299901 - Middle click fail on links with nested tags

Status: VERIFIED FIXED

(Core :: DOM: UI Events & Focus Handling, defect)

Description

[Ben Basson]

User-Agent:       Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.7.9) Gecko/20050706 Firefox/1.0.5
Build Identifier: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.7.9) Gecko/20050706 Firefox/1.0.5

Middle click is completely unresponsive when used on the "Read More" links on
Slashdot.

Reproducible: Always

Steps to Reproduce:
1. Visit http://www.slashdot.org/
2. Middle click "Read More"


Actual Results:  
Nothing happens.

Expected Results:  
Firefox should open the link in a new tab.

Comment 1

[Ben Basson]

Attachment: Minimised testcase

Comment 2

[Ben Basson]

Nominating to block 1.0.5, whatever is causing this will most likely break other
things too.

Comment 3

[Ben Basson]

This is not present on the trunk. Apologies for bugspam.

Comment 4

[:Gavin Sharp [email: [e-mail]]]

Confirmed:
Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.7.9) Gecko/20050706
Firefox/1.0.5

Works in 1.0.4.

Comment 5

[Ben Basson]

Attachment: Minimised testcase - image link

Looks like this bug affects middle-clicking on any child element of a hyperlink
that isn't a textNode.

Comment 6

[aja+bugzilla]

(In reply to comment #3)
> This is not present on the trunk. Apologies for bugspam.

It's a problem for the trunk build *I'm* running:
Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.8b2) Gecko/20050706
Firefox/1.0+ ID:2005070617 (Pacifica installer.exe)

Comment 7

[:Gavin Sharp [email: [e-mail]]]

This is almost certainly due to the changes from bug 298892. The
contentAreaClick changes made it so that any nested links fail the instanceof
checks, causing linkNode to be null. Long story short,

while (linkNode && !(linkNode instanceof HTMLAnchorElement))

should be:

while (event.originalTarget && !(event.originalTarget instanceof HTMLAnchorElement))

to match up with the previous code.

Comment 8

[Dennis Jacobfeuerborn]

(In reply to comment #6)
> (In reply to comment #3)
> > This is not present on the trunk. Apologies for bugspam.
> 
> It's a problem for the trunk build *I'm* running:
> Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.8b2) Gecko/20050706
> Firefox/1.0+ ID:2005070617 (Pacifica installer.exe)

I see this too in yesterdays prometheus tinderbox build and it is *very* annoying:
Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.8b2) Gecko/20050706 Firefox/1.0+

Comment 9

[:Gavin Sharp [email: [e-mail]]]

Checkin:
http://bonsai.mozilla.org/cvsquery.cgi?treeid=default&module=AviaryBranchTinderbox&branch=AVIARY_1_0_1_20050124_BRANCH&branchtype=match&dir=&file=browser.js&filetype=match&who=&whotype=match&sortby=Date&hours=2&date=explicit&mindate=2005-07-06+03%3A39&maxdate=2005-07-06+03%3A39&cvsroot=%2Fcvsroot
(second hunk)

Comment 10

[aja+bugzilla]

Nominating to block 1.8b3 as well.

Comment 11

[Jay Patel [:jay]]

Reassiging to dveditz to see if we can quickly fix this regression.  Sounds like
Gavin might have the solution to this one.

Comment 12

[Jay Patel [:jay]]

Nominating for everything, we'll have to see if we can get this fix in.

Comment 13

[:Gavin Sharp [email: [e-mail]]]

Attachment: Patch

This fixes it for me, and restores the original behavior.

Comment 14

[Daniel Veditz [:dveditz]]

Comment on attachment 188504 [details] [diff] [review]
Patch

sr=dveditz
also need the same fix in mail and xpfe

Comment 15

[Daniel Veditz [:dveditz]]

Attachment: thunderbird and suite version

Comment 16

[Daniel Veditz [:dveditz]]

Comment on attachment 188511 [details] [diff] [review]
thunderbird and suite version

gavin's patch, r/sr=dveditz for other ports

Comment 17

[Jay Patel [:jay]]

Comment on attachment 188504 [details] [diff] [review]
Patch

Let's get this checked in everywhere. a=jay

Comment 18

[[e-mail]]

D'oh :-[

Comment 19

[Mike Connor [:mconnor]]

suite fix landed on 1.7 branch and trunk
firefox and thunderbird fixes landed on aviary 1.0.1 branch and trunk

Comment 20

[Tracy Walker [:tracy]]

Verified with Windows Fx 1.0.5 2005-07-07-05-aviary1.0.1

Comment 21

[aja+bugzilla]

(In reply to comment #20)
> Verified with Windows Fx 1.0.5 2005-07-07-05-aviary1.0.1

Verifying fixed on trunk, too.
Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.8b2) Gecko/20050707
Firefox/1.0+ ID:2005070706 (auto-update)

Comment 22

[Kevin Brosnan]

*** Bug 299994 has been marked as a duplicate of this bug. ***

Comment 23

[Kevin Brosnan]

*** Bug 299996 has been marked as a duplicate of this bug. ***

Comment 24

[Adam Guthrie]

*** Bug 299950 has been marked as a duplicate of this bug. ***

Comment 25

[Adam Guthrie]

*** Bug 299957 has been marked as a duplicate of this bug. ***

Comment 26

[Adam Guthrie]

*** Bug 299929 has been marked as a duplicate of this bug. ***

Comment 27

[Andrew Schultz]

*** Bug 299913 has been marked as a duplicate of this bug. ***

Comment 28

[Rossen Naydenov]

Still not fixed in this release
Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.7.9) Gecko/20050707
Firefox/1.0.5

Comment 29

[Jay Patel [:jay]]

Rossen: Are you sure you have your middle mouse button configured correctly? 
Please provide a testcase that is still broken.  Both testcases already in this
bug work fine with the latest 1.0.5 candidate builds for me (and others).

Comment 30

[Frank Wein [:mcsmurf]]

BTW: I still see this bug (at least with SeaMonkey) on some links, i filed Bug
Bug 300353, a testcase is attached there.

Comment 31

[kangoophoo+moz]

Centre clicking OR ctrl+t clicking image links of any type results in no action
where a new tab should be. This is still happening in the latest 1.06 version.

Comment 32

[:Gavin Sharp [email: [e-mail]]]

This bug as filed is fixed. Are you sure you're not seeing this problem as a
result of extension incompatibility? Tabbrowser Extensions is known to be broken.

Comment 33

[Reid D Rivenburgh]

(In reply to comment #32)

Yes, I started following this bug because of what turned out to be a bug in TBE.
 The most recent version of TBE seems to work fine, though.