Open
Bug 138198
Opened 22 years ago
Updated 7 years ago
"open link in new tab" (middle or ctrl click) doesn't work for javascript links
Categories
(SeaMonkey :: Tabbed Browser, defect)
Tracking
(Not tracked)
REOPENED
People
(Reporter: nrg, Unassigned)
References
(Blocks 2 open bugs, )
Details
(Keywords: testcase, Whiteboard: [asaP2])
Go to http://www.blazonry.com/javascript/windows.php and click on the "Open Window 1" link while holding down on CTRL. A new tab will popup but no content will be displayed. Link works fine when normally clicked. Current behavior: javascript windows in a new tab are blank Expected behavior: Content appears even if javascript window appears in new tab nrg
Comment 1•22 years ago
|
||
New tab means new scripting environment. Executing the JS in the new scripting environment gives a syntax error, since the function is not defined. This is exactly the same as doing right-click and open-in-new-window on the link.... Are you suggesting that new windows/tabs should inherit the scripting environment of the parent? That's likely to break a number of existing scripts (and is likely to have security issues).
Updated•22 years ago
|
Comment 2•22 years ago
|
||
*** Bug 123725 has been marked as a duplicate of this bug. ***
Comment 3•22 years ago
|
||
This bug is similar to bug 55696, "RFE: 'Open a JavaScript link in a new window'". The issues bz brings up are the same issues that come up in bug 55696, and my proposed solution is the same.
Comment 5•22 years ago
|
||
There is the small case of bug 103843 - always opening windows in new tabs. Does it really block this? All that's happening there is that instead of opening a window it opens a tab. However, this is concened with what happens when you try to open it in a NEW window/tab which I think is different problem but one which is *very* closely related to bug 55696. Setting platform and OS to All.
OS: Windows NT → All
Comment 6•22 years ago
|
||
This is not an issue for the JS Engine, but the way the browser chooses to embed it. Reassigning to Tabbed Browser for further triage - cc'ing Mitch for the security issue.
Assignee: rogerl → jaggernaut
Status: UNCONFIRMED → NEW
Component: JavaScript Engine → Tabbed Browser
Ever confirmed: true
QA Contact: pschwartau → sairuh
Comment 7•22 years ago
|
||
I kinda expect a blank tab to open because we have no way yet of preventing that. What surprises me is that no window opens. I wonder if it's because that javascript code is executed on the new tab, which of course doesn't have the called function (nor would the relative url work I suspect). What we might be able to make work short-term is that we ignore the ctrl and just open in a new window, though I guess what the user expects is that we really do open in a new tab, which will require support from the back-end, if we decide to support that. Not gonna get to this any time soon.
I propose that we use Peter's solution since it is very easy to implement It's also better than having an empty tab show up! Just make all <A HREF="javascript:..."> tags ignore tabs and open as a regular click. (just like the webmaster intended) nrg
Comment 9•22 years ago
|
||
> New tab means new scripting environment. Executing the JS in
> the new scripting environment gives a syntax error, since the
> function is not defined.
Normally, a new scripting environment for the new tab (or window)
makes good sense, but there are cases when it doesn't necessarily,
such as when the user Ctrl-clicks certain kinds of javascript
links.
I believe scripted links can be divided into three categories:
1. Directly or indirectly opens a new window (via window.open,
a function that does nothing but call window.open (and maybe
set a variable or two in the process), or some similar
tactic) and otherwise has no impact on the existing page.
In that case, it's obvious what should be done: the newly
opened "window" can just appear in a tab instead if that's
what the user says to do, or if the user is choosing to
open it in a new window, that's what was going to happen
anyway, so no change is needed. This is the easy case.
2. Does not open any "new windows", but makes some kind of
change to the current page. This can be anything, from
document.write to assigning to document.all or
window.location to loading a different resource in one
particular frame, populating a table, altering form
content, or who only knows what.
In this case, perhaps (and this would be a dependency on
a separate bug for which I don't have the number just
now, which is about allowing the user to do this in any
general case) the current page should be duplicated
(without reloading, but by copying the DOM) for the new
tab or window, and the script executed there. That
gives the user the result of the link (whatever that
may be) in the new tab or window, and the previous
content in the original tab or window. This should
be as close to what the user wanted as can be done.
3. The really thorny case is what happens if the script
of the link does both: changes the current document
_and_ opens a new window. I don't know that it's
obvious what exactly is the Right Thing to do in this
case. If you do the same as for case 2, then the
script will open _another_ new window (or tab, once
the rfe for forcing all windows into tabs lands),
for a total of two new windows or tabs, which might
not be what the user wanted and will surely not be
what the user anticipated. OTOH, if you do the
same as for case 1, then the current document will
be altered, which also might not be what the user
wanted. Asking the user for each case would be
way too annoying, and it's too complicated a case
to explain tersely in a prefs dialog. Someone in
the UI team would need to decide what is the
least inappropriate thing to do in this case. I
imagine it is very much a minority case, but it
will happen on occasion, and will have to be
treated one way or the other. If you it is decided
to treat this as case 1, then the test can check
whether the current page is altered. OTOH, if it
is decided to lump case 3 with case 2, then the
test can check whether any new window is spawned
by the script.
The really evil case (could almost be case 4) is
where it is not possible to determine, without
executing the script, what it does. Perhaps because
it calls a function with conditional logic. (It has
been proven repeatedly that it is not always possible
to determine the outcome of a function, or even
whether it terminates, without executing it.) In
this case, I propose that the DOM be duplicated and
the script executed on the copy to see what it does,
and the result displayed wherever is determined
(via the above cases) to be the appropriate place.
This will cost a bit more, but not unacceptably so
(IMO) given that it is an unusual and pathological
case, and has to be dealt with somehow.
The expense of deciding which case the link falls into
only needs to happen when the user chooses to open the
link in a new tab or window, so it shouldn't affect
performance for anything else.
But this really can't be implemented until someone
decides what to do with case 3. (Personally, I don't
care which way it goes; either way, it will sometimes
be what the user expects and occasionally not. Ask
a UI person.)
Updated•22 years ago
|
Blocks: window-choice
Comment 10•22 years ago
|
||
*** Bug 172804 has been marked as a duplicate of this bug. ***
Updated•22 years ago
|
QA Contact: sairuh → pmac
Comment 11•22 years ago
|
||
*** Bug 175836 has been marked as a duplicate of this bug. ***
Updated•22 years ago
|
Blocks: link-modifiers
Summary: javascript openwin doesn't work when opening in a new tab → "open link in new tab" doesn't work for javascript links
Comment 12•21 years ago
|
||
The site http://tivo.weaknees.com/index.php produces a pop up when you hit several of the page links such as 'Tivo Parts'. But in that popo up you can't open up a link in a tab with a right click. Lots of activity over the network, but nothing shows up. However, you can open up a new window. If theoretically convoluted/impossible to open tab, should at least alert user somehow. Version 1.4RC1, win 95.
Comment 13•21 years ago
|
||
The tabbar in that example is just hidden (as are all other toolbars in the popup window), but the tab is still created as always, and you can ctrl-tab to get to it as usual. There are hidden prefs to not allow sites to hide certain toolbars. See bug 107949. And all of this has absolutely nothing to do with this bug.
Comment 14•21 years ago
|
||
Re comment 13 . Many thanks for clarification. Sorry for non useful post. Need a link which explains some of the obscure prefs which don't have a UI (e.g. as mentioned in your pointer about bug 107949 ) . If such a link exists, maybe it should be given more prominence (on the download page? as the installer exits?) for beginner reporters like me who are trying to be most efficient for all the hard working people on this project. Is the prior sentence worth a bug report?
Comment 15•21 years ago
|
||
> Need a link which explains some of the obscure prefs which don't have a UI Note a very useful URL to list them all is about:config Also see: http://www.mozilla.org/unix/customizing.html http://www.geocities.com/pratiksolanki/
Comment 16•21 years ago
|
||
Middle-Click on thumbnail images, a new tab open, but remain empty! http://www.extremetech.com/article2/0,3973,1189291,00.asp Why not to cut the corner and display in the new tab the image loaded by javascript.OpenImageWindow() ?? Open an empty tab is frustrating, better in that case transform a middle-click in a left-click and open the popup window with the image as expected.
Comment 17•21 years ago
|
||
*** Bug 211112 has been marked as a duplicate of this bug. ***
Comment 18•21 years ago
|
||
This bug is one of the few reason i still frustrated by mozilla. It have my vote for sure! 1. middle-click on a javascript OpenImageWindow() must open the image in a new tab 2. middle-click on a javascript OpenWindow() must open a regular window instead I can't count how many times i mid-clicked some links in sequence just for figuring out why i have empty tabs with (untitled) caption. IMHO, this behaviour should be corrected with high priority because UI usability and dataloss. I hope to sensibilize about this bug, and sorry for the spam.
Comment 19•21 years ago
|
||
*** Bug 226497 has been marked as a duplicate of this bug. ***
Comment 20•21 years ago
|
||
*** Bug 227314 has been marked as a duplicate of this bug. ***
Comment 21•20 years ago
|
||
I created a meta-testcase for this kind of bug in bug 151142. Interactive tests and results I get in 1.7 RC2 build 20040601 under XP Pro SP1a can be found in attachment 149849 [details]
Keywords: testcase
Comment 22•20 years ago
|
||
comment 9 does a good job of listing the possible things a js link can do. However, when a user tries to open a new tab by A) middle clicking on it or B) right-clicking and choosing "open in new tab", then they obviously want to open the window in a new tab. It would be nice to be able to tell exactly what the JS is doing ahead of time; but since we can't, I think trusting the user to know what THEY are doing is the next best alternative. It can also be assumed that when the user specifically chooses to place the window in a tab, that they do not want the size or toolbars removed. I suggest that this bug apply for A & B above, and NOT try to determine what to do based on any other criteria. Yes, this doesn't address the entire bug (such as JS that modifies both the source and the destination tab), but it is a good start that would be functional and useful.
Comment 23•20 years ago
|
||
*** Bug 222603 has been marked as a duplicate of this bug. ***
Comment 24•20 years ago
|
||
*** Bug 248554 has been marked as a duplicate of this bug. ***
Comment 25•20 years ago
|
||
*** Bug 126862 has been marked as a duplicate of this bug. ***
Comment 26•20 years ago
|
||
Refining summary to incorporate bug 126862.
Summary: "open link in new tab" doesn't work for javascript links → "open link in new tab" (middle or ctrl click) doesn't work for javascript links (should act like normal click)
Comment 27•20 years ago
|
||
Latest TBE partialy fixes this issue (it does not allow javascript to open untitled window on middle click, although user must left click again in order to see what he wants). I think that you must set something in TBE preferences in order to see this, but maybe it's default, though.
Comment 28•20 years ago
|
||
*** Bug 267222 has been marked as a duplicate of this bug. ***
Comment 29•20 years ago
|
||
*** Bug 267222 has been marked as a duplicate of this bug. ***
Comment 30•20 years ago
|
||
(In reply to comment #9) > 2. Does not open any "new windows", but makes some kind of > change to the current page. This can be anything, from > document.write to assigning to document.all or > window.location to loading a different resource in one > particular frame, populating a table, altering form > content, or who only knows what. > > In this case, perhaps (and this would be a dependency on > a separate bug for which I don't have the number just > now, which is about allowing the user to do this in any > general case) the current page should be duplicated > (without reloading, but by copying the DOM) for the new > tab or window, and the script executed there. That > gives the user the result of the link (whatever that > may be) in the new tab or window, and the previous > content in the original tab or window. This should > be as close to what the user wanted as can be done. As a programmer and someone who wants this bug fixed it seems to me that the obvious fix is what this guy suggests in 2 - however he suggests that the browser is going to have to know what javascript it to be executed so it can behave differently based upon it, but I think that sounds really difficult to implement and I don't think it's necessary. I would say when the user requests a link to me opened in another window the browser should duplicate the document as accurately as possible then activate the link in the copy of the window. This would work for most if not all cases, the only side effect is that it would slow down opening "normal" links and when a window.open is called you would end up with two windows opening, but I think this makes sense from what the user has requested. Here's a selection of test cases and how this would effect tham as I see it: 1) Normal link - Would still work but would be slightly slower due to the overhead of copying the window first. 2) Javascript Link that does window.open - the user would end up with two copies of the current window and the javascript opened one. 3) Javascript that modifies the current page - the user would end up with the original document and the new document correctly modified - as expected. 4) Javascript that posts a form - The user would end up with the original document and the result of the post as expect. IMHO when a user tells the browser to open a document in a new window, what they are really saying is "I don't know what this link is going to do, but whatever it is I don't want to lose *this* page!". So the prime concern is making sure that the current page is not effected. If the user ends up with two copies of the current page and a popup one then IMHO this is better than the current situation because it has kept the original document and all they have to do is close the doc they don't need open. Possibly at a later stage some flag could be put in and if window.open is called while the flag is set then it means close the current window?
Comment 31•20 years ago
|
||
Too much tehnical stuff. I dont understand - this bug will fix bug #222603 or not?
Comment 32•19 years ago
|
||
*** Bug 278728 has been marked as a duplicate of this bug. ***
Comment 33•19 years ago
|
||
I agree with the concept of the idea of the new tab/window meaning "I want the result of this to happen somewhere else". However, duplicating the DOM for every link isn't really practical. Even if it's only a slight slowdown for regular links, people tend to get touchy about issues of speed. If, instead, we duplicate for any javascript: links, that only leaves the problem of window.open causing an extra window. However, what if the first call to window.open in the function in the new window actually opened in that window, instead of spawning a new one? In a way, this would be like redirecting window.open to document.location. Scenarios here: Original window = W1, new window (from middle/ctrl click) = W2 javascript link without window.open: W1 is duplicated. W2 shows changes. javascript link with window.open: W1 is duplicated. W2's call to window.open causes W2 to change location. javascript link with multiple window.opens: W1 is duplicated. W2's first call to window.open causes W2 to change location. Subsequent calls actually open new windows. The one situation I can think of that would mess this up is if some kind of timer system is used, or something such that window.open isn't called by the function in question. This might be a solution for bug 55696, too.
Comment 34•19 years ago
|
||
Might we request this for blocking-aviary1.1, or should we have a patch proposed first?
Comment 35•19 years ago
|
||
*** Bug 281279 has been marked as a duplicate of this bug. ***
Comment 36•19 years ago
|
||
(In reply to comment #34) > Might we request this for blocking-aviary1.1, or should we have a patch proposed > first? You can ask for a blocking flag, even if a patch is not posted, considering Firefox 1.1 will be a major release. I just did that for this bug.
Flags: blocking-aviary1.1?
Comment 37•19 years ago
|
||
If "browser.block.target_new_window" is set to true, then middle click should not act like normal click as described in summary, but as it would open link in the same tab, and there wouldn't be way to open the link in new tab.
Comment 38•19 years ago
|
||
> Might we request this for blocking-aviary1.1, or should we have a patch > proposed first? > duplicating the DOM for every > link isn't really practical. > If, instead, we duplicate for any javascript: links, that only leaves the > problem of window.open causing an extra window. I think people should not expect a fix anytime soon. There are at least 20 ways to badly code a link. To categorize each kind is easy; to code effectively and efficiently around and against those ways is counter-productive, inconsequent, unrealistic, will have side effects (like bugs, performance) and is bound to fail anyway. The "javascript:" pseudo-protocol is practically impossible to deal with since it can have endless amount of heterogeneous code. People expect way too much here. I'm not trying to put down this bug. (I think users' UI and decisions should veto web authors' requests in the final instance.) Personally I am for educating (tech evangelism) against use of "javascript:" pseudo-protocol and for ignoring all recourse to "javascript:" pseudo-protocol (that would be drastic but tackling things at the root) rather than trying to make the browser counter all kinds of badly coded links. Remember that the current implementation in Mozilla makes links open in new tab when the link is normally coded *_like it should be_*, that is normally and according to W3C HTML 4.01 web standards and accessibility standards. The problem is with badly coded links and mainly because of the support for "javascript:" pseudo-protocol.
Comment 39•19 years ago
|
||
Fixing this bug might be a lot of work. On the other hand, educating all current and future web developers, as well as fixing all existing web pages sounds like even more work to me.
Comment 40•19 years ago
|
||
(In reply to comment #38) > There are at least 20 ways > to badly code a link. To categorize each kind is easy; to code effectively and > efficiently around and against those ways is counter-productive, inconsequent, > unrealistic, will have side effects (like bugs, performance) and is bound to > fail anyway. That is true, but this doesn't mean the solution suggested in comment #8 can't be implemented, at least as a temporary fix. After all, what users end up doing is re-clicking the link without Ctrl, so why not do it for them? Very easy to implement AFAICT, far from perfect, but improves user experience considerably.
Comment 41•19 years ago
|
||
I think there's no need to run JS codes twice, no need build new scripting environbent. Just do this: when a user clicks a link triggering a JS code just set a flag if user used ctrl+click (open in new tab,etc.) then execute the code in the old environment (no new tabs at this time), if the code wants to pop up a new window, then create just one new tab for it, if the flag was set.
Comment 42•19 years ago
|
||
This bug is NOT fully cross-platform. The same site (it's restricted access, so I can't demonstrate here) behaves differently with FF for Windows vs FF for FreeBSD (Unix?). On Windows, a middle-click to open a link in a new tab opens the link in a new tab. On FreeBSD, I get the blank tab discussed in the bug's initial filing. This is the same site, same code, same version of FF, only difference is the OS. Why is this taking so long to fix? It's been open for almost a year. Are we assuming that users don't know what they're doing when they request that a link be opened in a new tab? I am STILL on 0.9.3 because I NEED this to work. The manual copying and opening of links adds up to far too much of my time to justify upgrading, bugs or no.
Comment 43•19 years ago
|
||
(In reply to comment #42) > This bug is NOT fully cross-platform. > The same site (it's restricted access, so I can't demonstrate here) behaves > differently with FF for Windows vs FF for FreeBSD (Unix?). This actually appears to be separate from the Javascript issue, so is a different bug.
Updated•19 years ago
|
Whiteboard: [asaP2]
Comment 44•19 years ago
|
||
*** Bug 292209 has been marked as a duplicate of this bug. ***
Comment 45•19 years ago
|
||
*** Bug 294533 has been marked as a duplicate of this bug. ***
Comment 46•19 years ago
|
||
I vote for "INVALID" A LINK is a LINK is a LINK is a LINK ..... and NOT SCRIPT People, if you wanna use Javascript to do something with a link then put it in the correct place, the onCLick Handler (or whichever handler fits your needs). Simply use the construct <a href="newUrl?with&some¶meters" target="theTarget" onclick="myWickedJSFunction(this.href, this.target)">SomeWhickedAction</a> Now, normal-Click and JS gets executed and does wickedThings- if you do not want that to happen just middleClick - new Tab Pages that use href=javascript: are inaccessible and should be reported as broken to the webmaster
Comment 47•19 years ago
|
||
(In reply to comment #46) > I vote for "INVALID" > > A LINK is a LINK is a LINK is a LINK ..... and NOT SCRIPT > > People, if you wanna use Javascript to do something with a link then put it in > the correct place, the onCLick Handler (or whichever handler fits your needs). > > Simply use the construct <a href="newUrl?with&some¶meters" > target="theTarget" onclick="myWickedJSFunction(this.href, > this.target)">SomeWhickedAction</a> > > > Now, normal-Click and JS gets executed and does wickedThings- if you do not want > that to happen just middleClick - new Tab > > Pages that use href=javascript: are inaccessible and should be reported as > broken to the webmaster > Since when was it up to the user to make correct hyperlinks or not? Let's look at one example here...how about, HOTMAIL Do you really believe ms would get rid of all their javascript just so firefox could open emails in new tabs? What about gmail? Gmail's pretty damn popular and also uses js to open emails.
Depends on: majorbugs
Comment 48•19 years ago
|
||
(In reply to comment #47) > Since when was it up to the user to make correct hyperlinks or not? No, jens was saying that it's up to authors to correctly code their web pages (which is simple to do if you understand javascript/ecmacsript at all), not up to the users of those pages. Authors /should/ correct their code. I don't know if that necessarily means that this bug is INVALID, though.
Comment 49•19 years ago
|
||
(In reply to comment #46) > I vote for "INVALID" > I don't know that this should be invalid. While I wholeheartedly agree with the substance of your statements, I don't think that many of the sites that are experiencing issues related to this bug are going to actually do the right thing and script correctly just so things work for everybody. The fact of that matter is that when people design websites, oftentimes they just say "well it works in IE" and then go with it, they don't even take into account the possibility of middle-clicking to open a new tab. Some places may even intentionally do this in a manner to keep you from opening things in a new tab. In order to make tab browsing functional, this bug needs to be fixed with a workaround for people doing bad scripting. It is a fact of life that you oftentimes need to work around what other people are doing because they are doing it wrong. I think comment #47 hit the nail on the head. We can't expect MS or Google to change Hotmail and Gmail to allow opening things in a new tab. They use JS that will (until a workaround is implemented) break the ability to open emails in a new tab, and that is just the way it is. Definitely not invalid, IMO.
Comment 50•19 years ago
|
||
This bug should never have been confirmed. It doesn't have a clear statement of what behaviour would have to change for it to be considered fixed (i.e. it doesn't state the "expected results".) Such as given in bug 55696 comment 23. *** This bug has been marked as a duplicate of 55696 ***
Status: NEW → RESOLVED
Closed: 19 years ago
Resolution: --- → DUPLICATE
Comment 51•19 years ago
|
||
(In reply to comment #50) > This bug should never have been confirmed. It doesn't have a clear statement of > what behaviour would have to change for it to be considered fixed (i.e. it > doesn't state the "expected results".) > > Such as given in bug 55696 comment 23. > > *** This bug has been marked as a duplicate of 55696 *** Ian, what are you talking about? "Should act like normal click" seems straightforward to me. I don't care, the other bug seems reasonable, but it seems like you took a shortcut with your justification for nuking this one. I would say a more accurate reason would be on the order of: "Several optional solutions for this bug are fully developed in bug xxxx, so we're duping this bug against it." Sincerely, your local self-appointed and annoying bugzilla critic.
Comment 52•19 years ago
|
||
> Ian, what are you talking about? "Should act like normal click" seems
> straightforward to me.
I don't see that anywhere in this bug. The first occurace of "should act" is
your comment. And even if it was, it is IMHO much too vague.
Comment 53•19 years ago
|
||
Hixie: summary.
Comment 54•19 years ago
|
||
Ah, indeed. Didn't see that, the title is cropped at the "(" in my browser here. Anyway, that is, as I mentioned, too vague to identify what the browser should be doing. And this bug is still a dupe, as mentioned, so...
Updated•19 years ago
|
Flags: blocking-aviary1.1?
Updated•19 years ago
|
Status: RESOLVED → VERIFIED
Assignee | ||
Updated•16 years ago
|
Product: Core → SeaMonkey
Comment 55•13 years ago
|
||
fwiw, Firefox plans to implement this as an interim behavior until we are able to fix bug 55696. The simple Firefox change is happening in bug 672618.
Status: VERIFIED → REOPENED
Resolution: DUPLICATE → ---
QA Contact: pmac → tabbed-browser
Comment 56•10 years ago
|
||
Acting like normal link is the wrong approach. See bug 672618 comment 8.
Summary: "open link in new tab" (middle or ctrl click) doesn't work for javascript links (should act like normal click) → "open link in new tab" (middle or ctrl click) doesn't work for javascript links
Comment 57•10 years ago
|
||
Firefox 28: The user middle clicks on many of the links in http://www.noisefree.org/links.php intending to subsequently read them each in their different tab. Only later does he realize he has many empty tabs each with URLs like javascript:popupWindow('http://www.eskimo.com/~billb/hum/hum.html') in their URL bar. You might say this is the users fault. However 1. During the clicking process they seem just like usual links. 2. The user should not be expected to look at the link preview before clicking each link... that's why its in the corner and does not require an "OK".
Updated•7 years ago
|
Assignee: jag-mozilla → nobody
You need to log in
before you can comment on or make changes to this bug.
Description
•