151142 - modifier+click on a link (ctrl, shift) should not generate onclick event for links

Status: RESOLVED WONTFIX

(Core :: DOM: Events, defect, P5)

Description

[Norman Megill]

From Bugzilla Helper:
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.0.0) Gecko/20020530
BuildID:    2002053012

In the google.com page referenced, the ads in the right-hand boxes have both
"href=[newurl]" and "<table onClick='location.href=[newurl]'".  (The purpose is
to make the whole box clickable for user convenience, but also allow the link to
be clicked if Javascript is turned off.)  Control-clicking loads both a new tab
AND the current window with the new URL.  This defeats the purpose of tabbed
browsing.  I guess the question is:  should ctrl-click (meant for tabbed
browsing) activate onClick?  If so, shouldn't a change to location.href in
response to ctrl-click affect the newly opened tab only?

Reproducible: Always
Steps to Reproduce:
1. Enable tabbed browsing (all boxes checked in Preferences -> Navigator ->
Tabbed Browsing)
2. Go to http://www.google.com/search?q=mortgage
3. Ctrl-click on a link in a right-hand-side advertisement box


Actual Results:  A new tab opens with the advertised link (correct behavior). 
However, the original google page you are on is also overwritten with the
advertised link (unexpected and undesirable).

Expected Results:  Ideally only the new tab should open, and the Google page you
are on should remain unaffected.

Comment 1

[Vladimir Ermakov]

->Tabbed browser

Comment 2

[Jonas Jørgensen]

This is not a tabbed browser bug; the same arguments apply when ctrl+click is
set to open a new window instead of tab, and to shift+clicking a link.
--> DOM Events, though I'm not sure if that's the correct component.

Comment 3

[Jonas Jørgensen]

Attachment: Testcase

Comment 4

[Norman Megill]

I have a further comment on this.

When submitting this I called it an "enhancement" and not a bug because I think
any solution should be thought about carefully, and in fact may not be easy. 
Until then it might be best to leave well enough alone.

A "fix" of not triggering an onClick event with ctrl-click might be only a
partial solution with more drawbacks than advantages.  For example, if an href
is invoked via JavaScript with no direct hyperlink, the link would not open at
all.  While arguably this may be poor web page design, it is common and the user
often has no way of easily knowing whether there is JavaScript or a direct
hyperlink behind the scenes.

Another example is ctrl-clicking on a form submit button.  Should it open a new
tab?  Currently it doesn't.  However, the form is still submitted, and a new
page loaded in the current window.  I would love to see each new page under a
separate tab, so I could review all the information I filled in before
committing the final submit, for those stupid sites with complex multipart forms
that don't let you go back without erasing your data and don't tell you what
you've done.  Think about that!  A tabbed browsing feature like this would be
incredibly powerful and useful.

So, a general solution might do the following.  In every case where the browser
has a response to a normal click, a ctrl-click would produce the same behavior
but with the modified page displayed under a new tab.  So, for the general case
a ctrl-click would mimic the exact behavior of a standard click, but with the
result displayed under a new tab.

For the general case, there might not even be a new URL invoked, just some fancy
Javascript reformatting or something.  To summarize, the basic idea is that, "if
the page has any response whatsoever to a normal click, then ctrl-click will
open a new tab and place the exact same response under that tab, leaving the
original page intact".

In practice this might mean cloning the original page state behind the scenes so
its context (javascript content, etc.) is not lost, for use in constructing the
page under the new tab.

Or a more efficient solution might be to have the tabbed page routines reference
the original page while the tabbed page is being constructed, and not allow the
original page to be destroyed until the tabbed page no longer needs it.  Thus if
the user clicked a hyperlink on the original page while the tabbed page was
being processed, the original page would be kept in memory invisibly behind the
scenes until the tabbed page(s) no longer needed it.  This would be transparent
to the user, who would simply see a new page being loaded as usual over the
original page.

I know too little about the architecture to know what the scope of these changes
might be.  I'm just offering my idea of how I think it should behave ideally.

Comment 5

[Jesse Ruderman]

Some sites use Ctrl+click for something not related to navigation.  An example 
is http://webfx.eae.net/games/minehunter/minehunter.html, which uses ctrl+click 
to mark a square as containing a mine.  Mozilla should not break that by 
cloning the page just before handing the ctrl+click or by not sending the 
ctrl+click to the page.

For the case where a page uses javascript for navigation, the browser should 
temporarily redefine location.href= to open in a new tab/window when the user 
ctrl+clicks (bug 55696), but that would not completely fix the problem on 
Google's page (see bug 151833 comment 1).

