414418 - on first load, some of these <a>s don't trigger link cursor or title tooltip

Status: RESOLVED FIXED

(Core :: DOM: HTML Parser, defect)

Description

[Mike Shaver (:shaver -- probably not reading bugmail closely)]

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!

Comment 1

[Ria Klaassen (not reading all bugmail)]

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.

Comment 2

[Mats Palmgren (inactive)]

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.

Comment 3

[Mats Palmgren (inactive)]

Attachment: wip

FWIW, this seems to fix the URL (by being "optimistic" instead).
Not sure what a real fix is though...

Comment 4

[Mike Shaver (:shaver -- probably not reading bugmail closely)]

Would this patch (or a related one to prefer kLetInlineContainBlock) also help with 311366?

Comment 5

[Boris Zbarsky [:bzbarsky]]

> block-in-inline (in the DTD sense) occurs on "scanner boundary"

I'm pretty sure we have that on file already; mrbkap would know.

Comment 6

[Blake Kaplan (:mrbkap) (inactive)]

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.

Comment 9

[Oli Studholme]

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