161466 - Better UI for tabbed browsing prefs.

Status: VERIFIED FIXED

(SeaMonkey :: Preferences, enhancement)

Description

[Bamm Gabriana]

It would be much simpler is Mozilla had a "Tabbed Mode" and a "Windowed Mode".

In Windowed Mode, we would have the following:
1) Ctrl+Click on a link opens in a new window
2) Ctrl+Click on a bookmark opens it in a new window
3) Ctrl+Enter at the location bar opens URL in a new window
4) "File | New >" menu has "Navigator Window" on top, and "Navigator Tab" is
invisible.
5) Right-click on a link has "Open in New Window" on top, and "Open in New Tab"
is invisible.
6) target="_blank" opens in a new window

In Tabbed Mode, we would have the following:
1) Ctrl+Click on a link opens in a new tab
2) Ctrl+Click on a bookmark opens it in a new tab (Bug 72361)
2b) Ctrl+Click on a bookmark folder opens each bookmark in separate tabs (Bug
142683)
3) Ctrl+Enter at the location bar opens URL in a new tab
4) "File | New >" menu has "Navigator Tab" on top, followed by "Navigator Window"
5) Right-click on a link has "Open in New Tab" on top, followed by "Open in New
Window"
6) target="_blank" opens in a new tab

This means that we should combine all tabbed browsing prefs into a single
UI pref. I imagine the checkbox to read:

[ ] Enable Tabbed Browsing

Checking it would enable tabbed mode. Note that the Window options will still be
available in tabbed mode, but no longer the default. This will allow users to
use a combination of tabs and windows by opening related tabs in the same window.

Advantages are:
1) Fewer prefs
2) Less UI clutter in windowed mode
3) When enabling tabs, you simply turn the menu's visibility to true. No more
switching places as described in Bug 149297. It's always on top but not always
visible
4) Greater consistency in UI
5) Windowed mode resembles UI of browsers without tabbed browsing, such as older
versions of Netscape.

This method makes it much simpler and makes it easier to promote tabbed browsing
because a single pref enables all.

It's also press-friendly because it makes it easier for them to describe
Mozilla's tabbed browsing feature.

Comment 1

[Jason Bassford]

I agree that this is good "in theory" - but you are going to run into some
problems.  As an example, see bug 149287 comment 1 - here's a user who uses
tabbed browsing all the time, but who wants New Window above New Tab because he
wants the most *infrequent* thing he does listed first in the context menus.

So, right away, he'll disagree with points 4 & 5 of your Tabbed Browsing mode. 
It actually came as a surprise to me, after having opened bug 149287, that
tabbed browsers would NOT want to have New Tab at the top, but apparently it's
so.  Hence my change of focus in that bug away from a hardcoded solution.

What MIGHT come out of this bug is a set of "default" preferences based on a
main one betweeen tabbed browsing and windowed browsing along the lines of:

Select browsing mode:

( ) Use Tabs   ( ) Use Windows

[Advanced...]  [Reset]

That way, the other preferences are not immediately exposed to the average user,
and picking one mode or the other can tune the fine-grained preferences to a
"reasonable" set of behaviour.

(The only thing I'm not sure about in terms of the UI above is the "Reset"
button.  I added this just as a way for the user revert any customized changes
(via Advanced..) to the default settings of the "Tab" or "Window" mode already
selected.  But the wording needs to be better.)

