Closed Bug 313300 Opened 16 years ago Closed 16 years ago
change default for browser
.link .open _newwindow .restriction to "2" (don't divert window .open w/features)
Bug 308396 suggested many behavioural changes to tabbed browsing which were a little too risky to take for 1.5, but one change suggested therein which is not at all risky and which is the right thing to do is to change the default value of browser.link.open_newwindow.restriction from 0 (divert all window.open calls to tabs) to 2 (don't divert window.open with features). This allows for user-initiated pop-ups where the page author specified that the popup should appear as a certain size (ie: "pick your media player" or MT comments popups) I'm missing my build tree at the moment, but if someone could patch browser/app/profile/firefox.js such that: -pref("browser.link.open_newwindow.restriction", 0); +pref("browser.link.open_newwindow.restriction", 2);
Comment on attachment 200374 [details] [diff] [review] patch Asa & triage team, this is a low-risk pref flip for people who have chosen the "force links that open in new windows to open in new tabs" option so that we do the right thing with popups that are authored to be a certain size. Requesting that it makes it into 1.5rc1 ...
Comment on attachment 200374 [details] [diff] [review] patch This missed the boat for beta2 in the tabbed browsing kerfuffle, but everyone agreed this is the desired behaviour for 1.5, especially now that we have these prefs exposed (we didn't in 1.5)
Attachment #200374 - Flags: approval1.8rc1? → approval1.8rc1+
Branch: mozilla/browser/app/profile/firefox.js; new revision: 18.104.22.168; Trunk: mozilla/browser/app/profile/firefox.js; new revision: 1.88;
Assignee: nobody → ispiked
Target Milestone: --- → Firefox1.5rc1
Status: NEW → RESOLVED
Closed: 16 years ago
Resolution: --- → FIXED
Oh my god... File a new bug, and it suddenly will get fixed... Check out bug 266299 if you don't know what I mean. Had a change of mind, Mike?
/me wakes up from long Bugzilla slumber to post this I must be missing something here. In bug 266299 it was clearly resolved to *not* do this. Now all of a sudden a new bug is filed and within one day a "fix" is checked in? The pref says (I quote) "Force links that open new windows to open in" and I've chosen the option "a new tab". Based on my reading of this pref, if a link opens a new window, it should open in a new tab (no questions asked)! Any other behaviour where it only does this sometimes is simply broken. Users who set this pref do so by choice, since it is not a default. Since they obviously want the pref to do what it says, doesn't it make sense for the application to do so?
(In reply to comment #6) > I must be missing something here. In bug 266299 it was clearly resolved to > *not* do this. Now all of a sudden a new bug is filed and within one day a [...] > obviously want the pref to do what it says, doesn't it make sense for the > application to do so? Bug 266299 ended up being half about changing the default and half about exposing that choice in the UI, which was the reason for its wontfixing. FWIW, I don't agree with Jesse's assessment in bug 266299 comment 14, but let's not waste time splitting semantic hairs. The default pref was changed because a) after prolonged testing, we suspected that it would "felt" more natural to most users, and b) usability research confirmed that suspicion. There are a good number of sites out there which legitimately use sized-popups for small non-modal web application UI (most commonly "pick your media player" or "enter a comment" or other small form data) which are designed to be rendered at the specific resolution and look & feel awkward when forced into a full tab.
Mike: I see what you're saying, but I still think a user that goes into the prefs and sets "FORCE links to open in tab" will be expecting his user experience to be contained within the browser window. Making exceptions for various sized windows and js windows or whatever, just goes against having that pref there IMHO. Perhaps we can add checkboxes for "ALL links" and "HTML links" so that most of our users will be able to choose. I know the pref can be flipped manually, but I don't expect a lot of our normal users to go digging through about:config to change things. Early feedback on RC1 suggests that users are getting annoyed/confused about a blank windows being opened when they click on a js link.
What's the use case where they're clicking on links and getting a blank window opening? Or do you mean that you're seeing feedback about how they're getting annoyed that windows are actually popping up? I would totally support rewording of that tabbed browsing dialog, but there's no way that's gonna get in (as you probably know) for 1.5. Please see bug 308396 for a bunch of suggested UE improvements to tabbed browsing, including some reswizzling of our options.
Is SingleWindow extension still working? Maybe it is time to pull that out of mothballs to make the browser do what it is supposed to do.
(In reply to comment #8) ... > change things. Early feedback on RC1 suggests that users are getting > annoyed/confused about a blank windows being opened when they click on a js > link. > Isn't "Disable Targets for Downloads" the extension which fixes that broken part of the interface? I still have that one installed. Is there a log somewhere of what is attempted to be opened?
(In reply to comment #10) > Is SingleWindow extension still working? Maybe it is time to pull that out of > mothballs to make the browser do what it is supposed to do. Please keep this traffic of Bugzilla and in MozillaZine. Thanks.
(In reply to comment #12) > (In reply to comment #10) > > Is SingleWindow extension still working? Maybe it is time to pull that out of > > mothballs to make the browser do what it is supposed to do. > > Please keep this traffic of Bugzilla and in MozillaZine. Thanks. > I meant that as a possible solution to this bug. The SingleWindow extension used to do this job very well. Perhaps there is something to be learned from the code used there.
I don't like this change. And when *I* wish for #314771 ... I'm answered with "do it yourself in an extension". :( Actually I badly wish for an option to DISABLE non-resizable/non-minimize/non-maximize windows, so all windows will be resizable like normal windows. What's good on resize disabling? Is it like "our users are stupid, they don't know how to set size of window to like them, so we must force the window to have the only correct size."?) I really hate those web pages, who open non-resizable 100x100 pix windows with some important text in it, and my "minimum font size" setting is preventing me from reading whole text without copying it from the window into some notepad/etc..
Actually this "bug fix" will just make the bug 314771 happen more often for me and this is exactly the reason why I don't like the new behaviour. Because than the small window opens new window either in new tab in the small window, or in completely new big window... I want new tabs, not windows. The more I think about it, the more angry I feel, I will rather stop now and try to calm down. I just don't see the "easy to use UI" behind this concept, I wonder why "usability research" yielded different results. Maybe completely different favourite web sites and scenarios. Sorry for double posting, but I did see this connection of those two just couple of seconds after I posted the first comment.
(In reply to comment #14) > Actually I badly wish for an option to DISABLE > non-resizable/non-minimize/non-maximize windows, so all windows will be > resizable like normal windows. That has nothing to do with this bug, and there's already a preference to control that behavior (dom.disable_window_open_feature.resizable, set it to true to get what you want).
See also counter-bug, bug 314721, "The option 'Tools > Options > Tabs > Force links that open new windows to open in:' no longer works." Quite a few users were confused by this change and/or unhappy about it.
*** Bug 307790 has been marked as a duplicate of this bug. ***
*** Bug 350356 has been marked as a duplicate of this bug. ***
You need to log in before you can comment on or make changes to this bug.