When middle-clicking on a link the icon and scroll arrows for autoscroll appear instead of opening the link in a new tab...regression

Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.8b2) Gecko/20050520 Firefox/1.0+ I can confirm this. Also Right-Click, then Open in new Tab doesn't work. I expect this is related.

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

Without autoscroll enabled, middle click functions as normal. Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.8b2) Gecko/20050520 Firefox/1.0+ ID:2005052009

right click> open in new tab works for me. 14:41 build

This works for me with fixes checked in today, not yet in respins, for bug 281988. /be

Note: You have to have Tools > Options > Advanced > General > Use Auto-scroll enabled to see the middle-clicking-a-link-not-working bug.

Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.8b2) Gecko/20050520 Firefox/1.0+ ID:2005052013 Still broken, are there other fixes to go in or should this have been fixed in this build. Apologies if you meant that the fixes are still to be checked in. -> Reopen in case it should be fixed by earlier checkins

Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.8b2) Gecko/20050520 Firefox/1.0+ ID:2005052014 With Tools > Options > Advanced > General > Use Auto-scroll ticked, middle clicking on a link still pops the Auto-scroll icon rather than opening the link in a new tab like it used to.

Yeah, fresh build from a 40 minute-old checkout shows the same thing here.

very annoying bug indeed.

FYI. Using All-In-One Gestures 0.14.3 with "All-In-One autoscroll" set, this doesn't happen. With "Native autoscroll" set, problem manifests.

this hits linux too with the auto-scroll turned on

The problem is that instanceof is returning false across the board for XPCNativeWrappers.

Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.8b2) Gecko/20050521 Firefox/1.0+ Still shows up on the 21st's build.

Need an easy way to test "system" scripts. If someone can make a reduced testcase for Firefox, please lay it on this bug. /be

Apply this, rebuild in browser/, start firefox, right-click on an HTML page. instanceof isn't broken for Components.interfaces.nsIFoo because the relevant hasInstance hook deals. The problem here is that DOMJSClass_HasInstance does _not_ deal: it gets an XPCNativeWrapper JSObject, gets its class, and tries to return a value based on that, which naturally doesn't work. I suppose we could manually get the wrapped JSObject here or something... Need to expose a way to tell that we're dealing with an XPCNativeWrapper if we do that. And we might have to fix the various other hasInstance hooks too (eg liveconnect, maybe jsxml, etc).

Comment on attachment 184266 [details] [diff] [review] Patch per discussion with jst r+sr=jst

Comment on attachment 184266 [details] [diff] [review] Patch per discussion with jst Fixes instanceof regression with the new security stuff.

Fixed.

(In reply to comment #21) > Fixed. Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.8b2) Gecko/20050522 Firefox/1.0+ Verified Fixed in the latest hourly on WinXP

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