All of the boxes on this page are div-inside-a, with the a elements having a title attribute. (Usually) on first load, some of the boxes (the second-from-right on the top row, as I've seen it, plus one on the second row) don't show the link cursor or bring up the tooltip. On reload, things work as you would expect. I can reproduce it pretty reliably, and others have seen it as well, but let me know more details are needed!
Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9b3pre) Gecko/2008012615 Minefield/3.0b3pre I see it also on windows. Also on Firefox 1.x so it is not a (recent) regression.
OS: Mac OS X → All
Hardware: PC → All
It's a parser bug when a block-in-inline (in the DTD sense) occurs on "scanner boundary" so the tokenizer delivers something like so: ... <a> <div> kEOF the trailing start tags will be left as "undecided" by ScanDocStructure(): http://bonsai.mozilla.org/cvsblame.cgi?file=/mozilla/parser/htmlparser/src/nsHTMLTokenizer.cpp&rev=3.155&root=/cvsroot&mark=336,400,417,428,438#327 which causes HandleDefaultStartToken() to make a "pessimistic" decision for this block-in-inline, since it's not known to be well formed: http://bonsai.mozilla.org/cvsblame.cgi?file=/mozilla/parser/htmlparser/src/CNavDTD.cpp&rev=3.501&root=/cvsroot&mark=927,928,934,1007,1019#920 we will close containers on line 1007, instead of taking the 'eLetInlineContainBlock' route.
Component: Event Handling → HTML: Parser
QA Contact: events → parser
Created attachment 299974 [details] [diff] [review] wip FWIW, this seems to fix the URL (by being "optimistic" instead). Not sure what a real fix is though...
Would this patch (or a related one to prefer kLetInlineContainBlock) also help with 311366?
> block-in-inline (in the DTD sense) occurs on "scanner boundary" I'm pretty sure we have that on file already; mrbkap would know.
This sounds like a dupe of bug 324875, basically. The problem with the patch here would be something like: <em><div><script></script>foo</em> bar In this case, I'd expect 'bar' to not be italicized, but with the patch, the parser will let the <em> element contain the <div>. Then, when we hit the </em>, we'll see that there's a <div> in the way and ignore the end tag. This problem is mostly orthogonal to bug 311366 because this code only affects CNavDTD::IsInlineElement elements and (as people have been noticing in the other bug) user defined tags are not "inline" in that sense (thanks, rickg!)). The real fix here is really to just fix bug 328930 (also known as bug 373864) but that's not going to happen for Firefox 3.
Adding some keywords for search: packet boundary bug vomit bug block-level link bug ref: https://bugzilla.mozilla.org/show_bug.cgi?id=552363 which has some more background info
Status: NEW → RESOLVED
Last Resolved: 8 years ago
Resolution: --- → FIXED
Whiteboard: DUPEME → [fixed by the HTML5 parser]
You need to log in before you can comment on or make changes to this bug.