599339 - When clicking a link nested in another link, the outer link is followed; should follow the inner link

Status: RESOLVED DUPLICATE of bug 331959

(Core :: DOM: Core & HTML, defect)

Description

[Radek 'sysKin' Czyz]

User-Agent:       Mozilla/5.0 (Windows NT 6.1; WOW64; rv:2.0b7pre) Gecko/20100923 Firefox/4.0b7pre
Build Identifier: 

With html 5 parser, it's possible to nest anchors by wrapping table with an "outer" anchor and then making another anchor in the table itself.

This break my Motorola modem configuration website and presumably other websites.

Moreover, at least Firefox is completely confused by such construct and when inner link is clicked, it navigates to outer link's address but displays inner link's address in status bar (or urlbar equivalent, whatever that's called).



Reproducible: Always

Steps to Reproduce:
1. Using Minefield,, load attachment
2 [review]. Inspect the DOM
3. Inspect the "bugzilla" link by hovering over it and seeing where it goes
4. Click the link

Actual Results:  
* DOM contains a <table> as child of <a>
* the link seems to go to bugzilla
* the link actually takes you to google


Expected Results:  
the DOM has <a> closed and <table> as <a>'s sibling


I don't really know if it's html 5 parser bug or the DOM is expected. Parsing  certainly gives different results than on IE8, FF3.6.

If the DOM is expected, then I guess it's a Firefox bug. Link's target is incorrect.

If the DOM is not expected then it the Firefox bug might still be valid. Please tell me if I should file one.

Comment 1

[Radek 'sysKin' Czyz]

Attachment: attachment for STR

Comment 2

[Boris Zbarsky [:bzbarsky]]

ccing Henri about whether the parser is doing the right thing.  The other issue (of showing the wrong link) is already filed, since there were plenty of ways to get the old parser to nest <a>.

Henri, the fact that this breaks a modem's configuration screen is particularly bad....

Comment 3

[Henri Sivonen (:hsivonen) (temporarily away from Bugzilla)]

(In reply to comment #2)
> ccing Henri about whether the parser is doing the right thing.  The other issue
> (of showing the wrong link) is already filed, since there were plenty of ways
> to get the old parser to nest <a>.

The parser is doing the right thing and the spec is properly describing the old WebKit tree builder behavior. The problem is that Gecko follows the outer link when it needs to follow the inner link.

I don't know which component covers link clicking, but I'm guessing DOM HTML.

> Henri, the fact that this breaks a modem's configuration screen is particularly
> bad....

Indeed.

Comment 4

[Boris Zbarsky [:bzbarsky]]

My impression was that the breakage here was from the DOM difference even without clicking, not the clicking behavior per se. Radek, is that incorrect?

The clicking thing is a duplicate of a very old bug, as I said in comment 2; fixing it is likely out of scope for 2.0 at this point (involves major changes to activation behavior across the board).

Comment 5

[Radek 'sysKin' Czyz]

(In reply to comment #4)
> My impression was that the breakage here was from the DOM difference even
> without clicking, not the clicking behavior per se. Radek, is that incorrect?

Yes, the reason why motorola's config page *no longer* works is difference between html 5 parser and old parser. What firefox does with the link is, I agree without testing, an old bug.

Sooo I just tested Chrome and Opera and they both do new html5 thing, nesting table inside <a>. Motorola config page continues to work because they don't have the outer/inner <a> bug.
Strange that html 5 does that, but I have to conclude it's consistent so probably as per specs...

Comment 6

[Boris Zbarsky [:bzbarsky]]

OK, so fixing the click thing would in fact fix this?

That's a duplicate of bug 331959 (which is a regression of bug 26583), right?

Comment 7

[Radek 'sysKin' Czyz]

(In reply to comment #6)
> OK, so fixing the click thing would in fact fix this?

If Chroma and Opera are any guide, yes. They go to the "inner" link when "inner" link is clicked, which is all that's needed to navigate as expected.

Oh, and I just tested IE8 and it does the same as html 5. So in fact old mozilla parsing was "different" and now all is consistent everywhere I can see.