All of that aside, I think that it *IS* a good idea to explicity state which
mode the user, in general, likes to use.  Several other bugs could make use of
this in their own resolution.  (Rather than making assumptions based on the
setting of a fine-grained control that may not accurately reflect reality.  So
far, "Middle-click or control-click of links in a Web page" has been the "best"
indicator of tabbed browsing use - but it's not completely ideal.)

Confirming and changing platform/OS to All.

Comment 2

[Jason Bassford]

bug 149287 comment 1 -> bug 149297 comment 1

Comment 3

[Bamm Gabriana]

I think I like your suggestion better than what I originally wrote.

Here is a slight improvement of your suggestion, patterned after the Win98
folder options dialog.

Select browsing mode:
( ) Do not use tabs. (Always open new windows)
( ) Open tabs instead of windows.
( ) Custom, based on settings you choose: [ Advanced ]

The Advanced button would open a box that contains the six or seven cases
outlined above. The Reset button becomes unnecessary because he can just choose
either of the first two options.

Comment 4

[Jason Bassford]

Yes, your UI approach is better.  But I think that the top-level UI should be
simplified:

Select browsing mode:
( ) Open new windows.
( ) Open new tabs.
( ) Customize behaviour: [Advanced...]

If the user isn't certain what the implications of "Open new tabs" is, they can
always click on the [Advanced...] button (even if they haven't checked the
"Customize behaviour" box) and see how things are currently set.  If they decide
to actually change one of the prefs from the browsing mode default, then the UI
would automatically change so that "Customize behaviour" is selected next time
they view that panel.  (If they don't want to change anything, they can just
cancel out of the Advanced dialogue.)

I suggest changing the Summary of this bug to something along the lines of
"Better UI for tabbed browsing prefs." since, if you agree with me, it's morphed
away from a single pref.  (It's just grouping the individual prefs in a much
more easily understood fashion.)

Comment 5

[Bamm Gabriana]

I agree. Summary changed...

Comment 6

[Bamm Gabriana]

Here's how I imagine the Advanced dialog box, for now.

Custom Tab Settings:
[ ] Ctrl+Click or Middle-Click on a link opens it in a new tab
[ ] Ctrl+Click or Middle-Click on a bookmark opens it in a new tab
[ ] Ctrl+Click or Middle-Click on a bookmark folder opens each bookmark in
    separate tabs
[ ] Ctrl+Click or Middle-Click of a navigation button or history item opens
    the page in a new tab
[ ] Ctrl+Enter at the location bar opens URL in a new tab
[ ] Targeted links open in a new tab
[ ] Show Tab Menus

Note that the "Show Tab Menus" option applies to both the "New > Navigator Tab"
menu and the "Open in New Tab" menu, since it makes sense to have consistency
between the two menus.

People who want window menus on top can simply deselect it. People who want the
tab menus on top can select it and it magically appears on top of the window menus.

Can we identify which bugs this depend on?

Comment 7

[Jason Bassford]

Something else to consider: Since we're letting people choose between "Windowed"
and "Tabbed" browsing, we should probably also include in these preferences
those that apply only to Windowed browsing.

As an example: Ctrl-Click on a link.  As you've currently defined things, if the
box is checked a Ctrl-Click will open a new tab.  If it's unchecked, I assume
you're thinking that it will open a new window.  But are there not people who
want Ctrl-Click to do neither of these things?  In such a case a simple "on/off"
preference is insufficient.

Another example: Load links in the background.  Currently this applies to tab
browsing, but it could equally apply to windowed browsing.  (People might want a
new window opened, but they want the focus to remain on the current window - bug
105977.)  But this opens up a situation that has at least 3 options - load links
in the current window/tab, load them in a background tab, load them in a
background window.  Again, a simple "on/off" preference is insufficient.

Due to this, the whole Advanced section needs to be reworked to list a section
for each mode of browsing:

TABBED BROWSING

Tab Display

( ) Hide the tab bar when only one tab is open
( ) Load links in the background

Open new tabs for

( ) Middle-click or control-click of links in a Web page
( ) Control+Enter in the Location bar


WINDOWED BROWSING

Open new windows for

( ) Middle-click or control-click of links in a Web page
( ) Control+Enter in the Location bar

...and so on.

Anything that *IS* a simple on/off, like the order of New Tab / New Window,
could be located in just one of the sections - probably the Tabbed Browsing section.

We should work on redesigning the Tabbed Browsing preferences panel as it stands
today, then add more preferences as the appropriate bugs are fixed and their
additions make sense.  (I don't see any reason not to check in a patch for this
right now - then expand it as things progress.)  As such, the redesign really
has no dependencies, but implementing a complete version (as per your initial
report) does.

I'll see if I can come up with some bug dependencies for the "final" version. 
Note, however, that some of these bugs, if they're fixed, may not end up being
preference based, but could be hard-coded instead.  Still, here are some
possibilities.  Also, I'm not sure which way the dependencies should really be
going here on some of these bugs but, for now, I'm marking all the other bugs as
blocking this one.  You can remove those dependencies you don't like, add others
that I may have missed:

bug 9274  : Open multiple links in new windows.
bug 56690 : Shortcut to open links in background window.
bug 72361 : Ctrl-click a bookmark should open in new window / tab.
bug 103843: JavaScript created windows should appear as tabs.
bug 105547: Windows open in new windows instead of tabs.
bug 105977: Pref to open links in background window.
bug 121969: External apps should open new tabs, not windows.
bug 124973: Disable tab browsing.
bug 142683: Ctrl-click a bookmark folder.
bug 149297: Consistent New Window / New Tab menu order.
bug 152625: Tab group load focus ignores "load in background" pref.
bug 155402: URLs no longer launch in new window from external app.

Comment 8

[Boris Zbarsky [:bzbarsky]]

> People who want window menus on top can simply deselect it

I'm not sure this is such a great idea (as a user who mostly opens new windows
but does new tabs in some special cases, like bulletin board sites or
documentation).  This gives primarily-new-window people the choice of
hard-to-reach options or no tabs at all.

