258076 - Document new tab prefs

Status: RESOLVED FIXED

(Firefox Graveyard :: Help Documentation, defect)

Description

[Jeff Walden (gone starting June 8)]

Document the stuff to be added for bug 172962 (which would also seem to fix bug
227241, which somehow got absorbed into it in terms of the possible patch).  For
now, as no actual UI exists, what will happen will be something like this in
prefs.xhtml:

<!--h2>Tabbed Browsing</h2>

<p>Blah blah blah new prefs docs...</p-->

...and in the index and ToC:

<!--rdf:li the-proper-attributes="the-proper-values"/-->

Thus, they'll be shut off from actual display but will still be present for
localizer use.

Comment 1

[Jeff Walden (gone starting June 8)]

Attachment: Adds descriptive text - text needs work

Steffen, what do you see that's wrong with the wording this patch would
introduce?  It's definitely junky, but right now I'm having trouble coming up
with something better.

Comment 2

[Jeff Walden (gone starting June 8)]

Comment on attachment 158191 [details] [diff] [review]
Adds descriptive text - text needs work

Pinging Steffen so he'll see this when he gets back...

Comment 3

[Jeff Walden (gone starting June 8)]

I'm working on this and hope to have it finished soon.  As Help is an optional
component for localizations, however, this may or may not be a blocker.  It's
still worth clarifying.

Comment 4

[Asa Dotzler [:asa]]

not a blocker but we'd take reviewed patches.

Comment 5

[Steffen Wilberg]

Comment on attachment 158191 [details] [diff] [review]
Adds descriptive text - text needs work

>+<!-- LOCALIZATION NOTE watch for slight advanced prefs UI reorganization when
>+                       bug 172962 is fixed, currently targeted for 1.0 - can't
>+                       be worked around now because Browsing absorbs Multimedia
>+                       and loses a few prefs to new Tabbed Browsing section -->
Browsing absorbs Multimedia? And looses a few prefs to Tabbed Browsing?
Bug 172962 doesn't do that. Attachment 158455 [details] [diff] introcuces a new Tabbed Browsing
section, which only contains the new prefs. Is there another bug to reorganize
the prefs?

>+<!--
>+  <h3 id="tabbed_browsing">Tabbed Browsing</h3>
It's Windows only, see bug 172962 comment 82.

>+  <p><em>Open links from other applications in:</em><br/>When other
>+    applications on your computer display a web page, &brandShortName; opens the
>+    page in a new window.  You can change this behavior by selecting a different
>+    option.</p>
The default option of the pref "browser.openlink.external" is 1, see attachment
158459 [details] [diff] [review], which is "&recentWindowOrTab.label;", which displays "the most recent
tab/window". So that's the default, not opening in a new window.

>+  <p><em>Force links that open new windows to open in:</em><br/>&brandShortName;
>+    opens new windows from links you visit when web pages request that the links
>+    be opened in new tabs.
I'm confused. I think the links request to be opened in a new *window* (they
know nothing about tabs). So Firefox does right that: open a new window. If I
read attachment 158459 [details] [diff] [review] correctly, that will still be the default.

>     If you prefer to use tabs as you browse, this
>+    behavior may be counterproductive.  You can force &brandShortName; to open
>+    links that would normally be opened in a new window to instead be opened in
>+    new tabs or in the current tab/window by changing this option when it is
>+    enabled.</p>
Exactly. But can we make "when it is enabled" more active? I mean it's the user
who has do enable it. Something better than "enable this option and select the
appropriate choice"?

Comment 6

[Jeff Walden (gone starting June 8)]

(In reply to comment #5)
> Browsing absorbs Multimedia? And looses a few prefs to Tabbed Browsing?
> Bug 172962 doesn't do that. Attachment 158455 [details] [diff] introcuces a new Tabbed Browsing
> section, which only contains the new prefs. Is there another bug to reorganize
> the prefs?

See the just-posted bug 172962 comment 84 (or more correctly, the eventual
response).

> It's Windows only, see bug 172962 comment 82.

Done after I posted the patch here, but of course still a problem.

> The default option of the pref "browser.openlink.external" is 1, see attachment
> 158459, which is "&recentWindowOrTab.label;", which displays "the most recent
> tab/window". So that's the default, not opening in a new window.

Also done after I posted -- I assumed the current behavior would stay the
default behavior.

> I'm confused. I think the links request to be opened in a new *window* (they
> know nothing about tabs). So Firefox does right that: open a new window. If I
> read attachment 158459 [details] [diff] [review] correctly, that will still be the default.