I think this should be wontfixed in favor of bug 89296 (Google should fix their 
HTML).

Comment 6

[Norman Megill]

"Some sites use Ctrl+click for something not related to navigation."

This is a good point.  To address this problem, and to solve the google problem,
an algorithm like the following could be used.  The key idea is to make the
decision to trigger tabbed browsing at the point where a new page is loaded, not
directly in response to the ctrl+click itself (since we don't know yet how the
code behind the click will behave).  By "new page is loaded" I guess I mean any
change that would cause an update to the address displayed in the location field
in the toolbar:  it could be a direct hyperlink, a form submit, or a JavaScript
assignment to location.href.

1. When ctrl+click is pressed, clone the state of the current page with
sufficient information to recover in step 3(d) below.

2. Until a load of a new page is requested, treat crtl+click as it normally
would be treated without tabbed browsing.

3. At any point where a new page is loaded in response to the ctrl+click, the
following actions should be triggered:  (a) open a new tab, (b) start loading
the new page (surrounded by its frameset if it's a frame) into the tab, (c)
abort any processing of the current page's JavaScript, and (d) restore the
current page to the state cloned in step 1.

4. Otherwise, continue processing the current page until the response to the
click is completed.  Then we can discard the state cloned in step 1.

With this algorithm, the ctrl+click will not open new tabs in JavaScript games.
 On the other hand form submission can open new tabs and let us the easily
review all parts of a multipart form before the final commit (something I think
would be very useful).  And finally, google.com will work exactly as intended. 
I can't think of a case this would not handle correctly.

Comment 7

[Jonas Jørgensen]

Comment 5:

> Some sites use Ctrl+click for something not related to navigation.  An example 
> is http://webfx.eae.net/games/minehunter/minehunter.html, which uses ctrl+click 
> to mark a square as containing a mine.

That page doesn't contain any links (neither source nor dom inspector shows any
<a> elements), so it is not relevant to a discussion of generating onclick
events on ctrl/shift-click on links.

> Mozilla should not break that by 
> cloning the page just before handing the ctrl+click or by not sending the 
> ctrl+click to the page.

Correct, it should not. And it wouldn't if we only stopped generating onclick
events on links.

> I think this should be wontfixed in favor of bug 89296 (Google should fix
> their HTML).

Huh? Bug 89296 is marked dupe of a bug about not generating onclick events on
right-click.

Comment 6:

> 2. Until a load of a new page is requested, treat crtl+click as it normally
> would be treated without tabbed browsing.

Without tabbed browsing, ctrl+click on a link would open a new window.

> 3. At any point where a new page is loaded in response to the ctrl+click, the
> following actions should be triggered:  (a) open a new tab

...or window, depending on the preference...

