Open Bug 138198 Opened 19 years ago Updated 4 years ago

"open link in new tab" (middle or ctrl click) doesn't work for javascript links

Categories

(SeaMonkey :: Tabbed Browser, defect)

x86
All
defect
Not set
normal

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
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).
Depends on: 55696, 103843
*** Bug 123725 has been marked as a duplicate of this bug. ***
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.
So... is there a reason this is not just a duplicate of bug 55696?
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
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
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
> 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.)
*** Bug 172804 has been marked as a duplicate of this bug. ***
QA Contact: sairuh → pmac
*** Bug 175836 has been marked as a duplicate of this bug. ***
Summary: javascript openwin doesn't work when opening in a new tab → "open link in new tab" doesn't work for javascript links
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. 
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.
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?
> 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/
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.

*** Bug 211112 has been marked as a duplicate of this bug. ***
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.
*** Bug 226497 has been marked as a duplicate of this bug. ***
*** Bug 227314 has been marked as a duplicate of this bug. ***
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 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. 
*** Bug 222603 has been marked as a duplicate of this bug. ***
*** Bug 248554 has been marked as a duplicate of this bug. ***
*** Bug 126862 has been marked as a duplicate of this bug. ***
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)
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.
*** Bug 267222 has been marked as a duplicate of this bug. ***
Blocks: 251137
*** Bug 267222 has been marked as a duplicate of this bug. ***
(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?
Too much tehnical stuff. I dont understand - this bug will fix bug #222603 or not?
*** Bug 278728 has been marked as a duplicate of this bug. ***
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.
Might we request this for blocking-aviary1.1, or should we have a patch proposed
first?
*** Bug 281279 has been marked as a duplicate of this bug. ***
(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?
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.
> 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.
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.
(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.
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. 
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.
(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.
Whiteboard: [asaP2]
*** Bug 292209 has been marked as a duplicate of this bug. ***
*** Bug 294533 has been marked as a duplicate of this bug. ***
Blocks: majorbugs
No longer blocks: majorbugs
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&parameters"
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
(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&parameters"
> 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
(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. 
(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.
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: 16 years ago
Resolution: --- → DUPLICATE
No longer depends on: 55696
(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.
> 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.
Hixie: summary.
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...
Flags: blocking-aviary1.1?
Status: RESOLVED → VERIFIED
No longer blocks: 251137
Product: Core → SeaMonkey
No longer depends on: 103843
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
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
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".
Duplicate of this bug: 1279658
Assignee: jag-mozilla → nobody
You need to log in before you can comment on or make changes to this bug.