<a class="header-button" href="https://bugzilla.mozilla.org/home" title="Go to home page"> Bugzilla

Comment 2

•

23 years ago

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.

Component: Tabbed Browser → DOM Events

Summary: onClick response to ctrl-click defeats tabbed browsing → modifier+click on a link (ctrl, shift) should not generate onclick event

Comment 3

•

23 years ago

Attached file Testcase — Details

Reporter

Comment 4

•

23 years ago

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

•

23 years ago

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).

Reporter

Comment 6

•

23 years ago

"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

•

23 years ago

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.

Reporter

Comment 8

•

23 years ago

> > 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

•

23 years ago

> 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

•

23 years ago

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()">.

Reporter

Comment 11

•

23 years ago

Attached file Test case for ctrl+click — Details

> > 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

•

23 years ago

> 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

•

23 years ago

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)

Blocks: link-modifiers

Updated

•

23 years ago

Depends on: 128830

Updated

•

23 years ago

Blocks: window-choice

Comment 14

•

23 years ago

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.

Mats Palmgren (inactive)

Comment 15

•

23 years ago

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

Alfonso Martinez

Comment 16

•

22 years ago

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

John Keiser (jkeiser)

Comment 17

•

22 years ago

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.

Depends on: 184051

Vladimir Ermakov

Updated

•

22 years ago

Priority: -- → P3

Vladimir Ermakov

Updated

•

22 years ago

Severity: enhancement → normal

Updated

•

22 years ago

URL: www.google.com/search?q=mortgage → http://www.google.com/search?q=mortgage

Torben

Comment 18

•

22 years ago

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

Bob Firth

Comment 19

•

21 years ago

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

Comment 20

•

21 years ago

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

Comment 21

•

21 years ago

Attached file Simple page for meta-testcase — Details

Comment 22

•

21 years ago

Attached file Meta-testcase (obsolete) — Details

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

•

21 years ago

Attached file Meta-testcase (corrected) — Details

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)

Attachment #149847 - Attachment is obsolete: true

Updated

•

21 years ago

Keywords: testcase

Comment 24

•

21 years ago

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

Comment 25

•

21 years ago

Bug 257184 is nearly the opposite of this bug.

Summary: modifier+click on a link (ctrl, shift) should not generate onclick event → modifier+click on a link (ctrl, shift) should not generate onclick event for links

Patrick-Emmanuel Boulanger-Nadeau

Comment 26

•

21 years ago

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

Rob Decker

Comment 27

•

20 years ago

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 <a href="http://www.firefox.com" onmouseup="top.location=this.href" onclick="return false;">Show Bug</a> </a>

Comment 28

•

20 years ago

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

Boris Zbarsky [:bzbarsky]

Comment 29

•

20 years ago

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

Boris Zbarsky [:bzbarsky]

Comment 30

•

20 years ago

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

Cameron

Comment 31

•

19 years ago

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

Cameron

Comment 32

•

19 years ago

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.

Assignee: joki → events

QA Contact: vladimire → ian

Phil Ringnalda (:philor)

Comment 33

•

19 years ago

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

nrlz

Comment 34

•

19 years ago

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

•

19 years ago

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.

Adam Guthrie

Comment 36

•

19 years ago

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

Marc E.

Comment 41

•

17 years ago

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.

u88484

Updated

•

17 years ago

Flags: wanted1.9.1?

Jonas Sicking (:sicking) No longer reading bugmail consistently

Comment 42

•

17 years ago

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.

Johnny Stenback (:jst)

Comment 43

•

17 years ago

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.

Flags: wanted1.9.1? → wanted1.9.1-

Comment 44

•

17 years ago

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().

Updated

•

17 years ago

Depends on: 455268