User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:188.8.131.52) Gecko/20101211 Firefox/3.6.13 (Palemoon/3.6.13) Build Identifier: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:184.108.40.206) Gecko/20101203 Firefox/3.6.13 With nested DIV and A elements on a page (specifically DIV nested inside A nested inside DIV), on occasion the A element is prematurely terminated (creating an empty anchor) followed by the DIV that is supposed to be nested inside the A, with inside it another A. It's verified (with firebug vs. page source) that the actual page source is correct, but the HTML parser breaks and repeats the element. If styled as on the example page with a fixed height, this breaks the layout and page flow due to the double insertion of an anchor where there should only be one. Doing a page refresh -sometimes- fixes this error, or may break it again on subsequent refreshes of the same page (same page source). When it breaks, it is, as far as I can see, consistent in which anchors it breaks on, but the occurrence of the error is erratic. Reproducible: Sometimes Steps to Reproduce: 1. Visit the indicated page 2. Refresh, if needed, to see the problem occur (thumbnails are pushed out of alignment (down) when it happens. Actual Results: Thumbnails in the flowed grid of images are out of alignment and interspersed with whitespace. In code: DIV A /A DIV A ...content /A /DIV A /A /DIV Expected Results: A neat grid of thumbnails should be displayed. in code (as source): DIV A DIV ... content /DIV /A /DIV This has been tested on a fresh install of FF 3.6.13 with no addons and default config on a new profile. Firebug has been used to verify the code "as rendered" as opposed to "as downloaded"
Nesting of links is not allowed in html 4. http://www.w3.org/TR/WD-html40-970917/struct/links.html#h-13.2.3 AFAIK it is allowed in html 5 and Firefox 4 will support them as part of its html 5 support.
The links aren't nested, there is only -one- link involved, but it sometimes (not always) breaks the link when the nested DIV inside of the link is encountered. The A indicated in the resulting code example would be a repeat of the same link, just "chopped up" in several instances. If it would not be allowed to have a DIV within a link, and FF renders it strict to that rule, then it should -always- break the A up, but it doesn't. So either way this would be a bug.
This is fixed by the HTML5 parser in firefox 4. In Firefox 3.6 and earlier, the issue is that the invalid-markup detection depends on packet boundaries; if a packet boundary falls inside the div-inside-a then the <a> will get closed and reopened.
Status: UNCONFIRMED → RESOLVED
Last Resolved: 7 years ago
Resolution: --- → FIXED
Will this not be fixed for 3.6.x then? Sounds to me like this is quite an essential piece of coding to be fixed up!
This won't be fixed in 3.6.x, no. "Rewrite the HTML parser from the ground up" really doesn't fit in the "security and stability changes" scope of security updates, which is what 3.6.x releases are.
I wasn't aware that a fix to not break on packet boundaries would be -that- involved. If it is though, I fully agree that it's not within the scope of security and stability changes. One question though: if the markup would be valid (i.e.: not having a DIV inside A), would this still be an issue or not? Meaning: can this be avoided by having valid HTML? Because if it still is an issue even with valid markup, then anything with a larger amount of content between A and /A would suffer from the same link breaking (and combined with spatial styling of A elements this would be very problematic)
> if the markup would be valid (i.e.: not having a DIV > inside A), would this still be an issue or not? It wouldn't be. The bug is in the very complicate "fix up incorrect markup" parts of the parser; if you don't put blocks inside <a> the relevant code isn't executed. Note that the behavior there has been the same going back at least 10 years or so. So it's not like it's a new problem in 3.6....
Perfectly clear, Boris. Thanks for explaining :) In short, just means the site admin needs to fix up their markup.
You need to log in before you can comment on or make changes to this bug.