314814 - Not all links that open new windows are diverted

Status: RESOLVED FIXED

(Firefox Graveyard :: Help Documentation, defect)

Description

[u60234]

Bug 313300 changed the default value for the browser.link.open_newwindow.restriction pref so that windows with specific features are no longer diverted with the "Force links that open new windows to open in:" option.

Lacking a proper label for this option, it would be good to at least have this exception explained in the Help documentation.

Comment 1

[Jeff Walden (gone starting June 8)]

I might be able to get to this, but right now I'm not sure.  Tentatively targeting this at 1.5 as it doesn't look difficult and will probably confuse people...

Comment 2

[Steffen Wilberg]

Attachment: patch v1.0

This only applies to the "open in a new tab", not to the "open in the same tab" setting.

Comment 3

[Jeff Walden (gone starting June 8)]

Comment on attachment 201964 [details] [diff] [review]
patch v1.0

>+    If you have chosen to open links in new tabs, &brandShortName; will
>+    nonetheless open them in a popup window if the page author has specified
>+    that the popup should appear as a certain size.</p>

This feels stilted, particularly the "nonetheless" part.  I really feel that the whole idea we're trying to convey here is completely "ugh"; I remember going through exactly this confusion back when I first read about the preference after it had been checked into the source code.  Does the following sound any better, at all?  If you think it does, I think we can add this where you made your addition, style it so it looks like the rest of our "Note:"s do, and ask for approval:

Note: if you have chosen to open links in new tabs, &brandShortName; will ignore this &pref.singular; and will open a new window from a link if the page author specifies that the new window should have a specific size, because some pages can only be displayed correctly at a specific size.

This exception, while well-intentioned and probably for the better, is really starting to annoy me.

Comment 4

[Steffen Wilberg]

Attachment: patch v1.0.1

The name of the pref doesn't completely match the UI, which makes it unpleasant to document, but I like the new behaviour.
Your suggestion is indeed an improvement, and it tries to explain the behaviour. We're too late for RC2 anyway, so have a second look.

Comment 5

[Jeff Walden (gone starting June 8)]

Comment on attachment 202552 [details] [diff] [review]
patch v1.0.1

The change from "specifies" to "specified" makes sense to me, as the page (or page code) would have been written before the user actually saw it.  Also, for the record, I think I have this behavior enabled in my user.js, so what dislike I do have for it is more from a consistency standpoint than anything else.

Sorry about being slow on the review; I've been moderately busy recently, but last week was truly horrible.

Comment 6

[Steffen Wilberg]

> so what dislike I do have for it is more from a consistency standpoint than anything else.
Indeed!

Trunk checkin:
Checking in mozilla/browser/locales/en-US/chrome/help/prefs.xhtml;
/cvsroot/mozilla/browser/locales/en-US/chrome/help/prefs.xhtml,v  <--  prefs.xhtml
new revision: 1.42; previous revision: 1.41
done

Comment 7

[Mike Schroepfer]

Comment on attachment 202552 [details] [diff] [review]
patch v1.0.1

Please land on 1.8 and 1.8.1 branches.

Comment 8

[Steffen Wilberg]

Checked into 1.8 and 1.8.0 branches.

Comment 9

[Dave Liebreich [:davel]]

verified landed in build 2006010904 (mac)

Comment 10

[Dave Liebreich [:davel]]

verified on mac, build 2006011103 (a 1.8.0.1 build)