Open Bug 138198 Opened 19 years ago Updated 4 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).
*** Bug 123725 has been marked as a duplicate of this bug. ***
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
Ever confirmed: true
QA Contact: pschwartau → sairuh
*** Bug 172804 has been marked as a duplicate of this bug. ***
*** Bug 175836 has been marked as a duplicate of this bug. ***
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/
*** Bug 211112 has been marked as a duplicate of this bug. ***
*** 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]
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.
*** Bug 267222 has been marked as a duplicate of this bug. ***
*** Bug 267222 has been marked as a duplicate of this bug. ***
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. ***
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.
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.
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.
*** Bug 292209 has been marked as a duplicate of this bug. ***
*** Bug 294533 has been marked as a duplicate of this bug. ***
Depends on: majorbugs
(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
(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.
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...
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 → ---
Acting like normal link is the wrong approach. See bug 672618 comment 8.
You need to log in before you can comment on or make changes to this bug.