55696 - "Force JavaScript link to open in new window or new tab"

Status: NEW

(Firefox :: General, enhancement)

Description

[Peter Anvin]

Unfortunately, it has become increasingly common for sites to abuse JavaScript
in various horrible ways.  The site http://www.svd.se/ is a good example: to get
to *ANY* article, you go through a JavaScript link instead of using plain, old,
usable links.

Unfortunately, this breaks the middle mouse button, which is supposed to open
the link in a new window.

It would be nice if the middle button in the presence of such a link would clone
the window currently in, and then activate the link, to simulate the proper
behaviour.

Comment 1

[ltskinol]

This also doesn't work in NN4.7, and would be an excellent enhancement
for Mozilla.  It's a real PITA for those of use who use the middle
button extensively.

Comment 2

[Doron Rosenberg (IBM)]

event handling and confirming

Comment 3

[Loco]

Related to bug # 22775.

Comment 4

[Antti Näyhä]

Not that much related to bug 22775.  The middle button behaviour is 
Unix-specific; the requested functionality could be achieved eg. on Windows by 
right-clicking and selecting an appropriate menu item.

Adjusting summary, lowering severity to 'enhancement', changing Platform/OS to 
All/All and removing dependency on bug 22775.

Comment 5

[Jesse Ruderman]

>It would be nice if the middle button in the presence of such a link would 
>clone the window currently in, and then activate the link, to simulate the 
>proper behaviour.

Another way to accomplish this would be to override writing to 
document.location and to document.location.href (and make it window.open() 
instead) when ctrl-clicking or middle-clicking on javascript links.  That way, 
if the javascript link turns out to do something to the current page rather 
than pretending to be a link, no harm is done.

Comment 6

[joki (gone)]

I think that in order to achieve the desired effect a bunch of things would have 
to be overridden.  What if the javascript: just opened a new window.  So you 
clone the window and then open a new one?  If you just run the JS link in place 
then you might overwrite the current window.  document.location and 
document.location.href are a good start but especially in today DOM world there 
are lots of other ways to modify the window contents.  For the moment I'm going 
to future this one.


This bug has been marked "future" because the original netscape engineer
working on this is over-burdened. If you feel this is an error, that you or
another known resource will be working on this bug,or if it blocks your work
in some way -- please attach your concern to the bug for reconsideration.

Comment 7

[Hixie (not reading bugmail)]

Reassigning QA Contact for all open and unverified bugs previously under Lorca's
care to Gerardo as per phone conversation this morning.

Comment 8

[Dave Close]

My preference, FWIW, is to have some way to prevent ALL automatic new windows.
Who cares what the web designer wants? It's my screen.

Comment 9

[Madhur Bhatia]

QA contact updated

Comment 10

[Jesse Ruderman]

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

Comment 11

[slice1900]

One additional benefit for this fix would be to make it easier for us to disable
Javascript entirely in our browsers.  As it stands now, you can disable
Javascript, but some sites that have a lot of useless Javascript garbage force
you to enable it at their site by making much of the navigation pop up
Javascript windows.  It is annoying to have to enable Javascript and then
hopefully remember to disable it again, and you run the risk they are trying to
do something nasty (luckily for us most of them do IE-specific nasty stuff, but
 if Mozilla gains enough market share, they may start coding for us also)  If I
could middle click, or open in new window on systems that lack a middle mouse
button, it makes life easier.

Though not as easy as a preference that lets you disable window.open except when
you click on the link, like Omniweb provides.  Though even with that, having the
middle mouse button open the window as a normal link or "do nothing" would be
preferable to the empty window with the "window.open('http://blah')" in the
title bar.  Is there a bug filed for this preference?  I'd like to know if so,
so I can vote for it, and tell others to do so as well.

Comment 12

[Pierre Chanial]

I regret that this bug has been only targeted for future.
Its severity is absolutely not 'enhancement' because the browser does not behave
the way the user expect. It is so boring!
I think that mozilla developers should pay more attention to such improvements
(like this one or preventing window maximization or pop-ups) that would be
readily and greatly appreciated by end-users.

Pierre

Comment 13

[Gervase Markham [:gerv]]

Jesse or joki: do you have any idea what would be needed to make this happen?
Would it be sane to make middle-clicking a JS link merely do exactly the same
thing as left-clicking it?

Gerv

Comment 14

[Damian Yerrick]

Would it be possible to clone the current page into a new window (as IE does
on Ctrl+N) and then follow the link as it would have been followed?

Comment 15

[Jesse Ruderman]

>Would it be sane to make middle-clicking a JS link merely do exactly 
>the same thing as left-clicking it?

It would be sane -- certainly more sane than applying the javascript to a new 
window containing about:blank -- but it wouldn't be as good.  Fixing this bug 
completely would:

- Make links implemented using javascript work correctly with left-clicks and 
with middle-clicks.

- Allow any bookmarklet that normally replaces the contents of the current 
window to instead create a new window when middle-clicked.  (The bookmarklet 
might, for example, document.write a list of links on the page, or set 
document.location to a URL that asks the W3C to validate the page.)


>Would it be possible to clone the current page into a new window (as 
>IE does on Ctrl+N) and then follow the link as it would have been 
>followed?

You don't know ahead of time if the javascript: link is functioning as a 
dynamic link, as a link-that-opens-in-a-new-window, or if it just makes a small 
change in the page.  The only case where cloning makes sense is if the 
javascript: link functions as a dynamic link.

Comment 16

[Gervase Markham [:gerv]]

The reason I suggest it is that an implementation of that _should_ be reasonably
trivial; in the middle mouse click handler, check for JS links and, if it is
one, call the left mouse button handler instead.

Gerv

Comment 17

[Marko Macek]

I have also notices that a news:// url cannot be open in a new window. This
worked before... file a new bug?

Comment 18

[Jesse Ruderman]

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

Comment 19

[johnh]

I'd like to second what was proposed in bug #92964 and by Gervase Markham.
Currently middle-clicking on javascript links doesn't do anything useful.

What was proposed by Gervase Markham seems like a very useful and easy
work-around (until something better can be done):
turn middle clicks into left clicks if the link is javascript.

Comment 20

[Nathan Neulinger]

Which are you meaning? My suggestion "pop up as cloned window and treat as left 
click", or "treat as left click".

If it get's treated as left click only that could be a bit confusing if you 
were expecting a new window to pop up and instead it replaced the contents of 
the current window. (I'm not sure if that is better or worse than the non-
functional current behavior.)

I think that "do nothing" would be better than current behavior, but clone+left 
would be preferred.

Comment 21

[johnh]

Replying to comment #20:

So now we have three or four proposed results on middle-button-click on
javascript link:
a. do nothing
b1. "pop up cloned window and treat as left click"
b2. guarantee that one new window is created with the new contents
c. treat as left click

b2 is the Right Thing, but I don't think it can be done without understand what
the javascript code does, and that's impossible.

b1 is what the origianl poster proposed to handle http://www.svd.se/,
 but it doens't work consistently.  It works for the site you listed
(http://www.svd.se/) but not for sites where the Javascript's purpose is to pop
up a new window (see bug #101384 for an example).  In those cases "clone and
left click" would result in TWO new windows.

Either a or c would be better than current behavior.
Both should be simple.

c is what Gervase Markham proposed ("treat middle click on javascript as left
click") seems, while not perfect, much better than the current behavior, and
better than choice (a).

Comment 22

[Nathan Neulinger]

right, but on the cases where middle clicking on the javascript link pops up a
new window - it didn't work before either.

I think a) is far preferable to c). The reason being "doing nothing" in my book
is better than doing something completely counter to what the user expects. If
you explicitly choose to middle click something, you are expecting it to pop up
a new window.

Possibilities:

	1) Nothing happens - "Oh, that must be a screwy link where middle click doesn't