This looks like me being stupid (or at the least slightly befuddled).

> Exactly. But can we make "when it is enabled" more active? I mean it's the user
> who has do enable it. Something better than "enable this option and select the
> appropriate choice"?

That sounds like a good idea to me; I'll do something like that after I get a
response to the previously-mentioned comment.

This is now on hold until unresolved issues in prefs UI possibilities are fixed.

Comment 7

[Steffen Wilberg]

The patch in bug 172962 has been updated.

We also need to document the new "Select new tabs opened from bookmarks or
history" pref, which was introduced by bug 251770 a few days ago. Probably too
late for 1.0PR, so let's do it in this bug.

Comment 8

[Steffen Wilberg]

The patches for bug 172962 have been checked in. Check it out :)

Comment 9

[Jeff Walden (gone starting June 8)]

The prefs this describes are all completely cross-platform now, right?  I'm
going to (have to) get to this tonight, and I'll likely be editing the previous
patch so that it's fully correct.  Steffen, if you're online tonight any time,
send an email with times so that I can get something done before then so you can
look at it quickly.  This is coming down to the wire, but real life is
interfering right now enough that I really can't spare a whole lot of extraneous
time beyond that required to update the patch.

It'll be nice once Help's frozen; it's one less deadline in my life.

Comment 10

[Jeff Walden (gone starting June 8)]

Attachment: Second try

Okay, let's try this.

Comment 11

[Jeff Walden (gone starting June 8)]

Comment on attachment 162124 [details] [diff] [review]
Second try

Pinging Steffen, hoping he's still around...if not, I'll be checking this in
for 1.0 anyways, because its absence is a big problem with prefs documentation.

Comment 12

[Steffen Wilberg]

Comment on attachment 162124 [details] [diff] [review]
Second try

>+  <p><em>Open links from other applications in:</em><br/>When other
>+    applications on your computer display a web page, &brandShortName; opens the
>+    page in a most recently displayed tab or window.  You can make
s/a/the/

>+  <p><em>Force links that open new windows to open in:</em><br/>&brandShortName;
>+    opens new windows from links when web pages request them.  If you prefer to
>+    use tabs as you browse, this behavior may be counterproductive.  You can
>+    force &brandShortName; to open links that would normally be opened in new
>+    windows to be opened elsewhere if you desire.  To do so, select the checkbox
>+    for this &pref.singular; and choose the behavior you desire.</p>
Can you replace one of the "desire", please?

>   <p><em>Select new tabs opened from links</em><br/>When you middle-click on
>@@ -434,36 +467,22 @@
>     button), the links will be opened in a new tab. That tab will not be shown
>     directly; it will be loaded in a background tab. Check this &pref.singular; to load
>     the link in a foreground tab instead, which will show that tab
>     directly.</p>
> 
>+  <p><em>Select new tabs opened from bookmarks or history</em><br/>When you open
>+    bookmarks or web pages from your browsing history in a new tab,
>+    &brandShortName; automatically selects the tab and displays the newly-opened
>+    web page.  You can make &brandShortName; open these tabs but not select them
>+    by selecting this &pref.singular;.</p>
The last sentence is wrong. And we shouldn't use the word "select" because
that's what we want to explain. I prefer the explanation above, with background
and foreground tab. Can't we just say something like "same as above, but for
tabs opened from bookmarks or history"?

Comment 13

[Jeff Walden (gone starting June 8)]

Fixed branch and trunk with this text for "select from bookmarks":

> When you open
> bookmarks or web pages from your browsing history in a new tab,
> &brandShortName; automatically selects the tab and displays the newly-opened
> web page.  Uncheck this &pref.singular to load bookmarks and pages from your
> browsing history in a background tab.