Per 308396, unify single window mode preferences in the back end such that tabs-for-external-links and tabs-for-targeted-links share the same value.
P1. Must not ship another release in the inconsistent state.
Assignee: mconnor → nobody
Priority: -- → P1
P1. Must not ship another release in the inconsistent state.
bugzilla hates me.
Assignee: nobody → mconnor
Status: NEW → ASSIGNED
Target Milestone: --- → Firefox 2 alpha1
Will this change mean that instead of the existing prefs: browser.link.open_newwindow (which affects targeted links) browser.link.open_external (which affects external links) there will be only one pref? This doesn't sound particularly useful - is it easier to change the backend to treat external links as a subset of targeted links?
bump to beta1, this needs to be worked out with gecko people, since browser.link.open_newwindow is checked in appshell for some reason, even though consumers should be controlling that now. The pref defaults are consistent, and the prefpanel sets both, so this its just cleanup after the original implementation mess from pre-1.0
Target Milestone: Firefox 2 alpha2 → Firefox 2 beta1
(In reply to comment #5) > The pref defaults are consistent, and the prefpanel sets both, so this its just > cleanup after the original implementation mess from pre-1.0 Your comment implies that this is a UI-related cleanup, not a nuts-and-bolts cleanup. If so, is any information available on what the end results will be?
Oh, no, its a nuts-and-bolts cleanup for sure!
The current UI doesn't seem to allow users to set browser.link.open_newwindow to 1 (the option to open in "the same tab/window" has disappeared). Was this intentional or oversight? If oversight, can it please be restored? Also I'm curious as to comment #4 as well, since my 1.5 behavior (and desired future behavior) is that external links open in new tabs, while targeted links open in the same tab. It seems reasonable to not expose this to the user in UI, but I would hate to see the prefs disappear.
It was an intentional choice. The destructive option isn't usually the right option, and it was hidden in the interest of clarity. As for the external vs. targeted links options, I think that it was a flaw in the original implementation to handle those separately, and I don't feel compelled to continue to maintain separate prefs for those behaviours. Ben and Beltzner and I discussed this last fall, and agreed that setting those to different behaviours was largely a corner case, and there's always things like Tab Mix Plus to cover those corners.
load-balancing tabbrowser stuff to sspitzer
Assignee: mconnor → sspitzer
Status: ASSIGNED → NEW
Assignee: sspitzer → sspitzer
increasing swag, since I still need to talk to the gecko people.
Status: NEW → ASSIGNED
Whiteboard: SWAG: 0.25d → SWAG: .5d
12 years ago
Whiteboard: SWAG: .5d → SWAG: 1d
pushing out non-critical-path bugs to b2
Target Milestone: Firefox 2 beta1 → Firefox 2 beta2
Seth, what's the status here?
Whiteboard: SWAG: 1d → SWAG: 1d [at risk]
> since browser.link.open_newwindow is checked in appshell for some reason It's checked because the tree owner is implementing nsIWindowProvider, and so needs to either provide a window or not. I'd be happy to have some way of passing off this decision to the browser chrome. Presumably we'd need a chrome impl of nsIWindowProvider and a way to register it with the tree owner, right? Peter, the "same window" option is actually not something I would recommend using. There are crashes that it causes, last I checked.
Not going to hold Fx2 on this. As long as the preferences remain in sync as defaults, there's no significant issue in keeping the parallel prefs for one more release.
Flags: blocking-firefox2+ → blocking-firefox2-
sorry for the bug spam, re-assigning bugs back to default owner if I'm not working actively on them.
Assignee: sspitzer → nobody
Status: ASSIGNED → NEW
Created attachment 268626 [details] [diff] [review] remove browser.link.open_external What's wrong with just removing browser.link.open_external and using .open_newwindow everywhere? This would at least fix the potential UI issue from bug 358187 while still letting extension authors recreate the pre-Firefox 2.0 state.
Would love to take it, but won't block on it.
Flags: blocking-firefox3? → blocking-firefox3-
Whiteboard: SWAG: 1d [at risk] → [wanted-firefox3]
Bummer. What happened to "P1. Must not ship another release in the inconsistent state."? Thanks for your continued hard work anyhow.
Comment on attachment 268626 [details] [diff] [review] remove browser.link.open_external simon, sorry for letting this sit in my queue for so long. can you ask gavin, mconnor or mano to review this instead?
Priority: P1 → --
Target Milestone: Firefox 2 beta2 → Firefox 3 M8
Created attachment 279096 [details] [diff] [review] remove browser.link.open_external (unbitrotted)
Need to re-up the review request. ("P1. Must not ship another release in the inconsistent state.")
Created attachment 339974 [details] [diff] [review] unbitrotted [Checkin: Comment 26] Gavin: This is simple code clean-up to match the fact that we've been trying to keep these two prefs in sync since at least Firefox 2.0. Extensions could easily add the behavior back if need be.
Attachment #339974 - Flags: review?(gavin.sharp) → review+
Comment on attachment 339974 [details] [diff] [review] unbitrotted [Checkin: Comment 26] Filed bug 459313 on fixing QA companion code. We should get this in early to weed out any extensions that rely on this pref.
Target Milestone: Firefox 3 alpha8 → Firefox 3.1b2
Comment on attachment 339974 [details] [diff] [review] unbitrotted [Checkin: Comment 26] http://hg.mozilla.org/mozilla-central/rev/9d82e9adb2ba
Attachment #339974 - Attachment description: unbitrotted → unbitrotted [Checkin: Comment 26]
Status: NEW → RESOLVED
Last Resolved: 10 years ago
Resolution: --- → FIXED
How can I get back the behavior that was working for the following: link.open_newwindow,1 link.open_external,3 ? It was opening clicks in the same window no matter what, but external links were put into new tabs.
You can't, without an addon.
sorry about the spam, but what happened to the user-doc, did it ever get set up? (see bug 469082)
I've been sent over here from bug 469082 (thanks Natch). And... wait. I'm confused. This was actually an *intentional* change? There's no longer any way to suppress unnecessary new windows without having destructive behaviour from external links? And now there's yet another add-on necessary to restore the sensible, long-standing behaviour I've grown accustomed to since the days of Phoenix? You'll have to pardon my frustration, but this is beyond silly. *All* I want is control of my user experience; I don't want overzealous site owners setting target="_blank" on every link, spawning window after window or tab after tab. Now, if I want to do that, clicking links in my mail client blows away whatever I've currently got open. This makes no sense. It's silly. It's dumb. It's "clean-up" at the expense of your users. External links should never, *ever* blow away what's already open in the browser. There's a very good reason for handling links I'm clicking *in the browser* differently from links I'm clicking elsewhere in the OS. Back to 3.0 I go...
I usually do not moan about changes but this one just seems silly. It makes perfect sense for a user to want to browse a single website in a single tab and not open a gazillion tabs if the website was using window.open or something else. That was the main function of browser.link.open_newwindow,1. On the other hand combining this with external window prefs does not make any sense because if I am clicking 10 news articles in my feed reader I do not want them to open in the same tab! I know this change might seem trivial to the developers but this is a seriously a big usability issue for the users and you will see more complaints when 3.1 is released. I am not saying that because of this I won't use the next release but this will affect my and probably others' browsing experience. And while you guys are adding major features within the browser us users have to look for extensions to bring back the trivial features that existed before (like having a new tab button in the toolbar). Please reconsider this change, I really think this should exist within the browser. Thanks
One problem is that open_newwindow=1 breaks a lot of sites. The way I see it, HTML/JS/etc should have never allowed such a thing as opening a new window. And some sites are now migrating to "virtual windows" like dynamically adding a div ("lightboxes"). The question is, should Firefox allow its inexperienced users degraded experience on badly designed sites compared to IE, or should Firefox get rid of this hack and degrade experience for the more savvy users? Which matters more? Not scaring away recent migrants from IE or keeping the mindshare? I think Mozilla's focus is the first, and the pro users are supposed to migrate to minority browsers or use hacky extensions. After all, Firefox can't be the new IE while also retaining the qualities of the old Mozilla.
(In reply to comment #29) > sorry about the spam, but what happened to the user-doc, did it ever get set > up? (see bug 469082) We're waiting for bug 457027 to be pushed to the production server (should be some time next week), then we will be able to update <http://support.mozilla.com/kb/Options+window>.
Keywords: user-doc-needed → user-doc-complete
I believe we have to update at least one testcase on Litmus to cover the new behavior?
I would like to propose another solution for this bug. I upgraded from 3.0 to 3.1b3pre today, and the first thing I noticed was that Firefox was erasing my tabs. My solution preserves the cleaned up preferences code done by the current patch, but without causing the regression mentioned here and in bug 469082. The regression is fixed by adding three lines of code to browser.js. Please consider this: In browser.js:4315, replace this: aWhere = gPrefService.getIntPref("browser.link.open_newwindow"); With this: if (aContext == Components.interfaces.nsIBrowserDOMWindow.OPEN_EXTERNAL && gPrefService.getPrefType("browser.link.open_external") == gPrefService.PREF_INT) aWhere = gPrefService.getIntPref("browser.link.open_external"); else aWhere = gPrefService.getIntPref("browser.link.open_newwindow"); If browser.link.open_external is not defined (which it is not by default), browser.link.open_newwindow will be used instead. Please consider fixing this regression.
Good to know. So all we really need is a simple method for suppressing the opening of new windows/tabs via target="_blank".
Note that the prefs _used_ to be separated. I combined them at some point, by putting all the targeting code in a single place. The fallout was as you observe, for the simple reason that <a target="_blank"> calls window.open() internally.
Oh, and the upshot was that target=_blank targeting didn't work the same as window.open() targeting in various ways, and both were buggy, and would tend to get out of sync with each other. That's why the targeting code was consolidated.
I agree with #36. Current code leads to situation when opening link from external application causes different effects depending on whether firefox is already started or not. Now its confusing because: - firefox running -> opening link from extrenal application replaces active tab - firefox not running -> extrenal link opened in new tab It occurs with following setting: browser.link.open_newwindow;1 browser.link.open_newwindow.restriction;2 Overriding current tab is very irritating, and doing this or not depending on the state of forefox process is irritating even more. Please resolve this. Otherwise there is no more elegant way to browse in single window.
(In reply to comment #28) > You can't, without an addon. Can someone point me to a simple addon that achieves this? By simple I mean "not TabMixPlus". (I still don't get why you made the "open in same tab" feature completely useless though. Opening an external link requires you to open a blank tab beforehand, it gets ridiculous once a friend IMs 2-3 links. A website shouldn't control my tabs.)
What you can achieve without an add-on (and please continue the discussion in that thread): http://forums.mozillazine.org/viewtopic.php?p=5440185#p5440185
(In reply to comment #43) > Can someone point me to a simple addon that achieves this? By simple I mean > "not TabMixPlus". See attachment 371285 [details]. And why can't developers give a simple yes/no reply to my comment 36 where I suggest fixing this issue in a way that does not involve backing out this bug?
Can anyone explain why this was broken in 3.5? The bug should be re-opened until it is fixed.
I agree, this should be re-opened. Clearly a lot of people liked the old functionality (just see the number of threads and replies on the forums).
(In reply to comment #45) > See attachment 371285 [details]. This partially works. Go to about:config and create browser.link.open_external as an integer value, set it to 3. The set browser.link.open_newwindow to 1. External links now open in a new tab, internal links open in the same tab. Unfortunately, it is not compatible with Tabs Open Relative :(
I just upgraded to 3.5 and got stung by this change. I finally tracked it down to this bug and am rather surprised that this was intentional. I don't mean to belabor the discussion, but this bug seems the place most likely to attract positive attention. I (like some of the commenters above) had been using browser.link.open_newwindow=1 to constrain most clicked links to the same tab, regardless of what the web designer asked for, but with browser.link.open external=3 so that external links opened in new tabs. It's the behavior most consistent with the back/forward paradigm. I don't ask for this behavior to be the default, but it seems reasonable that firefox should accommodate it, as it has in the past.
(In reply to comment #49) That's the crux of it really. The preference should be re-instated and honoured. If that isn't possible for some reason (might break default settings or something) then new replacement preferences should be added. Please re-open the bug.
(In reply to comment #51) This is exactly what I used before FF3.5, it seems to me such an obvious setting, I can't believe that it is no longer possible. I don't want a proliferation of windows while browsing, so I want new windows to open in tabs, but when an external program launches a link, it should open a new window: there is no way to know which existing window (if any) to open it in, and it is really annoying to be dragged to a different desktop just because I happen to have a window already open there. I understand not wanting to confuse new users, but please give those of us who want it the ability to set this as we like it.
I cannot understand why a preference option was removed. I could understand that the default changed but there should still be a way to specify how the user wants to open external links. For example, for me, opening external links in a new tab is a great annoyance as I use multiple workspaces/desktops/spaces and I want Firefox to open a new window in the active workspace/desktop/space and not in a tab in some other window I have to hunt down through multiple workspaces/desktops/spaces.
I would also like to see this bug reopened. The current behavior is *very* annoying and almost makes me want to downgrade to 3.0. Despite of the web designers intentions I would like to open all links in the current tab (browser.link.open_newwindow=1) except of course those from external applications, which should be opened in a new window (browser.link.open_external=2). Having external applications open links in a random window as a new tab (default setting) is very confusing for the end user. There needs to be a differentiation as it was clearly explained in the comments above. IMHO both options should be available through the options menu: * Open links that are requested to be opened in a new window in [the current tab] | [a new tab of the active window] | [a new window] * Open links from external applications in [the current tab] | [a new tab of the active window] | [a new window] I don't think this would be asking too much intelligence from the end users. Also I'd like to point out, that the target attribute was deprecated for a reason. Therefore I'd make it the default setting to open all links in the current tab despite of what the target attribute says. I know it's radical. Don't hate me. ;-)
I don't think the comments in this bug are read by currently active UX people, so adding comments to this bug will not lead to any changes. It doesn't seem that there was an answer to the objections from the development team, so I think that there's a chance you'll get it if you post a summary of the objections and the request for clarification in mozilla.dev.apps.firefox.
I'm adding to the chorus of others: the loss of the ability to set different behavior for an external-app-opened link vs. a "_blank"/window.open() link opened within a current browser session is a HUGE regression. My own usage is like that of #51 and #52, and I should _not_ have to track down and load some sort of huge tag-arranging extension to get back what was a deliberately chosen by me via about.config behavior in previous versions. If the comments in this bug are not currently being read by the active UX people, then someone with access to them needs to drag them back to it, and quick. Otherwise, there WILL continue to be numerous openings of (duplicate) bug reports for this regression by people who don't know this was a deliberate change.
I've created bug #509664 for those who want the old behaviour back. So instead of (or in addition to) posting a "me too" here, you can vote there. I personally wouldn't want to vote for the bug here, which removed the functionality in the first place, as I'm not sure how taht would get interpreted. I also hope that a new, unclosed report will get developers to take notice of this issue.
Thanks for opening that bug. I voted there and removed my vote here as you suggested.
The functionality that was lost to this "cleanup" is to be discussed and voted upon in bug 469082; bug 509664 was already closed (not by myself) as a duplicate.
FAIL. Sometimes I think FF succeeds despite the main developers, rather than because of them. As usual user feedback is ignored and genuine issues written off as not being part of the latest brilliant new UI "enhancement" Moz came up with. Anyway, as per the standard solution to all UI regressions, here is yet another add-on created specifically to bring back the old, sensible and non-destructive behaviour: https://addons.mozilla.org/en-US/firefox/addon/13626 I have noticed something about FF. Every time there is a new major version number bump, I have to install more add-ons and more css hacks. I wonder, is it is possible to not break things for very large numbers of users next time please? We all like new features, but unless there is some security issue old ones should no be taken away.
I recommend acquiring the humility to consider the possibility that you might be wrong; intuition does not always make for the correct choice when designing user interfaces. Try the new setting for a week or two, then switch back to your preferred setting and give it a shot. Also consider that what may be right for you may not be right for users in general. Finally, have you ever described any piece of software as "bloated"? That comes of death by a thousand cuts, not by big things easily trimmed. Also worth considering: a little detachment goes a long way in avoiding poisonous arguments which may be worse than the original problem itself. There are much more important things in the world about which you can get this worked up, with better cause, than these little changes in your browser.
Jeff, your attitude is I'm afraid the exact problem I am talking about. I did try it for a few weeks, and it was incredibly annoying. I often ended up destorying a tab I had open, sometimes when I hadn't even clicked anything (e.g. a program opening a web site during an (un)install). The default settings are not much better, and the loss of control over how tabs work in a program I use every day is a "little change" for me. I'm not sure what you mean with the "death of a thousand cuts" comment. Perhaps you mean that by keeping all these extra preferences in it would bloat the code. The modifications would actually be pretty small, and besides my own point was that FF is getting more bloated for long time users because we keep having to install more and more add-ons and hacks. As you say, there are much bigger and more productive targets for reducing program size than removing a few lines of code for some preferences. It wouldn't affect the UI either as they are all hidden in about:config. I have looked in to contributing code to FF myself. I even installed Ubuntu in a VM to get a reasonable development environment, but lack of documentation is making it hard to figure out what needs to be reverted. On top of that it seems like a lot of work for something which will be rejected anyway, and an add-on was easier. Tell you what, if you can guarantee that a patch which restores the removed preferences and behaviour while not affecting the new model and of good quality will be accepted I'll make an effort to create one. I'd like to make another suggestion too. Why not create a better web site for discussing new features and changes with user. The current developer pages clearly are not working, and never get much publicity. A better site where people can comment and developers really, genuinely listen would solve a lot of problems. I'd set one up myself but to work it would need official backing and promotion. Something like a front page link and RSS feed.
"I recommend acquiring the humility to consider the possibility that you might be wrong; intuition does not always make for the correct choice when designing user interfaces." Consistency doesn't always make for the correct choice when designing a UI either, Jeff; and consistency is the only motivation behind this change.
**** happens - I noticed that change now wondering, why my setting does not work any more. :-((( I had it set this way for good reasons and now the option has been removed...
If I could vote against this, I would. It's a shame I always end up finding out about these things after getting frustrated with Firefox and having to search for a reason. At least Moz had the 'courtesy' of linking to this bug where the about:config documentation is found, so I can find out why Firefox now behaves stupidly, and without a way of letting me revert back. However, it would have been more courteous to ask people whether they wanted to keep it, first. This kind of consolidation decreases usability and doesn't improve performance or maintainability in the slightest. I agree with comment #60
This needs to be re-opened. Leaving the preference (especially as a hidden pref) does not harm anyone. On the other hand, destroying it as you have done causes harm. Example: I use multiple windows, one for each task. I use tabs for different pages within each task or related window. When I click a link in my instant messenger it's not related to any of them. Yet Firefox picks a random window to open it in. This violates the principle of least surprise. I couldn't agree more with comment #65: "It's a shame I always end up finding out about these things after getting frustrated with Firefox and having to search for a reason. [...] Firefox now behaves stupidly, and without a way of letting me revert back."
I want links I click on from third-party applications to open in the current tab. Using 3.6 causes me to close unmanageable number of tabs after some use.
Removing this functionality was a bad idea. If you want this functionality restored then I would suggest voting for Bug 509664. (Not that community/user votes ever lead to anything being done in this project)
You need to log in before you can comment on or make changes to this bug.