> (b) start loading the new page (surrounded by its frameset if it's a frame) 

Definitely *not* surrounded by its frameset. Why should ctrl+click behave
differently than open in new window/tab on the context menu?

> With this algorithm, the ctrl+click will not open new tabs in JavaScript games

Nor would it if we made ctrl/shift+click on a *link* not generate an onclick event.

Comment 8

[Norman Megill]

> > 2. Until a load of a new page is requested, treat crtl+click as it normally
> > would be treated without tabbed browsing.
>
> Without tabbed browsing, ctrl+click on a link would open a new window.

Yes, but at that point a load of a new page is requested, so step 2 stops
applying.  Go to step 3.

> > 3. At any point where a new page is loaded in response to the ctrl+click, the
> > following actions should be triggered:  (a) open a new tab

> ...or window, depending on the preference...

Yes, if tabbed browsing is not enabled the existing behavior would apply.  The
algorithm describes the behavior for the case where tabbed browsing is enabled.

> > (b) start loading the new page (surrounded by its frameset if it's a frame)
>
> Definitely *not* surrounded by its frameset. Why should ctrl+click behave
> differently than open in new window/tab on the context menu?

Agree.  (I thought tabbed browsing did this now, but it seems the sites I looked
at are themselves forcing a reload of the frameset.  I just wanted to be
consistent with current behavior.)

> > With this algorithm, the ctrl+click will not open new tabs in JavaScript games
>
> Nor would it if we made ctrl/shift+click on a *link* not generate an onclick
event.

Do you also agree that ctrl+click that's not on a link, but reassigns
location.href in the JavaScript, should open a new tab?

BTW a separate google.com problem is that they incorrectly use
onMouseOver="this.style.cursor='hand'..." for IE users in violation of CSS2.  If
Google did it right the Mozilla user would see the hand cursor over the whole
box (see http://developer.netscape.com/evangelism/docs/articles/cursor/ ), in
which case the user would have no feedback whether or not the cursor was
properly positioned directly over the link.

Comment 9

[Jonas Jørgensen]

> Do you also agree that ctrl+click that's not on a link, but reassigns
> location.href in the JavaScript, should open a new tab?

Not quite sure. I don't see how it's relevant to this bug, though.

Comment 10

[Jesse Ruderman]

I like the idea of not sending onclick for just links when ctrl+clicking, but 
I'm worried that it would break sites that use <a href="#" onclick="foo()">.

Comment 11

[Norman Megill]

Attachment: Test case for ctrl+click

> > Do you also agree that ctrl+click that's not on a link, but reassigns
> > location.href in the JavaScript, should open a new tab?
>
> Not quite sure. I don't see how it's relevant to this bug, though.

See the attached test case.

Comment 12

[Jonas Jørgensen]

> I'm worried that it would break sites that use <a href="#" onclick="foo()">

If we didn't send onclick for ctrl/shift+link click and someone ctrl+clicked a
link like that, the current page would open in a new window/tab. That is also
what currently happens if you right-click such a link and choose open in new
window/tab.

For the case of <a href="javascript:foo()"> links, a ctrl+click would open a
blank tab, just like right-clicking and choosing open in new window/tab
currently does.

In other words, not sending onclick for modifier+click on links would make
ctrl+clicking consistent with open in new tab/window. (Yes, it's true that both
ctrl+clicking and right-clicking and choosing open in new window/tab should both
eventually open the link in a new window, but that is covered by bug 55696.)

Comment 13

[Jonas Jørgensen]

Norm: Yeah, I do think that ctrl+click that's not on a link, but reassigns
location.href in the JavaScript, should open a new tab.

(BTW, your testcase does not in any way assume "tabbed browsing enabled";
firstly, there is no such thing as enabling or disabling tabbed browsing -- all
there is is a pref to decide whether or not ctrl+click should open a new tab or
window -- and secondly, if that pref is turned off, the only difference should
be that ctrl+clicking opens a window instead of a tab)

Comment 14

[Jesse Ruderman]

See also bug 161719, "Opening a URL in a Tab that was destined to be a new
window fails by duping the same URL".  That bug involves an href="#" link.  A
possible solution to *that* bug is to execute onclick first, and if onclick
loads a page or returns false, not follow the link.  Bug 161719 depends on
several other bugs and applies to both the context menu items "open link in new
window/tab" and ctrl+clicking.

This bug is still about making ctrl+clicking a link do the same thing as the
context menu items, which for now means not firing onclick.

Comment 15

[Mats Palmgren (inactive)]

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

Comment 16

[Alfonso Martinez]

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

Comment 17

[John Keiser (jkeiser)]

Adding dependency on bug 184051, since whatever click event is fired there can
likely be reused for ctrl+click so we don't *lose* ctrl+click, we just don't
fire the actual onclick event.

Comment 18

[Torben]

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

Comment 19

[Bob Firth]

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

Comment 20

[Gérard Talbot]

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

Comment 21

[Gérard Talbot]

Attachment: Simple page for meta-testcase

Comment 22

[Gérard Talbot]

Attachment: Meta-testcase

Tests and results of 10 types of links often found in webpages, tutorials and
books; in a wide majority of cases, these links fail with featured Mozilla
settings for opening referenced resources.

Comment 23

[Gérard Talbot]

Attachment: Meta-testcase (corrected)

Tests and results of 10 types of links often found in webpages, tutorials and
books; in a wide majority of cases, these links fail with featured Mozilla
settings for opening referenced resources.
(I corrected a layout problem with the table; should render well now)

Comment 24

[Gérard Talbot]

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

Comment 25

[Jesse Ruderman]

Bug 257184 is nearly the opposite of this bug.  

Comment 26

[Gérard Talbot]

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

Comment 27

[Rob Decker]

The following is a bug which is somewhat related to this one. The following link
should NOT fire whatever action is assigned to holding down the
shift/ctrl/alt/meta keys. But it does. What options does that leave javascript
developers who want to use the state of the modifier to simply change the link?

<a href="http://www.firefox.com" onmouseup="top.location=this.href"
onclick="return false;">Show Bug
&lt;a href="http://www.firefox.com" onmouseup="top.location=this.href"
onclick="return false;"&gt;Show Bug&lt;/a&gt;
</a>

Comment 28

[Patrick-Emmanuel Boulanger-Nadeau]

If CTRL-Left click is assigned to open a new window or new tab, why should not
it do EXACTLY like right-click -> open in new window / new tab ? At least,
that's what I firmly believe it should be doing. How much longer until this is
fixed, or that we must stop using & recommending FF/Mozilla? :)

Please see https://bugzilla.mozilla.org/show_bug.cgi?id=296069 for another test case

Comment 29

[Boris Zbarsky [:bzbarsky]]

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

Comment 30

[Jesse Ruderman]

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

Comment 31

[Cameron]

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

Comment 32

[Cameron]

If joki ever comes back, s/he may feel free to take this back. Hopefully someone else might notice it if it's out in the queue.

Comment 33

[Phil Ringnalda (:philor)]

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

Comment 34

[nrlz]

Can this be expanded to include middle-clicks? Currently we fire middle-clicks, but we also reserve it to do auto-scrolling. If we have a reserved function which the website cannot override, then we might as well not fire the event to the content.

Comment 35

[Boris Zbarsky [:bzbarsky]]

Who is "we"?  The rendering engine certainly doesn't do auto-scrolling last I checked.  If your issue is that the Firefox code that does it doesn't prevent event propagation or doesn't look at whether the default action is allowed, then that's a bug to be filed on Firefox.

Comment 36

[Adam Guthrie]

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

Comment 41

[Marc E.]

It has been 6 years since this bug has been reported, will this ever be resolved?

This is why I almost never submit bugs to Mozilla.

Check out http://www.iht.com , thats a major website that is affected by this bug.

Comment 42

[Jesse Ruderman]

It might be neat if Firefox did call the onclick handler, but redirected navigation attempts to new tabs or windows depending on what key you are holding (cf bug 251137).  I wonder if bz and dbaron have a master plan for fixing this bug that way as part of bug 335963.

Comment 43

[Johnny Stenback (:jst)]

Not critical for 1.9.1, but if anyone has time and/or resources to figure out what we could do here w/o breaking complex sites that actually depend on modifier keys in event handlers etc, feel free to work on it and nominate patches.

Comment 44

[Jonas Sicking (:sicking) No longer reading bugmail consistently]

Here is what I think we should do:

When ctrl+clicking a <a> with href set, open the url in the href in a new tab/window but don't dispatch any click events.

This ensures that pages like the one in comment 5 doesn't break. It basically makes is treat ctrl+click on an anchor the same as dragging that anchor to an empty spot in the tabstrip to create a new tab.

This *should* be implementable in chrome by registering a capturing listener that calls stopPropagation().

Comment 54

[Jens Stutte [:jstutte]]

Bulk-downgrade of unassigned, 4 years untouched DOM/Storage bugs' priority.

If you have reason to believe this is wrong (especially for the severity), please write a comment and ni :jstutte.

Comment 55

[Kagami Rosylight [:saschanaz] (they/them)]

Modifier+click is now expected to generate click events, and getModifierState() can be used to prevent unwanted behavior.

Comment 56

[Ben Bucksch (:BenB)]

Modifier+click is now expected to generate click events

Expected by who?

and getModifierState() can be used to prevent unwanted behavior.

Who can use getModifierState() for this purpose (as stated in the initial description) and how?

Comment 57

[Matijs van Zuijlen]

(In reply to Kagami :saschanaz from comment #55)

Modifier+click is now expected to generate click events, and getModifierState() can be used to prevent unwanted behavior.

Both of these things are well known. The problem is the every website has to make an effort to use getModifierState(). This will not happen, so Ctrl-click is now unreliable for Firefox. Since it is unreliable it is pointless and should be removed.

Comment 58

[Kagami Rosylight [:saschanaz] (they/them)]

Oh, on the second investigation I found Chrome has some different behavior here. It does fire click event but window.open() behavior changes based on modifier state. The spec says:

If there is a user agent that supports control-clicking a link to open it in a new tab, and the user control-clicks on an element whose onclick handler uses the window.open() API to open a page in an iframe element, the user agent could override the selection of the target browsing context to instead target a new tab.

I think we want to implement this behavior.

Comment 59

[Anne (:annevk)]

I'm not sure that is enough to help OP, which is about window.location = ... sets.

Comment 60

[Kagami Rosylight [:saschanaz] (they/them)]

Agreed, filed bug 1686439 as this bug is not exactly about window.open behavior.

Comment 61

[Anne (:annevk)]

Why do you think this should be INVALID though? It seems quite reasonable for end users to expect consistent behavior with other link clicks here.

Comment 62

[Kagami Rosylight [:saschanaz] (they/them)]

Okay, let's go WONTFIX as we do want to keep firing onclick here.