Comment 9

[Bamm Gabriana]

Jason: That is also a good suggestion. I was wondering though if it was useful,
since a person who does not want to open a new window or tab would simply click.

Did you really mean to use radio buttons? I think you meant check boxes.

Thanks for the list of related bugs. We should keep them so as not to lose focus
about the scope of this bug.

Comment 10

[Bamm Gabriana]

Boris: You can choose your individual settings via the Advanced button. In your
case you can either:

1) Ctrl+Click to open a new window and show Open in New Tab on top of the menu, OR
2) Ctrl+Click to open a new tab and show Open in New Window on top of the menu.

Comment 11

[Boris Zbarsky [:bzbarsky]]

Well.... To be completely honest, I never use control click, and never want
to... and I would much prefer my "Open In New Window" at the top of the menu.

I realize I'm being picky, but as long as you're defining an explicitly
"advanced" UI, you may as well make it flexible...

Comment 12

[Bamm Gabriana]

What would you suggest then? It seems to me that Middle-Click would be much
faster than Right-Click, Slide-Down and Click.

Comment 13

[Boris Zbarsky [:bzbarsky]]

Yes... but middle-click is how new windows get opened.

I would suggest having the option of having both items in the contextmenu, with
"new window" first.

Comment 14

[Bamm Gabriana]

Hmm, I read from another bug that interchangeable menus would be confusing to
new users who have to use more than one computer. However, that argument seems
to be negated by this being an Advanced menu, so it might be ok.

I imagine though that it will be easier to code a visibility toggle than
interchanging items.

Can you please describe how you would imagine our "Advanced" menu? Maybe we can
put our ideas together to come up with something flexible and intuitive.

Comment 15

[Boris Zbarsky [:bzbarsky]]

Yes, it would be harder to code.

If I think of a decent way of expressing this in UI, I'll say... Consider it
user feedback for the time being.  ;)

Comment 16

[Jason Bassford]

> This gives primarily-new-window people the choice of
> hard-to-reach options or no tabs at all.

I'm not sure if I'd call an Advanced... button hard to reach.  I like the
simplicity of choosing one mode or the other.  If they really do want something
more fine-grained they can still customize.  I will grant, however, that the
Advanced prefs should be reworded as well as redesigned in general so as to be
more friendly (my last example is still "wrong" in a lot of ways), and that we
should supply better help.

> a person who does not want to open a new window or tab would simply click.

Yes, but we still need to define what happens when they Ctrl-click - and I don't
like just unchecking it from the one section.  (I now believe I was wrong to
think that it might do nothing.)  Perhaps rather than simply repeating the same
"general" pref in each section we can combine them as a kind of chart.

Second attempt at an Advanced... menu - using all dependent bugs and points from
the original description of this bug:

Overall

[ ] Disable tabbed browsing UI
[ ] Hide the tab bar when only one tab is open
[ ] Load links in the background

New Tabs / Windows                       new tab   new window   current view

Ctrl-click or middle click opens         ( )       ( )         
Control+Enter in the Location bar opens  ( )       ( )         
Ctrl-click a bookmark opens in           ( )       ( )
Open multiple links in                   ( )       ( )         
External application URL opens in        ( )       ( )          ( )
JavaScript created window opens in       ( )       ( )          ( )

Menus list new tabs ( ) first
                    ( ) last
                    ( ) not at all

