Open Bug 55696 Opened 25 years ago Updated 10 months ago

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

Categories

(Firefox :: General, enhancement)

Product:
Firefox
Component:
General
Type:
enhancement

Tracking

()

Tracking Flags:
Tracking Status
blocking2.0 --- -

People

(Reporter: hpa, Unassigned)

References

(Depends on 1 open bug, Blocks 3 open bugs,
URL
)

Details

(Keywords: ux-control, ux-implementation-level, Whiteboard: [Hixie-P0] See comment 23 for expected results)

Attachments

(3 files, 2 obsolete files)

Patch to browser.js that updates the contentAreaClick() function
3.67 KB, patch
Details | Diff | Splinter Review
fit attachment 192209 to the latest trunk
3.27 KB, patch
Details | Diff | Splinter Review
patch
2.08 KB, patch
limi
: feedback+
Details | Diff | Splinter Review
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.
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.
event handling and confirming
Assignee: asa → joki
Status: UNCONFIRMED → NEW
Component: Browser-General → Event Handling
Ever confirmed: true
QA Contact: doronr → lorca
Related to bug # 22775.
Depends on: 22775
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.
Severity: normal → enhancement
No longer depends on: 22775
OS: Linux → All
Hardware: PC → All
Summary: Usability: Middle button and JavaScript → RFE: "Open a JavaScript 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. 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.
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.
Status: NEW → ASSIGNED
Target Milestone: --- → Future
Reassigning QA Contact for all open and unverified bugs previously under Lorca's care to Gerardo as per phone conversation this morning.
QA Contact: lorca → gerardok
Blocks: link-modifiers
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.
QA contact updated
QA Contact: gerardok → madhur
*** Bug 92964 has been marked as a duplicate of this bug. ***
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.
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
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
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?
>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.
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
I have also notices that a news:// url cannot be open in a new window. This worked before... file a new bug?
*** Bug 101384 has been marked as a duplicate of this bug. ***
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.
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.
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).
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.
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.
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.
Blocks: useragent
QA Contact: madhur → rakeshmishra
Blocks: 138198
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?
Blocks: window-choice
*** Bug 152450 has been marked as a duplicate of this bug. ***
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?
*** Bug 157082 has been marked as a duplicate of this bug. ***
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.
*** Bug 164521 has been marked as a duplicate of this bug. ***
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.
QA Contact: rakeshmishra → trix
*** Bug 189915 has been marked as a duplicate of this bug. ***
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.
*** Bug 201003 has been marked as a duplicate of this bug. ***
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?
Blocks: 119431
.
Assignee: joki → saari
Status: ASSIGNED → NEW
QA Contact: trix → ian
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. :-)
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
*** Bug 257085 has been marked as a duplicate of this bug. ***
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.
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.)
Tabs and Windows should work equivalently. Resummarising.
Assignee: saari → events
No longer blocks: 138198
Summary: RFE: "Open a JavaScript link in a new window" → RFE: "Open a JavaScript link in a new window" (or new tab)
Whiteboard: See comment 23 for expected results
*** Bug 138198 has been marked as a duplicate of this bug. ***
Note that bug 138198 asked for option (C) from comment #21. That bug has 111 votes and this bug has only 60 total.
(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
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!
*** Bug 218869 has been marked as a duplicate of this bug. ***
(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
Flags: blocking-aviary1.1?
Flags: blocking-aviary1.1?
Whiteboard: See comment 23 for expected results → [Hixie-P0] See comment 23 for expected results
Flags: blocking-aviary1.1?
(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...
Flags: blocking-aviary1.1? → blocking-aviary1.1-
I hope this is fixed soon. Can't believe five years have pasted all ready.
well, i hope you can fix it, because it's not an easy thing to do.
Assignee: events → war59312
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.
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
(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.
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.
Assignee: war59312 → events
*** Bug 300989 has been marked as a duplicate of this bug. ***
(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.
Flags: blocking-aviary2.0?
*** Bug 301950 has been marked as a duplicate of this bug. ***
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
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.
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)
> 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.
(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.
(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." (-:
TBP uses the same fixupAURL() function to canonicalize URLs for its tab-locking feature. Wouldn't makeURLAbsolute() be a better choice?
*** Bug 315586 has been marked as a duplicate of this bug. ***
I think Opera can do this
If Opera does this, does anyone know how they do it?
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.
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.
(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.
(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.
(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.
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?
(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
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.
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.
and I can't find showSingleWindowModePrefs in my Mozilla/5.0 (X11; U; Linux i686; hu-HU; rv:1.7.12) Gecko/20051104
(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
(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 77 is part of what this bug is about. See comment 23.
(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.
*** Bug 318297 has been marked as a duplicate of this bug. ***
Flags: blocking-aviary2? → blocking-aviary2-
Flags: blocking-firefox2-
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.
Flags: blocking1.8.1?
*** Bug 329825 has been marked as a duplicate of this bug. ***
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.
(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.
Not a 1.8.1 blocker.
Flags: blocking1.8.1? → blocking1.8.1-
*** Bug 343436 has been marked as a duplicate of this bug. ***
*** Bug 349058 has been marked as a duplicate of this bug. ***
(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
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.
*** Bug 355057 has been marked as a duplicate of this bug. ***
Flags: blocking1.9?
Flags: blocking1.9? → blocking1.9-
Whiteboard: [Hixie-P0] See comment 23 for expected results → [wanted-1.9] [Hixie-P0] See comment 23 for expected results
*** Bug 359454 has been marked as a duplicate of this bug. ***
Internet Explorer 7 does this just fine. Not sure about Opera.
Awesome!!
No longer blocks: 251137
Flags: wanted1.9+
Whiteboard: [wanted-1.9] [Hixie-P0] See comment 23 for expected results → [Hixie-P0] See comment 23 for expected results
(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.
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 }
"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.
That sounds like a separate issue.
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.
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.
Assignee: events → nobody
QA Contact: ian → events
I think the right way to fix this is by fixing bug 335963, rather than by hacking yet another case into browser.js.
Priority: P3 → --
Summary: RFE: "Open a JavaScript link in a new window" (or new tab) → "Open a JavaScript link in a new window" (or new tab)
Target Milestone: Future → ---
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?
Flags: wanted1.9.2?
Flags: blocking1.9.2?
Flags: wanted1.9.2?
Flags: wanted1.9.2-
Flags: blocking1.9.2?
Flags: blocking1.9.2-
Oldest. Bug. Ever.
Summary: "Open a JavaScript link in a new window" (or new tab) → "Force JavaScript link to open in new window or new tab"
Depends on: 103843
Fixing this bug would be a great improvement. Some (but unfortunately not all) webmasters improve their code if you complain.
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
blocking2.0: --- → ?
Blocks: 565621
(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/
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.
Assignee: nobody → Olli.Pettay
blocking2.0: ? → final+
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.
There's a difference between caching something (just don't delete it) and cloning it (make a working copy).
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
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.
Attached patch patch (obsolete) — — Splinter Review
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.
Attachment #471525 - Flags: feedback?(limi)
Attached patch patch — — Splinter Review
Attachment #471525 - Attachment is obsolete: true
Attachment #471526 - Flags: feedback?(limi)
Attachment #471525 - Flags: feedback?(limi)
(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.
(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>.
(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.
(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.
(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.
> 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.
(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)">
> 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.
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.
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.
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.
blocking2.0: final+ → -
(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.
I wrote an UserScript that fixes this problem: http://userscripts.org/scripts/show/91986 (requires Firefox 4)
Noting related bug 688985 - "Open Link in New Tab" from context menu or from modifier-click should do the same thing.
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.
Attachment #471526 - Flags: feedback?(limi) → feedback+
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 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.
Attachment #471526 - Flags: review?(dao)
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).
Here is another site to use for an example: http://www.wtag.com/main.html Try any of the links on the left.
(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
(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); }
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.
How come ctrl-click en wheel-click works great in chrome but not FF, anyone?
(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.
Blocks: 672618
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?
(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
(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.
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).
(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
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
See Also: → 1522674
Component: Event Handling → User events and focus handling
See Also: → 601118
See Also: 1522674 →
No longer blocks: 672618
See Also: → 672618
See Also: 601118 →

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.

Depends on: 672618
See Also: 672618 →

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.

Flags: needinfo?(bugs)
Severity: normal → S3

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

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

The relevant code lives in the frontend code.

Assignee: smaug → nobody
Component: DOM: UI Events & Focus Handling → General
Flags: wanted1.9.2-
Flags: wanted1.9+
Flags: needinfo?(smaug)
Flags: blocking1.9.2-
Flags: blocking1.9-
Flags: blocking1.8.1-
Product: Core → Firefox
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Creator:
Created:
Updated:
Size: