266958 - Invalid HTML causes mozilla to open different url than statusbar on new tab

Status: RESOLVED WORKSFORME

(SeaMonkey :: UI Design, defect)

Description

[Chris Thomas (CTho) [formerly [e-mail] [e-mail]]]

Seamonkey version of bug 266932

Comment 1

[Chris Thomas (CTho) [formerly [e-mail] [e-mail]]]

The URL is set to the testcase
(https://bugzilla.mozilla.org/attachment.cgi?id=164020&action=view).

From bug 266932 comment 0:

> User-Agent:       Mozilla/5.0 (Windows; U; Windows NT 5.0; rv:1.7.3)
Gecko/20041001 Firefox/0.10.1
> Build Identifier: Mozilla/5.0 (Windows; U; Windows NT 5.0; rv:1.7.3)
Gecko/20041001 Firefox/0.10.1
> 
> As reported by Netcraft
>
(http://news.netcraft.com/archives/2004/10/29/new_url_spoofing_flaw_found_in_internet_explorer.html),
> this bug which affects IE, also affects Firefox.
> 
> The following 2 code samples cause firefox to display http://www.mozilla.org on
> the statusbar but when you open the link in a new tab, it goes to google.com.
> 
> 1)
> <a href="http://www.mozilla.org"><table><tr><td><a
> href="http://www.google.com/">http://www.mozilla.org</a></td></tr></table></a>
> 
> 2)
> 
> <a href="http://www.mozilla.org"><div><a
> href="http://www.google.com/">http://www.mozilla.org</a></div></a>
> 
> 
> 
> Reproducible: Always
> Steps to Reproduce:
> 1. Right click on sample url, then choose open in new tab.
> 2.
> 3.
> 
> Actual Results:  
> Instead of going to mozilla.org as reported by the status bar, it goes to
google.com
> 
> Expected Results:  
> Firefox should go to mozilla.org or report google.com on the status bar

Comment 2

[Christian :Biesinger (don't email me, ping me on IRC)]

also seen on linux. os -> all

Comment 3

[Christian :Biesinger (don't email me, ping me on IRC)]

so which url _should_ we go to?

Comment 4

[Boris Zbarsky [:bzbarsky]]

This one is interesting.  Note that actually clicking the link goes to
mozilla.org.  Which is not surprising, since the same code handles both that and
the status bar setting.

The "right" thing to do is to not allow <a> within another <a>.  If there's no
way to fix that, then the "right" thing to do is to go to the inner link (and we
have an existing bug on that).

Comment 5

[Blake Kaplan (:mrbkap) (inactive)]

In the case of <a href=a><a href=b>foo</a></a> we (correctly) do not allow this
nesting (i.e., the DOM is <a></a><a>foo</a>). However, the problem here is that
we have to allow <a> to contain <div> (we have bunches of code dealing with this
inline-contains-block quirk) which can then contain <a>. I don't think the DTD
has the concept of not allowing a tag if its parent is in the current stack.
Also, what *should* the content model look like if we don't allow this? The
obvious choice to me seems dangerous:
1) <a><table><tr><td></td></tr></table></a> <table><tr><td><a>etc...
2) <a><div></div></a><div><a> ... what if the <div> has an id=?

(also note that simply ignoring the nested <a> isn't a real solution)

which would be something like we do for RS handling, but looks hard to implement
with lots of chances to get things wrong... So unless I've missed something,
this doesn't look like it can be fixed in the parser.

Comment 6

[Blake Kaplan (:mrbkap) (inactive)]

Sorry, I misspoke. We *do* do this sort of check for <a>, but don't actually act
on it. I'm still not certain what we should do in this case... if the code
worked the way I had expected when I looked at it earlier, we would drop the
second <a> on the floor. Is this actually desired?

I'll try to look at this on Monday, if nobody else wants to (I probably will not
have time to look at it tomorrow).

Comment 7

[[e-mail]]

This is all down to our screwy event model. Basically event processing for links
works like this:
a) the event beings capturing phase, and is sent up the DOM tree for processing.
Capturing event listeners fire as the recursion unwinds.
b) the event begins bubbling phase, and is sent up the DOM tree to fire bubbling
events.
c) once all the bubbling events have fired, the link processing phase fires as
the recursion unwinds. This makes link processing behave somewhat like a
capturing event listener in the system group, except that mouse enter and exit
events don't have a system event phase.
It looks as if areas have been specially hacked to get this right...

Comment 8

[[e-mail]]

OK, so by making the ESM and PresShell dispatch extra system events, and by
calling HandleDOMEventForAnchors during the system bubbling phase, I was able to
get the hover and click to apply to the google link.

Comment 9

[Adrian Kalla [:adriank]]

WFM on Mozilla 1.8b2 nightly 2005041106

Comment 10

[Chris Thomas (CTho) [formerly [e-mail] [e-mail]]]

(In reply to comment #9)
> WFM on Mozilla 1.8b2 nightly 2005041106

WFM 20050730

Comment 11

[Blake Kaplan (:mrbkap) (inactive)]

This particular problem ended up being fixed by the checkin for bug 90664. Note
that it is still possible to trigger this with an XHTML page or by using DOM
methods.

Comment 12

[Olli Pettay [:smaug][[e-mail]]]

Attachment: test case

Bug 234455 fixed this also for XHTML

Comment 13

[Olli Pettay [:smaug][[e-mail]]]

Oops, no. It is still there...

Comment 14

[[e-mail]]

I need to retest with a clean build, but this works in my development tree.

Comment 15

[Boris Zbarsky [:bzbarsky]]

I think we should retest this after fixing bug 127903...  Please do not resolve until then.

Comment 16

[Jonathan Watt [:jwatt]]

This is still broken for me. The inner link is to google.com but I currently get:

Loading in current window:

  mouseover: google.com  in status bar
  mousedown: mozilla.org in status bar
  mouseup:   mozilla.org loaded

Loading in new window/tab:

  mouseover: google.com  in status bar
  mousedown: mozilla.org in status bar
  mouseup:   google.com  loaded

(Note: be careful you're putting the cursor directly over the text, or it may not be over the inner link, so everything showing mozilla.org is correct.)

This bug is fixed by the current patch in bug 331959 (attachment 216626 [details] [diff] [review]).

Comment 17

[Markus S.]

This bug seems to be fixed. I tested with Mozilla/5.0 (Macintosh; U; PPC Mac OS X Mach-O; en-US; rv:1.9a1) Gecko/20061210 SeaMonkey/1.5a and both links show google.com as target and visit Google when clicked.

Comment 18

[Tony Mechelynck [:tonymec]]

Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.9pre) Gecko/2008040701 SeaMonkey/2.0a1pre

WFM. I'm marking this RESOLVED. If you reopen, please mention:
- User-Agent string from about: page, similar to the one at top of this comment
- Clear and unambiguous "Steps to Reproduce"
- Actual result
- Expected result
- Any useful additional info.