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

RESOLVED FIXED

Status

()

Core
HTML: Parser
RESOLVED FIXED
10 years ago
8 years ago

People

(Reporter: shaver, Unassigned)

Tracking

Trunk
Points:
---
Dependency tree / graph

Firefox Tracking Flags

(Not tracked)

Details

(Whiteboard: [fixed by the HTML5 parser], URL)

Attachments

(1 attachment)

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

Comment 2

10 years ago
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

Comment 3

10 years ago
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.
Whiteboard: DUPEME
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.

Updated

10 years ago
Blocks: 432099

Updated

10 years ago
Blocks: 432181

Updated

10 years ago
Duplicate of this bug: 441752

Updated

9 years ago
Duplicate of this bug: 461460

Comment 9

8 years ago
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.