Note that I'm combining 4) and 5) in the original description of this bug.  Bug
149297 rules out inconsistency between the context and main menus.

> Did you really mean to use radio buttons?

No, you're correct. I'd meant to use check boxes.  However, see above where I
*do* mean to use radio buttons. <grin> I like this example a lot better than my
previous attempt.

I also agree that the more flexible we make this, the better.  So long as we
ensure it doesn't grow to be TOO complex.  There needs to be a balance between
customizability and simplicity.

Comment 17

[Bamm Gabriana]

You forgot to mention targetted links, navigation buttons (back, forward) and
history items.

But isn't this becoming a little too complex? We might be losing the
intuitiveness of the approach.

Comment 18

[Jonas Jørgensen]

Yay, more prefs!

Comment 19

[Jason Bassford]

> You forgot to mention targetted links, navigation buttons
> (back, forward) and history items.

I realised the lack of targeted links right after I posted and read the result.
 But they can be simply added.  I had to re-read all of your comments here to
figure out where navigation buttons and history items came from - they weren't
mentioned in the original description that I can see but in comment 6.  By these
you mean Ctrl-click on the dropdown menu items?  Has anybody opened a bug on
this feature yet?  In any case, they too can be simply added.  It was the format
of my example that was more important than the specifics.

> But isn't this becoming a little too complex?

Given the number of prefs that we'll have to accomodate (assuming all of the
dependent bugs here ARE fixed) I see no way around this.  The best we can do is
get the UI as friendly as possible.

> Yay, more prefs!

<grin> They aren't really being generated by this bug, but by all of the other
dependent bugs.  Unless the UI is redesigned from its current state, when they
are all checked in (if they are) it's going to be a real mess.

I will grant that there are, in a sense, 3 additional prefs directly caused by
this bug as per comment 4 - but it seems to me that if we take the Advanced pref
panel (in whatever form it would end up) and put it directly into the current
main Tabbed Browsing section (with its 10+ prefs) it would alienate "regular"
users far more than a simple selection of two different browsing styles and an
Advanced button.

Comment 20

[Jonas Jørgensen]

Ctrl-click a link, middle-click a link, Ctrl-Enter in location bar, Ctrl-click
on a bookmark, target="_blank", target="foo", window.open(), etc, etc, etc open in:
( ) new tab ( ) new window.

One pref for opening tabs instead of windows is all we need. Merge 'em.

We do *not* need a pref for hiding all tab-related UI. Otherwise we'd also need
separate prefs for hiding all bookmarks-, history- and printing-related UI, just
to name a few.

Nor do we need a pref for deciding the order of the "Open in new tab"/"Open in
new window" context menu items, or the File|New|Navigator Window/Navigator Tab
menu items. They should stay where they currently are regardless of any pref
setting.

Comment 21

[Jason Bassford]

Jonas: What you're saying is fine if all of these other bugs are killed or do
not themselves get resolved with prefs.  I just don't see that happening. 
Somebody is always going to want more fine-grained control...

Comment 22

[Bamm Gabriana]

> Yay, more prefs!

Yup, but it will make things a lot more intuitive. Tabbed Mode, Windowed Mode
and Custom are much easier to grasp than each of the individual prefs.

> By these you mean Ctrl-click on the dropdown menu items?

I meant Ctrl+Back Button, but I can't find the bug. Maybe I should file a dupe
and wait till someone dupes it, for me to find out? hehehe...

> I see no way around this.

Since Netscape days, Ctrl+Click has traditionally meant "Open in New Window".
IE's equivalent is Shift+Click. I think saying "Ctrl+Click opens a new tab
instead of a window" should be straightforward enough.

Don't get me wrong, I like your fine degree of control. I just think the table
has grown too large. Looks too daunting.

I would use a checkbox if there are only 2 choices, and a radio button if there
are 3 or more.

Comment 23

[Jason Bassford]

> I just think the table has grown too large. Looks too daunting.
> I would use a checkbox if there are only 2 choices, and a radio
> button if there are 3 or more.

Okay, 3rd attempt.

Overall:

[ ] Disable tabbed browsing UI
[ ] Hide the tab bar when only one tab is open
[ ] Load links in the background

Open links in new tabs instead of new windows with:

