313300 - change default for browser.link.open_newwindow.restriction to "2" (don't divert window.open w/features)

Status: RESOLVED FIXED

(Firefox :: Tabbed Browser, defect)

Description

[Mike Beltzner [:beltzner, not reading bugmail]]

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 1

[Adam Guthrie]

Attachment: patch

Comment 2

[Mike Beltzner [:beltzner, not reading bugmail]]

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 3

[Mike Connor [:mconnor]]

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)

Comment 4

[:Gavin Sharp [email: [e-mail]]]

Branch: mozilla/browser/app/profile/firefox.js; new revision: 1.71.2.15;
Trunk: mozilla/browser/app/profile/firefox.js; new revision: 1.88;

Comment 5

[Anton van Bohemen]

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?

Comment 6

[Ali Ebrahim]

/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?

Comment 7

[Mike Beltzner [:beltzner, not reading bugmail]]

(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. 

Comment 8

[Jay Patel [:jay]]

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.

Comment 9

[Mike Beltzner [:beltzner, not reading bugmail]]

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.

Comment 10

[Worcester12345]

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.

Comment 11

[Worcester12345]

(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?

Comment 12

[Mike Beltzner [:beltzner, not reading bugmail]]

(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.

Comment 13

[Worcester12345]

(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.

Comment 14

[Peter Helcmanovsky]

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..

Comment 15

[Peter Helcmanovsky]

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.

Comment 16

[:Gavin Sharp [email: [e-mail]]]

(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).

Comment 17

[Jesse Ruderman]

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.

Comment 18

[Phil Ringnalda (:philor)]

*** Bug 307790 has been marked as a duplicate of this bug. ***

Comment 19

[Phil Ringnalda (:philor)]

*** Bug 350356 has been marked as a duplicate of this bug. ***