Description

Internet Explorer 6 does not render pages correctly.

Steps to reproduce

1. Go to page MoinMoinBugs/InterwikiAndPageNameNotOnSameBaseline on this Wiki (as an example)

2. View it in IE6 (see screenshot below)

Example

Details

This Wiki.

The text directly above the table is not displayed in IE6 (although space is reserved, and selecting the text with the mouse, or sometimes hiding and re-exposing the window, can force a redraw).

After some fiddling with the HTML generation code, I have confirmed that the issue is with the "line number" anchors <span id="line-XX" class="anchor"></span>. I have tried a number of variations of stylesheet rules and HTML, but have not been able to get a consistent rendering.

This issue may be related to the interaction of line number anchors just before a table - but I haven't isolated it enough to be certain...

A previous bug (display of <pre> blocks) was also related to these anchors.

My understanding is that the line anchors are intended for use by the action=diff rendering, to implement links from the diff to the page itself. Would it be possible to limit the damage, maybe by only including the links when in "diff" mode? I don't know enough to produce a patch - although I'll continue to look at the possibility. Would a patch on these lines be accepted?

• The line numbers were invented for diff mode, right, but while doing it, I thought it would be nice to have them in general, so that you could say "look at http://mywiki/page#line-42" (or even just "...#42") to directly point someone at a specific line of text. Ok, so lets discuss how to solve:

• restrict line anchors to diff view (aka "less damage")
• don't use those anchoring spans, but put the line number id/name into the first html tag generated for that line. this would require a more complex and bigger formatter change.
• use IE7 for viewing pages (but not for edit mode)
• more ideas?

(Delay in responding because I missed this comment - sorry).

• I have looked into restricting line anchors to diff view only, and it's extremely difficult, as the diff action is strongly decoupled from the Wiki parser (which generates the line anchors) and the HTML formatter. This option probably isn't worth pursuing further, I doubt it's much easier than your second option.

• ID in the first tag should fix the IE rendering bugs once and for all, as they all seem to be related to the tags (whether the original <a> or the current <span>) having empty content. But as you say, it's hard. Also, some lines may not have tags (for example, content within <pre>).

• IE7 does not fix the rendering bugs, unfortunately...

• A variation on the "ID in the first tag" approach might be to wrap the whole content of the line in <a id="...">....</a>. Then the anchor is attached to the whole line content, and is non-empty. It's not trivial to implement - I couldn't be sure I'd not end up mismatching the start and end tags - but it looks easier than the other option, and could work.

• I tried only generating line anchors for non-blank lines, but that doesn't work, either (lines such as the { { { that start a preformatted block are non-empty, but generate no content).

• I'm still looking at CSS hacks, but so far not getting very far. An alternative might be some sort of Javascript hack, but that's too ugly even to contemplate

Yay, I got a fix Pure black magic, but it seems to work. I'll check on non-IE browsers later, but I've attached a diff against beta 5. moin-1.5.0beta5.diff

OK, I have tested this patch in the following browsers:

• Firefox 1.5 on Windows XP SP2 - looks fine
• IE6 on Windows XP SP2 and Windows 2000 - looks fine
• Opera 8.5 and 8.51 on Windows XP SP2 - spacing between paragraphs is wider than it should be (or at least, than it was before). I'm not sure if this is bad enough to constitute a major issue - I certainly don't know how to fix this without breaking IE6 again! I've attached a screenshot of Opera's behaviour with the patch, for what it's worth.

Note - this is utter magic - I have no idea why this fixes the IE issue. It's hugely fragile. But my experience is that any attempt to fix cross-browser rendering bugs is like this, so I don't know how to do any better...

FWIW, there are still some HTML validation errors relating to the line number anchors (click on the "Valid HTML 4.01" link to see the details). Whether fixing these would fix the rendering issues, I can't tell...

Workaround

Use another browser (not an option for some people, including me...)

Discussion

The screenshot looks outdated, could someone please update it and check if the issues with IE are still there?

Just checked, yes they are still occurring. -- PaulMoore 2005-12-12 14:37:05

Grumble. Just checked a second time, and things look OK at the moment. This was always a fairly intermittent bug, so I'm reluctant to say it's "fixed".... Ha! I reproduced it again, at MoinMoinBugs/CannotUpdateCreateDrawings. Screenshot updated. -- PaulMoore 2005-12-12 14:44:43

Further update

There may be a better approach to solving all of this. Originally, there were two separate rendering bugs:

1. The highlightiong of <pre> sections bled into the following paragraph.

2. Parts of the display were not drawn (but appeared if you select the text with the mouse, or hover over a link).

I believe that the second bug was made worse by the contortions required to fix the first. (And the contortions required to "fix" both results in what I refer to as "black magic" above...) Specifically, I think the second bug is caused by using display: none on elements with no content, which is triggering the display issues. I can't find any confirmation of an IE bug of this nature on the web, though.

I have found an alternative fix to the first bug, which may avoid causing the second. Specifically, if we go back to a simple <a id="..." class="anchor"></a> anchor (or possibly <span id="..." class="anchor"></span>, as <a> isn't valid HTML everywhere), and then use CSS to set the width and height of the anchor to 0, we seem to get correct behaviour.

There is one proviso - a block like

    { { {
    some preformatted text
    } } }

has an extra blank line after the text, as part of the preformatted block. Arguably, this is correct, as there is a newline between "text" and the "}}}", which generates the extra line. If you don't want that extra line, you can put the "}}}" on the same line as "text". This seems to me to be a reasonable requirement - what do others think?

I need to test this alternative on a few browsers before uploading a patch. This may take a couple of days (limited internet connectivity plus real life are interfering). Please watch this space... -- PaulMoore 2005-12-14 13:21:47

I have found what looks like an explanation - the problem lies with the fact that the anchor elements are empty. While legal, this is not handled well by IE6. See http://www.howtocreate.co.uk/wrongWithIE/?chapter=Empty+Elements for details. Specifically, the paragraph:

• Now for the second half of the problem. If the empty paragraph is not given a height or width, it should not be rendered at all, but in fact IE does not do this properly either. It just hides the contents of it, and renders the box as a single invisible line-height box, tucked under where it would have been. Applying a background will show the box in its new position (usually when coupled with a background on a preceding element).

(Note the last comment - "usually when coupled with a background on a preceding element" - this is what we see with the <pre> rendering bug).

Additionally, the HTML 4.01 spec says (section 12.2):

• Note. User agents should be able to find anchors created by empty A elements, but some fail to do so.

Ultimately, this seems to imply to me that there is no good solution with empty anchors - the correct solution would be to put the <a> element round the whole line contents - after all, that's the actual content that the line anchor refers to. But I can't follow the code well enough to produce a working patch for this.

(BTW, my previous idea was flawed, because my test file was using "quirks mode", where MoinMoin uses standards-compliant mode, and IE's behaviour differs between the two modes).

Suggestions:

• Disable line anchors altogether (not realistic, but I'll probably hack the one instance it matters to me on, as a workaround for now).

• Put the line content inside the <a> element (too hard?)

• Only display line anchors in diff mode, and accept any display breakage there (damage limitation).
• Make line anchors a user preference (awkward, as the user won't know why he/she should care).
• Browser detection - suppress line anchors for IE (too costly, as it invalidates the cache).
• Client-side browser detection - delete line anchors via javascript for IE (no guarantee it will work).

• Get someone more experienced than me in resolving browser compatibility bugs to look at it

Any comments?

Would it be possible, at the very least, to make line anchors optional (via a config variable, line_anchors, defaulting to 1) for the 1.5 release? It allows IE users a workaround (at the cost of line anchor functionality) without hacking the MoinMoin code.

Here's a patch, if the idea is accepted: line_anchor.diff -- PaulMoore 2005-12-29 13:39:26

If possible could one try my patch too probably it solves it too, see MoinMoinBugs/CancelTextEditRemovesSlashesInTitle -- ReimarBauer 2005-12-29 15:08:33

• Looks like I can't reproduce it with a current IE6 on the current code running here on moinmoin wiki. So I guess it got solved somehow by latest CSS changes...

This still exists in this wiki - I get the issue opening page MoinMoinBugs/DesktopEditionGivesCyclicUsageError. Screenshot here:

I have changed the category below - I don't know if this is the best way to "reopen" the bug report, my apologies if I should have done something different... -- PaulMoore 2006-01-10 11:55:11

Looks like the change noted in MoinMoinBugs/InternetExplorerPeekABooBugInRightSideBar might fix this. Any chance it could be applied to this Wiki, and then I could check better than I am able to manage on my local setup (where I haven't been able to achieve a 100% reproducible test case)?

Plan

• Priority:
• Assigned to:
• Status: seems like it has been fixed by recent css changes, please reopen if you still have the bug after clearing your browser cache.

CategoryMoinMoinBugFixed