[ ] Ctrl-click or middle click
[ ] Control+Enter in the Location bar
[ ] Ctrl-click a bookmark
[ ] Ctrl+Back Button (?)
[ ] Multiple links

Web Code                tab  window  current

External URL  opens in  ( )   ( )     ( )
JavaScript    opens in  ( )   ( )     ( )
HTML target   opens in  ( )   ( )     ( )         

Menus list new tabs ( ) first
                    ( ) last
                    ( ) not at all

Comment 24

[Jason Bassford]

Cleaning up. (Somebody tell me to stop posting these examples if this is
becoming SPAM-like.)

Overall:

[ ] Disable tabbed browsing UI
[ ] Hide the tab bar when only one tab is open
[ ] Load links in the background


Open links in new tabs instead of new windows with:

[ ] Ctrl-click or middle click
[ ] Control+Enter in the Location bar
[ ] Ctrl-click a bookmark
[ ] Ctrl+Back Button (?)
[ ] Multiple links


tab window current for:

( )   ( )   ( )   External URL
( )   ( )   ( )   JavaScript  
( )   ( )   ( )   HTML target


Menus list new tabs:

( ) first
( ) last
( ) not at all

Comment 25

[Bamm Gabriana]

Thanks, Jason. That looks a lot cleaner.

And you are right, this bug did not create those prefs. We are just creating a
central repository for prefs created by other bugs.

In other words, whenever a tab-related bug creates a new pref, it would
automatically be placed in the advanced prefs instead of being exposed to the user.

Basically, there are just three choices: Tab, Window and Custom.

It's simple, intuitive, and flexible.

Comment 26

[jag (Peter Annema)]

We're not going to add a pref to hide or disable tabbed browsing UI. We're not
going to add a pref to list "Open Link in New Tab" before "Open Link in New
Window". If/when we can support opening target="..." and JS window.open in tabs
instead of windows, it'll be one pref, and I think allowing those to open in
"current" (window or tab) would subtly break sites that use them. No,
ctrl+back-button is not going to open that page in a new window or tab.
"Ctrl+click on a bookmark" should use the "ctrl+click on a link" pref.

Comment 27

[Jason Bassford]

Updating suggested Advanced prefs panel based on comment 26:

Display

[ ] Hide the tab bar when only one tab is open
[ ] Load links in the background


Open links in new tabs instead of new windows with

[ ] Ctrl-click or middle click
[ ] Control+Enter in the Location bar
[ ] Multiple links


tab window current for

( )   ( )   ( )   External URL
( )   ( )   ( )   JavaScript / HTML target 

Comment 28

[Marcus Campbell]

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

Comment 29

[Jason Bassford]

Adding dependency - bug 158223: Regular left-click opens new tab.  (Not sure how
it would fit into the Advanced pref panel.  Maybe we should wait and see if it
gets attention or not first.)

Comment 30

[Jason Bassford]

Adding dependency - bug 164390: Regular left-click opens new tab.

It was previously incorrectly marked as a dupe of bug 158223 due to misleading
Summary text and description in that bug.

Comment 31

[Stefan Huszics]

> If/when we can support opening target="..." and JS window.open in tabs
instead of windows, it'll be one pref, and I think allowing those to open in
"current" (window or tab) would subtly break sites that use them.

A small comment on this.
IME HTML target="_blank" and (invalid) target="_new" is used almost always to
open up links to external sites.

Javascript new windows and target="foo" is however almost always related to the
current page and is highly likely to break sites.
Placing these 2 groups in the same pref to mee seems like an unwize choise.

BTW, user_pref("browser.block.target_new_window", true);
is an already nicely working pref with this distincion :)

Comment 32

[Worcester12345]

helpwanted keyword?

Comment 33

[Worcester12345]

Will this partially or entirely coincide with part of the new "options panel"
which is due out for Firefox 1.1? It might make sense to look at that
functionality together, no?

Comment 34

[Worcester12345]

see Bug 172962 comment 89 through comment 107, Comment 167 and Comment 168 
Comment 170, Comment 190  

Comment 35

[Peter Weilbacher]

Attachment: Add UI options to Tabbed Browsing panel, 1st try

