301187 - Ctrl-click on link no longer opens a new tab with links via PHP.

Status: VERIFIED WORKSFORME

(SeaMonkey :: Tabbed Browser, defect)

Description

[Jason Bassford]

Steps to reproduce:
1. Go to the URL.
2. Enter a query that brings up several links.  (Try selecting all resolutions
and "cache", for instance.)
3. Ctrl-click on one of the links.

What happens:
Nothing at all.

What should happend:
The link should be opened in a new tab.

NOTE: If you right-click and select open in a new tab it works just fine.  But
the Ctrl-click functionality is broken.  This only seems to happens with some
PHP generated pages - I haven't narrowed it down further than that.

(Why is "tabbed browser" not available as a component here?)

Comment 1

[Jason Bassford]

I just noticed this problem with some Google search results also.  Oddly, it's
only some of the links that don't work with Ctrl-click.  Others work just fine.
 So it may have nothing to do with PHP.

Comment 2

[George]

It does not work here regardless of the link I Ctrl-click on. The "open new tab
for ctrl-click" funcionality is completely dead for me.

Comment 3

[Jason Bassford]

I've got to get this to some appropriate component for better attention - so
switching to Core / Tabbed Browsing for now.  (It can be switched somewhere else
if need be.)

Comment 4

[George]

Jason,

Stop the presses!

This behaviour does not surface unless you have the Multizilla/Multiviews
extension installed. There definitely was a change in Mozilla 1.7.10 which makes
Multizilla break the ctrl-click for new tab funcionality. There were no isues
with Mozilla 1.7.9.

Thus, at first I do not even know whether it is a Mozilla or a Multizilla issue?...

Setup: Mozilla 1.7.10, Multizilla 1.8.0.1.d & 1.8.1.0.a, running under Win2KPro
on a P4 3.2GHz, with 2GB RAM.

Comment 5

[Jason Bassford]

I don't use Multizilla, but I do use both the Linky and Single Window
extensions.  I tested with a new profile and things work.  I'll try to narrow
things down further and report back.

(I wonder, though, if we can just point the finger at a set of extensions - or
if we can pinpoint what changed in the code to break them...)

Comment 6

[George]

I also use Linky, and ctrl-click worked with that for me. I do not use
Singlewindow, however.

Very funny though. This is what I get in the Javascript Console in response to
ctrl-clicking a link (nothing happens, of course):

'
Error: findParentNode is not defined
Source File: chrome://multiviews/content/contentAreaClick.js  Line: 434
'

I get the same error if I click on one of the tab headers.

What is even funnier is that if I do not click a link, but just click on a
random/neutral/nonfunctional part of any web page, in any of the tabs open, or
just the empty space on the tab bar, I get the same error but twice for each click!

'
Error: findParentNode is not defined
Source File: chrome://multiviews/content/contentAreaClick.js      Line: 99
-
Error: findParentNode is not defined
Source File: chrome://multiviews/content/contentAreaClick.js      Line: 179
'

These last two errors are thrown by subs that check whether the left mouse
button is pressed down. 

The complete line of code is the same in all three cases:
'
            linkNode = findParentNode(event.originalTarget, "a");
'

?

Comment 7

[Jason Bassford]

Okay, confirming.  When I remove the Single Window extension, Ctrl-click opens
new tabs again.  (Which is ironic, since that extension is supposed to make
links open in tabs.)

Comment 8

[Jason Bassford]

However, as far as I'm concerned, there's a problem with SeaMonkey if Ctrl-click
doesn't do *exactly* the same thing as Right-click (context menu) -> Open link
in a New Tab.  (I can't see why they should be different.)

I think you're on the right track that it's not the tab functionality that's
broken, per se, but something to do with the mouse button.  However, the fact
that Ctrl-click works on *some* links makes it stranger...

Comment 9

[George]

It seems we are being worked around by the guys improving the phishing detection.

See: https://bugzilla.mozilla.org/show_bug.cgi?id=296758

...

Comment 10

[Jason Bassford]

Is there a specific bit of the code / a comment there that makes you think it's
the cause of this breakage?

Comment 11

[George]

Unfotunately, it is more uf a hunch as of now.

For sure they were messing with the same part of contentareaclick.js in Mozilla.
That is what makes me think so.

I just left a bug report for Multizilla.

See: http://www.mozdev.org/bugs/show_bug.cgi?id=11128

Comment 12

[George]

Jason,

As it turns out, my suspicion about one of the security bug fixes killing the
findparentnode function have been proven right.

My bug report for Multizilla has become labeled as the duplicate of another bug
from a few weeks before. (oh well....).

In any case, a fix has just been landed for Multizilla, which could also be used
for SingleWindow (after some fiddling). Also, you might find HJ's (Multizilla
owner) comments informative.

My bug report: http://bugzilla.mozdev.org/show_bug.cgi?id=11128

is duplicate of: http://bugzilla.mozdev.org/show_bug.cgi?id=10967

Comment 13

[Adam Guthrie]

Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9a1) Gecko/20051003
Firefox/1.6a1 ID:2005100313

Ctrl+Clicking a link from that search opens the link in a new tab (WFM).