work".
	2) (current behavior) One window pops up that has no content but a javascript
url
	3) Opens two windows, one with same as parent, other with popup'd new window
(same behavior as existing netscape for popup-javascript-links)
	4) Opens a single window with the resulting javascript

	5) Processes link as if you doubleclicked

Seems to me that any are preferably to 5. clone+left would yield either 3 or 4,
which would be a nice behavior. 

Comment 23

[Jesse Ruderman]

I still think my comment #5 would be the most useful and least confusing 
behavior.

- If the link sets document.location, channel the load into a new window and 
halt the javascript execution.
- If the link calls window.open(), allow it to open the window (even if the 
user has set restrictions on pop-up windows), but make sure it opens in *new* 
window rather than replacing a named window or frame by ignoring the second 
parameter to window.open().
- If the link simply modifies part of the page, let it modify the page (don't 
open a new window).
- If the link returns a value (eg javascript:5), open that value in a new 
window as data:text/html,5.

Comment 24

[Ben Bucksch (:BenB)]

Do NOT open something in the current window, when I requested to open it in a
new window. Sometimes, I have verys good reasons for my decision. For example, I
am on a complex form process (registration or whatever). If you replace the
current page, it might not be possible for me to get to the old one (esp. with
Mozilla's current broken caching), and I might lose the ability to register my
desired account name or lose money or whatever.

Comment 25

[Keith Lea]

Guys, it seems obvious to me that there is only one valid solution: When the
user middle-clicks or selects to open a javascript link in a new window, Mozilla
should make sure that any calls within the code in that link to change the
location of the current page be sent to a new window. Right? What is wrong with
this?

Comment 26

[Jesse Ruderman]

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

Comment 27

[Matt Fago]

Any activity on this? I have been running into this very frequently. Lots of
sites abuse javascript. 

It seems to me clearly to be a bug. If I select "Open link in new window," but
the link is actually a javascript, a new window is indeed opened, but the
javascript does not run. To many users it thus appears that Moz cannot handle
the javascript at all!

This is thus IMHO a fairly serious bug, no?

Comment 28

[Alfonso Martinez]

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

Comment 29

[manojd]

On comment 15: "You don't know ahead of time if the javascript: link is
functioning as a dynamic link, as a link-that-opens-in-a-new-window, or if it
just makes a small change in the page.": Actually, most of the time I do know -
at least for links I care about. Human readable context provides enough info.
And for sites using this as a navigation tool, I will at most botch up once
interactively to learn the difference!

Also I filed bug#157082 today - not just Javascript, it happens to be a problem
with pages that use Flash too.

Comment 30

[Jesse Ruderman]

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

Comment 31

[Serge Gautherie (:sgautherie)]

I support the idea that opening a new tab/window which displays nothing is
worthless (to say the least);

Then, I would prefer a "do nothing" approach, possibly with a message, as a
dialog, or temporarily on the status bar.

I would rather not support a too complicated/unexpected behaviour:
simply test for (any) "javascript:"; and let the user know.

Comment 32

[Alfonso Martinez]

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

Comment 33

[Jason Kennerly]

Cloning the window does make sense, even if the javascript merely produces a
small change rather than opening a dynamic link. The reason for this is obvious:
the user WANTS the change to appear in a new window so that the contents of the
current window remain UNCHANGED. Hence, cloning the window is the way to go.

Strange that the bug didnt show up in the search when I tried to locate it
before reporting it. 

Comment 34

[Alfonso Martinez]

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

Comment 35

[Ron Arts]

I not really sure if this really is a dupe of Bug 201003. 

When a user clicks on a Javascript link (or in my case, chooses
an option from a SELECT box that does onchange=location.href=...)
AND she holds down Ctrl while doing it, a new tab does NOT open.
I think this qualifies as a bug instead of a RFE, because 
this is unexpected behaviour.

In fact one of my co-workers in accounting was the one who
brought this problem to my attention. She suffers from
RSI and learned to use tabs extensively. she was annoyed by
the fact that she 'couldn't let the dropdown open in another tab'.

Maybe this bug should be treated as separate anyway?

Comment 36

[Pham]

.

Comment 37

[Vaclav Dvorak]

I don't know if this has been proposed before, so sorry if this is redundant...

I see a solution in combination with bug 64560. That bug requests an ability (a
pref, actually) to override window.open to just go to the given URL instead of
opening it in a new window. Once that is implemented, we could use it in
combination with the window-cloning approach that was already mentioned here in
comment 0, but has the problem of potentially opening _two_ new windows, as
mentioned in comment 6.

So when a user middle-clicks a JavaScript link, the browser would:
1) clone the current window
2) temporarily override window.open to just follow the link (bug 64560)
3) run the JavaScript of the link that was clicked
4) restore original window.open functionality (unless, of course, the original
functionality _is_ to just follow the link, using the pref that will hopefully
be implemented in bug 64560).

How about that?

Funny, BTW, that the capability to open a JS link in a new window would thus
depend on the capability to open it in the same window. :-)

Comment 38

[Sebastian Wittmeier]

Hi Vaclav,

> How about that?

Great! I wanted to suggest some heuristics, but you have perfectly defined the
right behaviour.
I vote for this bug and hope someone clears the FUTURE flag.

Sebastian

Comment 39

[Boris Zbarsky [:bzbarsky]]

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

Comment 40

[Anthony Lieuallen]

In reply to comment #21:

> So now we have three or four proposed results on middle-button-click on
> javascript link:
> a. do nothing
> b1. "pop up cloned window and treat as left click"
> b2. guarantee that one new window is created with the new contents
> c. treat as left click

I believe, well first that this needs to be fixed.  This significantly breaks
tabbed browsing, arguably the number 1 feature that Firefox offers.

Then, I would go for option C.  It should do one of two things:
- Pop up a "one time" (disable-able) box, like when you submit a form the first
time, or redirect from https to http.
- Add a new preference to enable simply disabling "new tab/window" functionality
when a link is middle/control/right and choose new tab/window clicked. 
Essentially make it left clicked.

Much more complicated functionality like discussed in many comments would be
divine (bookmarklets who can display results in current or new tab based on
click) but unfortunately not practical.  The browser can't know what a script
does before executing it, and cannot alter its behavior based on that.

Comment 41

[Nickolay_Ponomarev]

Now that the ability to divert links that open in a new window is implemented,
it seems like comment 37 is the most sane way to implement this RFE. But then
there still are problems with cloning tab's contents.

While I'm spamming this bug, are <a onclick="..." href="#"> links are part of
this bug or separate? What about <a onclick="..." href="something.html">? (See
also bug 156137.)

Comment 42

[Hixie (not reading bugmail)]

Tabs and Windows should work equivalently. Resummarising.

Comment 43

[Hixie (not reading bugmail)]

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

Comment 44

[Ben Ruppel]

Note that bug 138198 asked for option (C) from comment #21.  That bug has 111
votes and this bug has only 60 total.  

Comment 45

[Simon Ruggier]