Since bug 172962 took care of the backend, it is much simpler to implement the
UI for these options (browser.link.open_newwindow and
browser.link.open_external). I somewhat followed the idea from comment 27, but
I needed more space to make the words clear. If someone has a good suggestion
how to use fewer words but keep the meaning, please comment. Once the wording
in the UI is final I can also add two paragraphs for the help.

Comment 36

[Peter Weilbacher]

Attachment: Screenshot with the new options

Comment 37

[Peter Weilbacher]

Attachment: Help changes for UI tabbed browsing options

Comment 38

[Peter Weilbacher]

Comment on attachment 177985 [details] [diff] [review]
Add UI options to Tabbed Browsing panel, 1st try

Perhaps this catches your attention for a quick review when I remark that this
is for feature parity of the suite with Firefox... :-)

Comment 39

[[e-mail]]

Comment on attachment 177985 [details] [diff] [review]
Add UI options to Tabbed Browsing panel, 1st try

>+  <hbox>
Probably because my test machine uses different fonts the subtle difference in
size between the two groupboxes caused one to wrap. So I suggest setting
equalsize="always" on the hbox to fix the problem.

The other alternative would be a system like the one for the navigator page to
display preference.

Comment 40

[Peter Weilbacher]

(In reply to comment #39)
> The other alternative would be a system like the one for the navigator page to
> display preference.

That sounds like a good idea that I have to try. (That would even create enough
space to put additional controls for the browser.link.open_newwindow.restriction
preference, although I am not sure those should really appear in the UI...)

Comment 41

[jag (Peter Annema)]

If equalsize="always" works, I'd prefer that over copying the "nagivator page to
display" pref pane.

Comment 42

[Peter Weilbacher]

The equalsize trick seems to work on my OS/2 system, but I didn't yet verify on
a system where the panel is resizable. I played with Neil's suggestion a bit,
but the method used in the Navigator panel has two drawbacks:
- It is not entirely intuitive to use (are there any other programs that use a
drop-down like this?), there is no feedback of a change after a different item
in the drop-down gets selected. In the case here this wouldn't hurt, though,
because the text at the top of the boxes would change.
- It needs some JS in addition to XUL, and for some reason I cannot get it
working for this case. Probably just a stupid mistake on my part.

The advantages are
+ Create more space in panel
+ Ability to reuse access keys (and strings)

Hmm...

Comment 43

[Peter Weilbacher]

Attachment: 2nd XUL patch for Tabbed Browsing prefs panel

The same patch as before, but now with equalsize="always" (and me as
contributor). This works just as well when resizing the dialog as the other
groupboxes.
Carrying over neil's sr+.

Comment 44

[Ian Neal]

->MAS

Comment 45

[Ian Neal]

Peter, could you add accesskeys to the other prefs on this page whilst you are
at it?

Comment 46

[Peter Weilbacher]

Attachment: Corrected patch, with extra accesskeys

Here it is, I added the same accesskeys for all three platforms to be
consistent. I think I followed the rules, but please check.

Comment 47

[jag (Peter Annema)]

Comment on attachment 182047 [details] [diff] [review]
Corrected patch, with extra accesskeys

r=jag

Only change I'd make is to group the accesskeys with the label:

<!ENTITY openCurrent.label "The current tab/window">
<!ENTITY newWindowGroupCurrent.accesskey "c">
<!ENTITY externalGroupCurrent.accesskey "u">

etc., just like is done everywhere else. It'll make it easier to verify that
the access keys are in sync with the label they're used on.

Comment 48

[Peter Weilbacher]

Attachment: Same patch but rearranged accesskey with in the DTD (Checked in)

Carrying over reviews. This patch should be ready for checkin. As this is about
feature parity with Firefox, I guess this should go into Seamonkey 1.0.
Therefore asking for approval.

Comment 49

[Asa Dotzler [:asa]]

Comment on attachment 182416 [details] [diff] [review]
Same patch but rearranged accesskey with in the DTD (Checked in)

a=asa

Comment 50

[Ian Neal]

Comment on attachment 182416 [details] [diff] [review]
Same patch but rearranged accesskey with in the DTD (Checked in)

Pref patch checked in

Comment 51

[Ian Neal]

Comment on attachment 178303 [details] [diff] [review]
Help changes for UI tabbed browsing options

>Index: extensions/help/resources/locale/en-US/cs_nav_prefs_navigator.xhtml
>===================================================================
>+  <li><strong>Link open behavior</strong>: If a webpage is designed so that
>+    certain links open in a new window by default (either through the target
>+    attribute in HTML or through embedded JavaScript), the user may wish to
>+    override this:
>+    <ul>
>+      <li><strong>The current tab/window</strong>: Redirect the link so that it
>+        opens in the current tab of the active window.</li>
>+      <li><strong>A new tab in the current window</strong>: Open a new tab with
>+        the linked page instead of a new window.</li>
>+      <li><strong>A new window</strong>: Open a new window with the linked page.
>+        This is the default and does not override the webpage design.</li>
>+    </ul>
>+  </li>
The style in help is not to use "the user", so in the first section change "the
user" to "you".

You are not being consistent through the options - possibly alternative:
Open the linked page in the current tab of the active window.
Open the linked page in a new tab instead of a new window.
Open the linked page in a new window. (This is the default and does not
override the webpage design).

You could keep your first option but the other two are awkward the way you have
them.

>+  <li><strong>Links from other applications</strong>: If &brandShortName; is
>+    called from another application with a webpage address as an argument (like
>+    a click on a link in an external email program), where do you want the page
>+    to be loaded:
>+    <ul>
>+      <li><strong>The current tab/window</strong>: Open the link directly in
>+        the active tab of the browser window that was active last.</li>
>+      <li><strong>A new tab in the current window</strong>: Open a new tab with
>+        the linked page within the browser window that was active last.</li>
>+      <li><strong>A new window</strong>: Create a new browser window to open
>+        the linked page.</li>
>+    </ul>
>+  </li>
The description of the pref does not quite read correctly - perhaps the bit
after the brackets could read:
), you can control where the page will be loaded:

Same issue again with the options.

Help patches do not typically need an sr= just r= (and drivers a= at the
moment)

Comment 52

[Peter Weilbacher]

Attachment: New help patch addressing comments

Thanks for checkin and comments, Ian. Perhaps I should just have opened a
follow-up bug and let a native speaker do the work for the help in the first
place, but I think I was not too far off the target. :-)

For your alternative description of the options, do you mean to leave away the
<strong></strong> text? The order and description in the panel are probably
already good enough to associate the options with the help text, so I deleted
that.

Comment 53

[Ian Neal]

Comment on attachment 182862 [details] [diff] [review]
New help patch addressing comments

No I didn't mean for the <strong> to be removed, sorry for the confusion. Apart
from that looks fine.
r= with those changes.

Comment 54

[Peter Weilbacher]

Attachment: Corrected help patch with <strong> (Checked in)

OK, now the same including the <strong> sections I had removed. Carrying over
Ian's r+, asking for approval.

Comment 55

[Asa Dotzler [:asa]]

Comment on attachment 182954 [details] [diff] [review]
Corrected help patch with <strong> (Checked in)

a=asa

Comment 56

[Ian Neal]

Comment on attachment 182954 [details] [diff] [review]
Corrected help patch with <strong> (Checked in)

Checking in cs_nav_prefs_navigator.xhtml;
new revision: 1.29; previous revision: 1.28
done

Comment 57

[Giacomo Magnini]

It doesn't seem to fit under modern (cut panel at the end).

Comment 58

[Peter Weilbacher]

You mean the dialog is not large enough in height? Hmm, I tried Classic, Modern
and Skypilot and for all of them it fits. Do other long pages like Navigator ->
Downloads and M&N -> Composition fit?

Comment 59

[Jason Bassford]

I filed bug 293427 for this specific issue.

Comment 60

[Worcester12345]

Should this one be marked as "fixed" or what?

Comment 61

[Peter Weilbacher]

I would have marked it fixed but some of the dependencies are still open or
reopened. If it is still good practice to close this then please go ahead!

Comment 62

[Robert Kaiser]

If the specific problem(s) this bug describes is/are solved, the bug owner should mark it fixed. If there's still work to do in this specific bug (report), then leave it open and tell what's still to do.

Comment 63

[Peter Weilbacher]

OK then. :-)

Comment 64

[Worcester12345]

(In reply to comment #63)
> OK then. :-)
> 

Were you the original reporter of this? I was unvoting some fixed bugs, but not sure if you changed user name or something. Thanks.