(In reply to comment #44)
> Note that bug 138198 asked for option (C) from comment #21.  That bug has 111
> votes and this bug has only 60 total.  
I don't think so, I thought it was asking for b1, which is what I would ask for.

Either way, I'm frustrated with some of the overly complex solutions people have
suggested to the problem, which assume that if a solution opens up any
situations that are considered nonoptimal(like a cloned page opening up a new
window), the solution is bad.  Seems to me that trying to interpret what
javascript will do and act accordingly is futile and impossible, because the
expected behaviour will differ depending on the user, and the complexity rapidly
increases once a solution requires interpreting javascript code (see comment 23).  

Right now, I consider the problem of script opening new windows to be a wholly
separate problem from javascript links not working when opened in new windows
and tabs.  The new windows problem has been dealt with.  This problem still
needs to be dealt with, and from the perspective of a few of us, judging from
the comments, the expected behaviour is clear: a javascript link opened in a new
tab should result in a tab that is identical to what the current tab would have
looked like if the link had been left clicked. This is because the point of
opening a link in a tab is to preserve the current page.  Note that part of
doing this would include making this happen with bookmarklets too, it still
makes sense in that case.

Conveniently, this behaviour is described in the description filed with the bug.
 If you ask me, implementing this behaviour would be a monumental feature, one
that would set Firefox apart from other browsers, and make my life much easier.
 Just as an example, the University I attend has a strong co-op program, with
everyone in the engineering faculty required to do co-op, and various other
faculties taking part.  However, the online system that is used to help students
apply to jobs is hardly usable, with everything being done through post
operations, breaking even the back button.  This means that after viewing a job,
each user must go back to the search page, query their search again (slowly),
possibly navigate through the paged search results, and then view the next job.
 If this bug were solved as seen above, this site, among others, would work
properly, allowing users to view jobs quickly, without going through that cycle.
 At the very least, it would mean a significant number of people using Firefox
at my school alone just for this one reason.

I realize this comment is a bit large, but basically, my point is to keep it
simple, and that the expected behaviour is already in the bug description.

Simon

Comment 46

[Worcester12345]

See if this extension does what you want.
http://www.spuler.us/extensions/singlewindow.htm

If so, find out how they did it and get that code in here quick. This bug is 5
YEARS OLD!

Comment 47

[Andrew Schultz]

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

Comment 48

[Simon Ruggier]

(In reply to comment #46)
> See if this extension does what you want.
> http://www.spuler.us/extensions/singlewindow.htm
> 
> If so, find out how they did it and get that code in here quick. This bug is 5
> YEARS OLD!

I think that behaviour is already implemented in the nightlies, though I haven't
tested it out.  In any case, it's a solution to a different problem.

Simon

Comment 49

[Ethan Sprang]

(In reply to comment #48)
> (In reply to comment #46)
> > See if this extension does what you want.
> > http://www.spuler.us/extensions/singlewindow.htm
 
> it's a solution to a different problem.

The "Single Window Extension" prevents javascript from openning a new *window*
by diverting that window into a new tab.  However, it does not prevent
javascript from opening a link into the current tab (i.e. overwriting the
current tab).  What is wanted is a fix (or extension) that allows the user to
force a javascript-opened page (one that would appear in the current tab,
overwriting the currently-viewed page) to appear into a new tab.

This bug is very annoying.  
It has 100+ votes.  
It is the oldest bug listed in the nightly "confirmed bug list."  
It's 5 years old.  
Geez...

Comment 50

[War59312]

I hope this is fixed soon. Can't believe five years have pasted all ready.

Comment 51

[timeless]

well, i hope you can fix it, because it's not an easy thing to do.

Comment 52

[Worcester12345]

I have seen the "Singlewindow" extension listed as a possible fix for at least
3-5 bugs here, probably more. Maybe it is time to look at incorporating that
code into the Mozilla/Firefox code base.

Comment 53

[Ian Macfarlane]

Single window mode was added to Firefox 1.0, but it's turned off by default.

http://www.squarefree.com/burningedge/releases/1.0.html

Comment 54

[Ethan Sprang]

(In reply to comment #53)
> Single window mode was added to Firefox 1.0, but it's turned off by default.
> 
> http://www.squarefree.com/burningedge/releases/1.0.html

As noted above (#49) Single Window mode is NOT a solution when faced with a
Javascript link that opens new content IN THE SAME TAB.  What users want is to
be able to open that new content in a new tab and leave the current tab unchanged.

See posts 21, 27, 35, 40, and 45.

Comment 55

[Justin Kerk]

Another important concern is that even for Javascript links that open in new
tabs thanks to single window mode, middle-clicking on the links doesn't work, as
described in comment #0.

Comment 56

[Kevin Brosnan]

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

Comment 57

[Worcester12345]

(In reply to comment #53)
> Single window mode was added to Firefox 1.0, but it's turned off by default.
> http://www.squarefree.com/burningedge/releases/1.0.html

I'm pretty sure the Single Window extension goes above and beyond the "single 
window mode" in even current nightly firefox builds. Unfortunately, there seems 
to be a compatibility problem with nightly trunk builds now I think.

Comment 58

[Jaime Mitchell (use [e-mail] for email)]

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

Comment 59

[Jos Vermeulen]

There's an extension that fixes this for the most links. Maybe take a look at
the code?

http://forums.mozillazine.org/viewtopic.php?t=303799

Comment 60

[Andy Lanzone]

Attachment: Patch to browser.js that updates the contentAreaClick() function

I wrote the extension mentioned in comment #59.  This patch add the extension's
functionality to the contentAreaClick() function in browser.js.  Tested
successfully in Deer Park Alpha 2.

Comment 61

[James Ross]

Man that's a lot of (what seems like) very hacky hacks. Could you perhaps 
explain in detail what it is doing, and *why* each bit is needed? (I'm sure you 
spent a lot of time making ti work well, but I'll be damned if I can see how it 
even works at all)

Comment 62

[Andy Lanzone]

> Could you perhaps explain in detail what it is doing, and *why* each bit is 
> needed?

The code started off as an extension, so it doesn't do anything fancy.  It just
captures the click and parses the href attribute of the link.

First it ensures the click was a middle click, then checks the link.  If the
link contains 'javascript:' or ends with '#' it will try to parse the link;
otherwise things continue as normal.  

If the link contains the string 'javascript:', the 'if (is_js != -1)' block is
entered.  These links usually look like "javascript:open('target link','other
stuff')", so it tries to extract the 'target link' part [rawHref].  If
successful, it cleans the link up using fixupAURL() and opens the link
[handleLinkClick].

If it can't extract the 'target link', the javascript may be of the form
javascript:void(0) with an onclick attribute of onclick="window.open('target
link');".  The link's onclick attribute is checked [else if
(wrapper.getAttribute("onclick"))] to see if it exists.  If the onclick
attribute exists, the code tries to extract a link from it like above.  If both
extractions (href and onclick) fail, then it gives up.

The other type of javascript link ends in '#' and has uses an onclick value.  If
the link's href ends with '#', the 'else if (pound == '#')' block is entered. 
In this block, the code checks the onclick attribute and tries to extract a
link.  Like the code above, if it finds a link (rawHref), it cleans it up with
fixupAURL() and opens the link [handleLinkClick].

The fixupAURL(aURL) is a subroutine that makes sure a link 'aURL' is of the form
"http://host.com/path/url".  If aURL is already of that form, it immediately
returns aURL.  Otherwise, if aURL is a local path (e.g.
'/cgi-bin/getmsg?msg=MSG123' like at Hotmail) it must add the appropriate host
and path values to construct a proper link.

Hope that helps.

Comment 63

[Anish Patel]

(In reply to comment #62)
Works great for most sites... but I did find an error case with the Smart Middle
Click

1) go to http://www.cnn.com/
2) click on a javascript link in the "Watch free video" section on the right.

Notice that the new tab is created, but the wrong argument is captured by the
plugin.

Comment 64

[Worcester12345]

(In reply to comment #62)
> > Could you perhaps explain in detail what it is doing, and *why* each bit is 
> > needed?
> 
> The code started off as an extension, so it doesn't do anything fancy.  It just
> captures the click and parses the href attribute of the link.
> 
> First it ensures the click was a middle click, then checks the link.  If the
> link contains 'javascript:' or ends with '#' it will try to parse the link;
> otherwise things continue as normal.  
> 
> If the link contains the string 'javascript:', the 'if (is_js != -1)' block is
> entered.  These links usually look like "javascript:open('target link','other
> stuff')", so it tries to extract the 'target link' part [rawHref].  If
> successful, it cleans the link up using fixupAURL() and opens the link
> [handleLinkClick].
> 
> If it can't extract the 'target link', the javascript may be of the form
> javascript:void(0) with an onclick attribute of onclick="window.open('target
> link');".  The link's onclick attribute is checked [else if
> (wrapper.getAttribute("onclick"))] to see if it exists.  If the onclick
> attribute exists, the code tries to extract a link from it like above.  If both
> extractions (href and onclick) fail, then it gives up.
> 
> The other type of javascript link ends in '#' and has uses an onclick value.  If
> the link's href ends with '#', the 'else if (pound == '#')' block is entered. 
> In this block, the code checks the onclick attribute and tries to extract a
> link.  Like the code above, if it finds a link (rawHref), it cleans it up with
> fixupAURL() and opens the link [handleLinkClick].
> 
> The fixupAURL(aURL) is a subroutine that makes sure a link 'aURL' is of the form
> "http://host.com/path/url".  If aURL is already of that form, it immediately
> returns aURL.  Otherwise, if aURL is a local path (e.g.
> '/cgi-bin/getmsg?msg=MSG123' like at Hotmail) it must add the appropriate host
> and path values to construct a proper link.
> 
> Hope that helps.

Cool. "Make it so." (-:

Comment 65

[Bradley Chapman (not reading bugmail, still gone but not forever)]

TBP uses the same fixupAURL() function to canonicalize URLs for its tab-locking
feature. Wouldn't makeURLAbsolute() be a better choice?

Comment 66

[Jesse Ruderman]

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

Comment 67

[flock31070]

I think Opera can do this

Comment 68

[Ian Macfarlane]

If Opera does this, does anyone know how they do it?

Comment 69

[Ivan Ičin]

Opera can't do this.

There is Firefox extension called Smart middle click which does this. I had no problem using it for a long time, so probably it should be implemented in core.

Anyway, I think that things like "opera might be doing this" and then "how opera does this if it does it anyway" are bug spam.

Comment 70

[flock31070]

Oops:P
I was thinking of when Opera automatically opened links that open in a new window to open in a new tab, which Firefox 1.5 does now.

Comment 71

[Worcester12345]

(In reply to comment #46)
> See if this extension does what you want.
> http://www.spuler.us/extensions/singlewindow.htm
> 
> If so, find out how they did it and get that code in here quick. This bug is 5
> YEARS OLD!

Has anyone looked into how this extension works, and if that code could be used here? Anyone know if that extension STILL works with current version(s) of the browser? Worth investigating.

Comment 72

[Simon Ruggier]

(In reply to comment #71)
> (In reply to comment #46)
> > See if this extension does what you want.
> > http://www.spuler.us/extensions/singlewindow.htm
> > 
> > If so, find out how they did it and get that code in here quick. This bug is 5
> > YEARS OLD!
> 
> Has anyone looked into how this extension works, and if that code could be used
> here? Anyone know if that extension STILL works with current version(s) of the
> browser? Worth investigating.
> 

The point of that extension is to guarantee that any links that open in a new window will open in a new tab instead, which allows all browsing to be done in a single window.  This behaviour is already implemented in both 1.07 (the showSingleWindowModePrefs setting must be enabled in the about:config page to unhide the option), and in 1.5.

On the other hand, the point of this bug is to give a guarantee that a link can be opened in a new tab or window, even if it is a javascript link that opens in the same tab.  This allows the user to preserve the page they are viewing if they want to follow such a link.

Comment 73

[Worcester12345]

(In reply to comment #72)
> (In reply to comment #71)
> > (In reply to comment #46)
> > > See if this extension does what you want.
> > > http://www.spuler.us/extensions/singlewindow.htm
> > > 
> > > If so, find out how they did it and get that code in here quick. This bug is 5
> > > YEARS OLD!
> > 
> > Has anyone looked into how this extension works, and if that code could be used
> > here? Anyone know if that extension STILL works with current version(s) of the
> > browser? Worth investigating.
> > 
> 
> The point of that extension is to guarantee that any links that open in a new
> window will open in a new tab instead, which allows all browsing to be done in
> a single window.  This behaviour is already implemented in both 1.07 (the
> showSingleWindowModePrefs setting must be enabled in the about:config page to
> unhide the option), and in 1.5.
> 
> On the other hand, the point of this bug is to give a guarantee that a link can
> be opened in a new tab or window, even if it is a javascript link that opens in
> the same tab.  This allows the user to preserve the page they are viewing if
> they want to follow such a link.
> 

I guess what needs to happen is to just improve the interface so people can easily set it to work in any combination of those ways which best suits their browsing needs. Until then, the SingleWindow extension is all we have. Even then, the extensions and themes and downloads managers don't respect those preferences, but that is also another bug.

Comment 74

[Ethan Sprang]

It appears this bug disappeared from the daily Official Trunk Build threads list of bugs back in August.  Doing a search on the forums shows no mention of it since then.  Has the bug been inadvertently overlooked, deliberately ignored, or resolved?

Comment 75

[Simon Ruggier]

(In reply to comment #73)
> (In reply to comment #72)
> > (In reply to comment #71)
> > > (In reply to comment #46)
> > > > See if this extension does what you want.
> > > > http://www.spuler.us/extensions/singlewindow.htm
> > > > 
> > > > If so, find out how they did it and get that code in here quick. This bug is 5
> > > > YEARS OLD!
> > > 
> > > Has anyone looked into how this extension works, and if that code could be used
> > > here? Anyone know if that extension STILL works with current version(s) of the
> > > browser? Worth investigating.
> > > 
> > 
> > The point of that extension is to guarantee that any links that open in a new
> > window will open in a new tab instead, which allows all browsing to be done in
> > a single window.  This behaviour is already implemented in both 1.07 (the
> > showSingleWindowModePrefs setting must be enabled in the about:config page to
> > unhide the option), and in 1.5.
> > 
> > On the other hand, the point of this bug is to give a guarantee that a link can
> > be opened in a new tab or window, even if it is a javascript link that opens in
> > the same tab.  This allows the user to preserve the page they are viewing if
> > they want to follow such a link.
> > 
> 
> I guess what needs to happen is to just improve the interface so people can
> easily set it to work in any combination of those ways which best suits their
> browsing needs. Until then, the SingleWindow extension is all we have. Even
> then, the extensions and themes and downloads managers don't respect those
> preferences, but that is also another bug.
> 

Well no, I would say that extension's pretty much obsolete, since its goal is fulfilled by the core browser already.  If you want to unhide the built in prefs in the 1.0 branch of Firefox, see http://kb.mozillazine.org/Suppress_new_windows for easy instructions, which are simpler and than installing the extension, and change less.

With regard to configuration windows being separate, that's not a bug, it's an intentional decision.  Those windows are not browser windows, and as such would not even belong in a tab in the first place.  Also, in 1.5, the single window mode feature has been refined so that it only forces full webpages into new tabs, so that small dialogs still pop up as intended by the website authors.

That being said, the above issue is still completely unrelated to this bug.

Simon

Comment 76

[Ivan Ičin]

I would like to strongly suggest that this is not the place to ask if you don't which extension does what, but as so many people beat around the bush, here is URL of extension that mostly solves this problem:

http://www.extensionsmirror.nl/index.php?showtopic=4027

If you middle click javascript link it opens a correctly new tab. It has some bugs though, so if javascript does something else but opens new tab, it will still open new tab and do nothing (well I believe it is a bug). But I think it is still much better than current behaviour.

There was the question whether it is compatible with Firefox 1.5RC2, and the answer is yes.

Comment 77

[Imre Péntek]

as I said it previously when the link is clicked you can store (even in a single bit) if ctrl key (or any other modify key to signal that the user wants to "pop up" new tabs instead of windows) was pressed, and when javascript code reaches any_javasript_function_that_pops_up_a_window() (sorry I haven't even used javascript) then just check that one bit and act accordingly.

Comment 78

[Imre Péntek]

and I can't find showSingleWindowModePrefs in my Mozilla/5.0 (X11; U; Linux i686; hu-HU; rv:1.7.12) Gecko/20051104

Comment 79

[Worcester12345]

(In reply to comment #75)
> (In reply to comment #73)
> > (In reply to comment #72)
> > > (In reply to comment #71)
> > > > (In reply to comment #46)
...
> 
> With regard to configuration windows being separate, that's not a bug, ...

Here's the bug:
Bugzilla Bug 262575

Comment 80

[Simon Ruggier]

(In reply to comment #79)
> (In reply to comment #75)
> > (In reply to comment #73)
> > > (In reply to comment #72)
> > > > (In reply to comment #71)
> > > > > (In reply to comment #46)
> ...
> > 
> > With regard to configuration windows being separate, that's not a bug, ...
> 
> Here's the bug:
> Bugzilla Bug 262575
> 

Oh, whoa, I totally misunderstood what the issue was; yes, that is a bug.

With regard to #77, that isn't what this bug is about either, if the script pops open a new window, it can already be forced into a tab... The point of this bug is to route script links that do not pop up new windows into new tabs or windows.

As for the hidden prefs, check the link I sent, otherwise, I don't know, sorry.  I can say that it definitely worked for me before I upgraded though.

Comment 81

[Jesse Ruderman]

Comment 77 is part of what this bug is about.  See comment 23.

Comment 82

[Simon Ruggier]

(In reply to comment #23)
> I still think my comment #5 would be the most useful and least confusing 
> behavior.
> 
> - If the link sets document.location, channel the load into a new window and 
> halt the javascript execution.
> - If the link calls window.open(), allow it to open the window (even if the 
> user has set restrictions on pop-up windows), but make sure it opens in *new* 
> window rather than replacing a named window or frame by ignoring the second 
> parameter to window.open().
> - If the link simply modifies part of the page, let it modify the page (don't 
> open a new window).
> - If the link returns a value (eg javascript:5), open that value in a new 
> window as data:text/html,5.

(In reply to comment #81)
> Comment 77 is part of what this bug is about.  See comment 23.
> 

No, offence, but I've disagreed with your comment in previous comments of mine, and my opinion is still the same.  I think that one of the fundamental characteristics of opening a link into a new tab or window is that it preserves the original page.  Of course, if there's an event that handles the middle clicking, then it can still screw this up for regular links.  However, the original bug description clearly implies that the original page should be preserved, and I agree.

Sorry about the difference of opinions, but it's open to debate.

Comment 83

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

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

Comment 84

[David E. Ross]

Mozilla/5.0 (Windows; U; Win98; en-US; rv:1.8.0.1) Gecko/20060130 SeaMonkey/1.0

See comment #70.  SeaMonkey does this, too.  If I select a Javascript link with the left button of my mouse, link now opens in a new tab instead of in a new window.  For "Link open behavior", my preference is set to "A new tab in the currect window".  

I know this isn't quite what the RFE in this bug report indicates.  However, it is a definite improvement.  

Comment 85

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

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

Comment 86

[Elizabeth Lawson]

I heard that this is the bug that stops hotmail and any links on msn messenger from opening in Firefox. This is the only thing that has stopped me from switching to firefox as I use hotmail and msn execessively. I will happily switch once this bug is fixed.

Comment 87

[Worcester12345]

(In reply to comment #86)
> I heard that this is the bug that stops hotmail and any links on msn messenger
> from opening in Firefox. This is the only thing that has stopped me from
> switching to firefox as I use hotmail and msn execessively. I will happily
> switch once this bug is fixed.
> 

Now I am wondering if this is what keeps killing www.mail2web.com for me. I have no problems when using IE. Thanks for the heads up.

Comment 88

[Mike Shaver (:shaver -- probably not reading bugmail closely)]

Not a 1.8.1 blocker.

Comment 89

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

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

Comment 90

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

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

Comment 91

[Worcester12345]

(In reply to comment #4)
> Not that much related to bug 22775.  The middle button behaviour is 
> Unix-specific; the requested functionality could be achieved eg. on Windows by 
> right-clicking and selecting an appropriate menu item.
> 
> Adjusting summary, lowering severity to 'enhancement', changing Platform/OS to 
> All/All and removing dependency on bug 22775.


I think he meant Bugzilla Bug 277754 "Firefox opens external links in a new window instead of a new tab as specified in Options"



Other similar sounding bugs:
Bugzilla Bug 187915 Don't open a blank tab for downloads from Command-clicked
link

Bugzilla Bug 266583 additional tab opened when ctrl+clicking a link which opens
another window

Comment 92

[Jon B]

Why is this listed as an "enhancement"?  It is a major functionality problem.  Javascript "new window" links cannot be opened in a new tab, while every other link can.

Comment 93

[Phil Ringnalda (:philor)]

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

Comment 94

[Anders Conbere]

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

Comment 96

[John]

Internet Explorer 7 does this just fine. Not sure about Opera.

Comment 99

[Takanori MATSUURA]

Attachment: fit attachment 192209 to the latest trunk

Comment 100

[War59312]

Awesome!!

Comment 101

[Worcester12345]

(In reply to comment #0)
> Unfortunately, it has become increasingly common for sites to abuse JavaScript
> in various horrible ways.  The site http://www.svd.se/ is a good example: to get
> to *ANY* article, you go through a JavaScript link instead of using plain, old,
> usable links.

This example is no longer true. I see in comment 99 that there is an attachment, but this doesn't seem quite working yet in trunk for me.

Comment 102

[Dotan Cohen]

I would like to reinforce the reason that one would middle click a link. When one clicks a link, he expects that the page will change. Maybe a new page will be loaded, maybe some AJAX will happen, maybe a display:none item will be shown || hidden, but he expects something to change.

Often, a user wants that change to take place (he wants the new page, for instance), however in addition to the change he would like to preserve the current page status for whatever reason. This is why he middle-clicks. His current tab stays how it is, yet the updated || changed || new page is displayed in another tab.

The best way to get this behaviour is, upon a middle clicking a JS link, to clone the current tab (I will refer to this as tab 1), then perform the JS on the new tab (I will refer to this as tab 2). In the event that the javascript makes no changes to the current tab (tab 2) yet ONLY makes a new tab, then that new tab will be loaded in tab 2.

#!/my/imagination/psuedo-code

// User middle-clicks link

if (link==JS) {

    // open new tab

    if (JS makes any changes to the current tab) {
        // Run the JS in the new tab, and open any other tabs
        // that the JS wants to open in yet another tab
    } else {
        // treat second tab as the JS's new tab, and load in
        // it what JS wants to load.
    }

} else {
    // Do what is normally done with links
}

Comment 104

[Alan D Winter]

"Open a JavaScript link in a new window" (or new tab) 

Anything will do. At present to open the link 

(e.g javascript:__doPostBack('linkBtnElec','')

 I have to go to "View page in IE tab" to get the javascript link to open at all. This isn't good enough. 

Comment 105

[Simon Ruggier]

That sounds like a separate issue.

Comment 106

[me639241]

Nearly 8 years have passed since the report of this bug, and a simple JS link support has still not been successfully added into new Firefox 3.0. FF opens empty tabs instead (and without warning! Not good if you open tabs in the background!). 

There are 180 votes for solving this bug already, I think it should be considered to comply with the request for inclusion. - It ranks #13 of the top voted bugs -

The Smart Middle Click Extension has not (yet?) been updated for FF3 btw.

Comment 107

[Christopher Weber]

Will this ever be fixed? 

I offer 20 Euro for the first person to submit code that gets this problem fixed which actually gets accepted into Firefox. 10 Euro for a working addon. Payment via paypal.

Comment 108

[David Baron :dbaron: (⌚️UTC-4, no longer working on Mozilla)]

I think the right way to fix this is by fixing bug 335963, rather than by hacking yet another case into browser.js.

Comment 112

[GDur]

when the bug is known as so long, why the bug is not already fixed?...
i hoped that the bug will be fixed soon.

can pleasy somebody who's authorizes say where the problem is?

Comment 114

[Skippy le Grand Gourou]

Oldest. Bug. Ever.

Comment 116

[Ria Klaassen (not reading all bugmail)]

Fixing this bug would be a great improvement. Some (but unfortunately not all) webmasters improve their code if you complain.

Comment 117

[GDur]

for my webstie i use a workaound i invented:
http://gdur.cerebrumsoft.org/fusiondog/

i use real(normal) links like :
<a href='http://dict.leo.org' id='12' class='links'>Leo</a>

and then i manipulate them with javascript dynamicly:
for (lalala)
{
document.getElementById(i).href = websites[i][1] + websites[i][2] + document.getElementById("label").value;
}

so i solved the problem...it works fine..i hope i could help u all

Comment 118

[Worcester12345]

(In reply to comment #0)
> Unfortunately, it has become increasingly common for sites to abuse JavaScript
> in various horrible ways.  The site http://www.svd.se/ is a good example: to get
> to *ANY* article, you go through a JavaScript link instead of using plain, old,
> usable links.
> 
> Unfortunately, this breaks the middle mouse button, which is supposed to open
> the link in a new window.
> 
> It would be nice if the middle button in the presence of such a link would clone
> the window currently in, and then activate the link, to simulate the proper
> behaviour.

Looks like they fixed your site. Here is a new one to test on:

http://support.asus.com/

Comment 119

[Johnny Stenback (:jst)]

Reassigning to smaug who will investigate what other browsers do to help here, if anything, and to see what we *can* do to make this work better. But for the record, there are cases where we simply can not fix this w/o support for complete window cloning, current JS state n' all, which needless to say isn't a small task at all. And if it turns out that this is simply not realistically fixable, we'll wontfix this bug. Either way, we'll try to figure this out for 1.9.3.

Comment 120

[Ben Bucksch (:BenB)]

Re "window cloning": Don't we already do that when you go Back? AFAIK, we cache the page including all its DOM and presentation frames and JS state. The onload does not fire, yet the page works fine.

Comment 121

[Boris Zbarsky [:bzbarsky]]

There's a difference between caching something (just don't delete it) and cloning it (make a working copy).

Comment 122

[Worcester12345]

Another good test site (try to right click the picture to open in a new window or tab):

http://telegram.com/article/20100607/NEWS/6070323/1101

Comment 123

[Olli Pettay [:smaug][[e-mail]]]

So, based on my testing IE8 prevents "open in new window" in the context menu
for javascript: links. Ctrl+click works like a normal click.

Safari and Chrome seem to have the same behavior as IE8 - they just ignore the
ctrl if the link is javascript:

Opera 10.5x seems to have the same behavior as FF trunk, except that it shows
"Open in new window" in the context menu. Ctrl+click runs the script in the
new window/tab and depending on the script something reasonable may or may not
happen.

I like neither of the behaviors. Either ctrl+click/open-new-window should just 
work, or nothing should happen.

What is explained in comment 23 is doable though. I'll try that approach to
see how well it works. I may post links to tryserver builds later - in
a few days - if it works reasonable well.

Comment 124

[David Baron :dbaron: (⌚️UTC-4, no longer working on Mozilla)]

Also see the proposal in bug 335963.

Comment 125

[Olli Pettay [:smaug][[e-mail]]]

Attachment: patch

So this patch should fix (remove) support for ctrl+click on javascript links.
IMHO, there isn't really anything better we can do, at least not without
major changes which would allow us to clone DOM windows and documents etc.

Comment 23 would make us just work inconsistently depending on what the script is
doing.

And I don't really see any proposal in Bug 335963.

Comment 126

[Olli Pettay [:smaug][[e-mail]]]

Attachment: patch

Comment 127

[David Baron :dbaron: (⌚️UTC-4, no longer working on Mozilla)]

(In reply to comment #125)
> And I don't really see any proposal in Bug 335963.

The idea is that "Open in New Window" / "Open in New Tab" on javascript links would run the javascript in the page, but redirect any window.open (which would be exactly the window.open calls allowed by the popup blocker) or any page navigation to the new window or tab as requested.

Comment 128

[Olli Pettay [:smaug][[e-mail]]]

(In reply to comment #127)
> The idea is that "Open in New Window" / "Open in New Tab" on javascript links
> would run the javascript in the page, but redirect any window.open (which would
> be exactly the window.open calls allowed by the popup blocker) or any page
> navigation to the new window or tab as requested.

Why *any*? What if the script is calling window.open in some other window.
Or in an iframe? It would be very difficult to get any consistent and
reasonable handling, IMO.
Actually, how is <a href="javascript:..."></a> any different than
<span onclick="..."></span>.

Comment 129

[David Baron :dbaron: (⌚️UTC-4, no longer working on Mozilla)]

(In reply to comment #128)
> (In reply to comment #127)
> > The idea is that "Open in New Window" / "Open in New Tab" on javascript links
> > would run the javascript in the page, but redirect any window.open (which would
> > be exactly the window.open calls allowed by the popup blocker) or any page
> > navigation to the new window or tab as requested.
> 
> Why *any*? What if the script is calling window.open in some other window.
> Or in an iframe? It would be very difficult to get any consistent and
> reasonable handling, IMO.

Why not any?  If the page does that, and we can open it in what the user wanted, that's good.

> Actually, how is <a href="javascript:..."></a> any different than
> <span onclick="..."></span>.

It isn't.

Comment 130

[Olli Pettay [:smaug][[e-mail]]]

(In reply to comment #129)
> Why not any?  If the page does that, and we can open it in what the user
> wanted, that's good.
So if the web page does something like frames[0].contentDocument.location = "foo.html", that foo.html would be opened in a new tab?
But that would easily break web site, since window.parent wouldn't
point to the right window. 


> > Actually, how is <a href="javascript:..."></a> any different than
> > <span onclick="..."></span>.
> 
> It isn't.
So you want that we have some state when handling ctrl+click in general, 
not just when handling ctrl+click on a link.
Nothing to do with Bug 335963 then, if I understand that bug correctly.

Comment 131

[David Baron :dbaron: (⌚️UTC-4, no longer working on Mozilla)]

(In reply to comment #130)
> (In reply to comment #129)
> > Why not any?  If the page does that, and we can open it in what the user
> > wanted, that's good.
> So if the web page does something like frames[0].contentDocument.location =
> "foo.html", that foo.html would be opened in a new tab?
> But that would easily break web site, since window.parent wouldn't
> point to the right window. 

We already support "Open in New Window/Tab" for the equivalent <a href="" target="">link</a>, though.  Sometimes pages don't work in new windows/tabs.

Comment 132

[Dotan Cohen]

> Sometimes pages don't work in new windows/tabs.

Furthermore, from my experience as a heavy web surfer, the use of pages updating their parent pages via javascript is at least three orders of magnitude less common than pages which abuse Javascript links. I cannot even think of a specific example in recent years. Can someone provide a use case of parent-controlling on any modern website?

In any case, like more people (and the Firefox default) I block popups, so for all practical purposes there is no more "parent page to update via javascript" use case anymore.

Comment 133

[Olli Pettay [:smaug][[e-mail]]]

(In reply to comment #132)
> ... so for
> all practical purposes there is no more "parent page to update via javascript"
> use case anymore.
Sure there is, frames/iframes
data:text/html,<iframe onload="alert(window.parent.location)">

Comment 134

[Dotan Cohen]

> Sure there is, frames/iframes

Exactly, thanks!

The "parent window" to be changed should always be the newest tab opened. Users opened the link as a middle click precisely because they don't want the page altered.

Comment 135

[Ben Bucksch (:BenB)]

While frames usually don't modify their parents, they quite often need read *access* to their parents, to get information. Either to reuse JS functions (to not load them all again) or to get the ID of the product to display or whatever. So, it is important to get this right technically, but as you say yourself is not a problem for the user.

Comment 136

[Olli Pettay [:smaug][[e-mail]]]

So for FF4, I think we shouldn't do more than make the UI work consistently.
And the patch should do that.

Comment 23 leaves still way too many cases undefined.

Comment 137

[Johnny Stenback (:jst)]

Per discussion with Olli and others we can not block on this bug, which is essentially unfixable. I'll gladly approve a patch that does what Olli outlines above, but I think we'll have to stop there, at least for now.

Comment 138

[Alex Limi (:limi) — Firefox UX Team]

(In reply to comment #123)
> So, based on my testing IE8 prevents "open in new window" in the context menu
> for javascript: links. Ctrl+click works like a normal click.
> 
> Safari and Chrome seem to have the same behavior as IE8 - they just ignore the
> ctrl if the link is javascript:
>
> I like neither of the behaviors. Either ctrl+click/open-new-window should just 
> work, or nothing should happen.

Agreed. If we can't open a new window reliably for these cases, we shouldn't allow it at all.
 
> What is explained in comment 23 is doable though. I'll try that approach to
> see how well it works. I may post links to tryserver builds later - in
> a few days - if it works reasonable well.

Worth a try, indeed.

Comment 139

[Andrea]

I wrote an UserScript that fixes this problem: http://userscripts.org/scripts/show/91986 (requires Firefox 4)

Comment 140

[Shad Sterling]

Noting related bug 688985 - "Open Link in New Tab" from context menu or from modifier-click should do the same thing.

Comment 141

[Alex Limi (:limi) — Firefox UX Team]

Comment on attachment 471526 [details] [diff] [review]
patch

My C++ isn't very good, but if what this does is to disable the opening of a new tab when Ctrl/Cmd-clicking a javascript: link (and disable the context menu that does the same), I'm +1 on this one.

Comment 142

[Dotan Cohen]

That looks like an effective, simple patch. Nice, Alex!

I recommend that the patch be updated to handle the case-insensitive sting "javascript:", though. Note that the patch will only affect links for which the "javascript:" declaration is in the href itself, it will not affect links that have events configured for them. However, it is better than nothing and until the general case is handled, Alex's patch would be a welcome addition.

Comment 143

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

Comment on attachment 471526 [details] [diff] [review]
patch

This is bitrotten by bug 586234. It seems like it would be easier to just add an early-return to handleLinkClick, rather than adding checks in most of its code paths. I don't think handleLinkClick needs to handle javascript: URIs at all.

Comment 144

[L A Walsh]

Alex -- this bug does exactly that -- when you want to click on a jscript link, and have it open in another window, you can't.  It's a pain in the but sometimes to be forced to rt-click on it, which takes you off of a window that you sometimes can't get back to (pressing back and FF  says it has to resend data, which changes the page).

Comment 145

[Worcester12345]

Here is another site to use for an example:
http://www.wtag.com/main.html

Try any of the links on the left.

Comment 146

[Worcester12345]

(In reply to Worcester12345 from comment #145)
> Here is another site to use for an example:
> http://www.wtag.com/main.html
> 
> Try any of the links on the left.

That one seems changed or fixed or whatever.

Here is another test case:
https://www.primaryarms.com/SearchResults.asp?Search=carry+handle+mount

Comment 147

[L A Walsh]

(In reply to Worcester12345 from comment #146)
> (In reply to Worcester12345 from comment #145)
> > Here is another site to use for an example:
> > http://www.wtag.com/main.html
> > 
> > Try any of the links on the left.
> 
> That one seems changed or fixed or whatever.
> 
> Here is another test case:
> https://www.primaryarms.com/SearchResults.asp?Search=carry+handle+mount

-------------

Some of those on the top website do it, some do not.
The photos fail because the browser has a bogus address at the top
and has lost it's top level Domain.  So the javascript executes outside 
the site.  Sample link:
javascript:open_photo_popup(294043);s_objectID='photomod02';

Opens a new tab (popups diverted to tabs -- but even if they were not, I 
am pretty sure the popup wouldn't have anything in it) -- 
The Location bar in the new tab has exactly the above text in it -- no http/...

The problem is that when a link is javascript the context of the site opening the popup isn't carried to the new window.   That's what needs to happen -- when javascript opens a new window as a popup, the initial state of that window needs to be in the DOM of the site that opened the window.  It MAY be that it's an HTTP address, in which case the owner of the window immediately becomes that of the new site, but barring an explicit site change, context needs to be carried.

Is this possible?   It seems like it *shouldn't* be a security issue, but what does anyone else thing?   

Also of note: these links do not work when javascript is disabled.

One could put the onus of all these bad links on the web site creators, as there are known methods for creating links that work as desired.  I.e.
instead of <a href="javascript:open_photo_popup(294043);s_objectID='photomod02';">, they should have:
<a href="http://www.wtag.com/cc-common/gallery/photos.html?album_id=294043&p=17989997#/0/17989997" onclick="popUp(this.href);return false;">text</a>

BUT... the success of successful programs on the internet and their ubiquity relies on a fundamental: "be conservative in what you generate for output & be liberal about what you accept -- i.e. when calling os functions be conservative, but when dealing with the junk coming in over the internet, allow the user to select "best guess" method -- where if following a literal standard doesn't work, then in cases like these, the browser can try to "do the right thing" to compensate for a plethora of bad websites in order to give the user the best experience in spite of badly programmed websites.

Note I did say it would be a user selectable mode, as in taking a best guess MIGHT expose the user to unanticipated results.  Especially on a malicious website.  One might want this mode to be able to allowed on a site-by-site basis, just like other permissions  -- at the simplest level -- trusted, vs. unknown, but better are finer gradations.  

Example: (high to low, names refer to class of websites -- but user-configurable names  would be desirable as underlying classes might be something vague like: full(highest), trusted, medium-high, medium, medium-low, low, no trust, restricted(access prevented)).
But 'friendly names' might be : full trust; bank-level trust (reasonable that they wouldn't execute malicious code); 
*known*-merchant-level trust (been here before, long history -- they haven't screwed up yet!); 
*new*-merchant level trust (going to purchase, so they better be a bit trustable);
social-level trust (shouldn't execute bad code, but some user might inject bad code); 
random search-result trust(unknown); 
sites with known problems in past (may not have some now, but security is questionable and/or lax and/or site is often attacked); 
& blocked....

I realized the last bit of this is way beyond the scope of this bug -- BUT I thought I would mention it, as if you have a browser that can deal with poorly designed web-pages on the fly -- it would be useful to more general classifications for websites.

Note: I am aware that one can get ultra fine grain control by defining capability.security.policies that define a set of policies and allow find-grained privileged control (and implementing the above may be a as simple a matter as coming up with the write values for above defined policies).  Though ideally, FF would do something similar to what MS has done in ie -- define general policies levels, and allow point-by-point customization of those policies -- and do MS one better -- explain how each policy would affect "what"....

Simply looking at all the capabilities often doesn't give you huge clues about
what they do:

(i.e. if you patch your mozilla to display the hidden caps -- which I feel should be done by default or a user option to show expert security-control values).

But quick and dirty to show users this info -- comment claims these are 'private'
vars... but they are much less private than a var that might be holding CC information or similar in cleartext -- i.e. these are just security settings for
policies -- why categorize them as 'private' to the point of hiding the user's settings *from themselves* ??

/prog/Mozilla Firefox> diff -u chrome/toolkit/content/global/config.js{.orig,}
--- chrome/toolkit/content/global/config.js.orig        2012-03-06 07:54:12.000000000 -0800
+++ chrome/toolkit/content/global/config.js     2012-07-29 17:51:46.685003700 -0700
@@ -1,4 +1,3 @@
-//@line 41 "e:\builds\moz2_slave\rel-m-192-w32-bld\build\toolkit\components\viewconfig\content\config.js"

 const nsIPrefLocalizedString = Components.interfaces.nsIPrefLocalizedString;
 const nsISupportsString = Components.interfaces.nsISupportsString;
@@ -191,8 +190,6 @@
     if (topic != "nsPref:changed")
       return;

-    if (/^capability\./.test(prefName)) // avoid displaying "private" preferences
-      return;

     var index = gPrefArray.length;
     if (prefName in gPrefHash) {
@@ -301,8 +298,6 @@
   for (var i = 0; i < prefCount.value; ++i)
   {
     var prefName = prefArray[i];
-    if (/^capability\./.test(prefName)) // avoid displaying "private" preferences
-      continue;

     fetchPref(prefName, gPrefArray.length);
   }

Comment 148

[Igor Pavlov]

Execution
<a href="javascript:my_script()"> </a>
 , if you press "ctrl" key or "shift"
- open new tab or  new window ?
----------------
IE and Google Chrome: execute script.

Comment 150

[oskarannas]

How come ctrl-click en wheel-click works great in chrome but not FF, anyone?

Comment 151

[Christopher Weber]

(In reply to Christopher Weber from comment #107)
> Will this ever be fixed? 
> 
> I offer 20 Euro for the first person to submit code that gets this problem
> fixed which actually gets accepted into Firefox. 10 Euro for a working
> addon. Payment via paypal.

Pretty obvious, that this offer from 2009 has become senseless by now. Who cares anymore? Not me. I switched browsers. Bye.

Comment 152

[avada]

Was this issue fixed in the meantime in another bug or did JS links just die out?
I've been using Smart Middle Click for several years. Disabled it a month or two ago and I ran into this issue zero times.
Is there a present day website on which I can test it?

Comment 153

[Gingerbread Man]

(In reply to avada from comment #152)
> Was this issue fixed in the meantime in another bug 

It's not fixed, and worse, there's bug 672618.

> or did JS links just die out?

No such luck.

> Is there a present day website on which I can test it?

On the following page, the links titled “Good PopUp #1” and “Good PopUp #4”. There's no issue with “Good PopUp #2” and “Good PopUp #3” because the former doesn't involve JavaScript at all, while the latter specifies an actual URL for the value of the href attribute.
http://www.popuptest.com/goodpopups.html

Comment 154

[avada]

(In reply to Gingerbread Man from comment #153)

> It's not fixed, and worse, there's bug 672618.
Isn't it practically the same issue as this? Anyway I see that was abandoned too...

Oh well. I'll just keep using Smart Middle Click.

> http://www.popuptest.com/goodpopups.html

Thanks for the link.

Comment 155

[David E. Ross]

With recent versions of SeaMonkey, the Smart Middle Click extension does not seem to work for a number of JavaScript links.  Furthermore, I can no longer access the source Web site <http://spiers.free.fr/>; when I try it, I get a 403 error (access denied).  

This illustrates why extensions should be considered merely temporary work-arounds for problems.  The real fixes need to be incorporated into the base code (in this case, Core: Event Handling).

Comment 156

[Worcester12345]

(In reply to avada from comment #154)
> (In reply to Gingerbread Man from comment #153)
> > http://www.popuptest.com/goodpopups.html

"Safe Popup Examples
Click on any of the links below. You should see a new browser window open. "

Good PopUp #2 does not open a new window. It opens a new tab. The others all open a new window.

Mozilla/5.0 (Windows NT 6.1; WOW64; rv:42.0) Gecko/20100101 Firefox/42.0 ID:20151029151421 CSet: e2f9a0ed50bc

Comment 158

[Worcester12345]

Similar, but not a duplicate of:
Bug 1390490 - "middle" or command-clicking on link opens new "pop up" window, instead of opening link in new tab

Comment 160

[Thomas Wolff]

Ah, this issue is getting some attention, after 19 years, wow!
Now some of the reference raise fears that the "solution" might go in the wrong direction.
Please note that the current behaviour is a most annoying violation of the principle of least astonishment.
Intuitive expectation would be to get a new tab with the same contents as if the user had just left-clicked within the current tab.

Comment 161

[xyzxyz7769901]

As this remains a very irritating issue after 22 years, I hope (perhaps in vain) that drawing some attention back to it might do it good. More seriously, if anybody is willing to take a swing at fixing this I at least would very much appreciate it.

Comment 162

[Worcester12345]

(In reply to xyzxyz7769901 from comment #161)

As this remains a very irritating issue after 22 years, I hope (perhaps in vain) that drawing some attention back to it might do it good. More seriously, if anybody is willing to take a swing at fixing this I at least would very much appreciate it.

Did you vote for it? It has only 223 votes right now.

Comment 163

[mmortal03]

(In reply to Worcester12345 from comment #162)

(In reply to xyzxyz7769901 from comment #161)

As this remains a very irritating issue after 22 years, I hope (perhaps in vain) that drawing some attention back to it might do it good. More seriously, if anybody is willing to take a swing at fixing this I at least would very much appreciate it.

Did you vote for it? It has only 223 votes right now.

To be fair, it's already the highest voted bug under Core -> DOM: UI Events & Focus Handling.

Comment 164

[Olli Pettay [:smaug][[e-mail]]]

The relevant code lives in the frontend code.

Comment 165

[Jodi Marquez]

Attachment: kordereress19717818.txt

Thanks from biegroupmusnerb1983.