106398 - Tabbed Browsing Preference Pane uses lots of Windows centric terminology

Status: VERIFIED FIXED

(SeaMonkey :: Tabbed Browser, defect)

Description

[Andrew Thompson]

"Middle click or control-click the links in a web page"

-> On Mac OS its actually command click. Don't have a multi button mouse that
does middle click to test that out.

"Middle click or control click of bookmarks ... " 

Same ...

"Control + Enter in the URL bar"

This key is labelled "Return" on Mac OS, in fact, its also Command and its refer
ed to as the "Location Bar" elsewhere in the app. '+' doesn't look too
professional either. 

eg, on Mac OS this should be:

"Command and Return in the Location Bar" 

The whole dialog is clunky - using a sentence in the group box title and hoping
that runs on into the Checkbox items. UGH.

What is 


"Open tabs instead of windows for control + enter in the URL bar" supposed to
mean to an average person?

Something like:

Use a new tab instead of a new window when opening links:

[] When control (mac: command) clicking or middle clicking a link in a web page

[] When a web page tries to open a new window

etc

Not perfect but better.

Comment 1

[David Hyatt]

Hahah, you know this is a prototype, right?  I never planned for any of the
wording to stay the same. :)

Comment 2

[Andrew Thompson]

I kinda knew that. But you know how many prototypes get shipped? 

I guess I'm just a little too used to seeing Windows stuff creeping into Mozilla 
from people who don't know any better (I had no idea who put the prefs dialog 
together). Nothing personal :)

Comment 3

[Peter Trudelle]

This is one of the many reasons why we need a spec.

Comment 4

[David Hyatt]

Suggest some alternate wording.  I'm ready to fix this.

Comment 5

[Andrew Thompson]

Thinking about it, I think mpt may be right. Something line:

By default open documents in new:

(*) Windows
( ) Tabs

To temporarily change this setting, hold down the option (control?) key while 
opening the document.

I would say "alt" for Windows, but isn't there some reason we can't use that?

Does this conflict with any existing keybindings? I will give suggestions for 
changing the wording if you wish, but I'd rather just simplify the UI if 
possible.

Comment 6

[timeless]

alt-enter is generally owned by properties. so yes alt really shouldn't be
considered here.

Comment 7

[Andrew Thompson]

Does that apply in any of the contexts being discusses here? alt-click link 
doesn't seem to do anything, nor does alt-click on the Personal Toolbar or in the 
Addressbar at present, as far as I can tell. (but I'm presently trying it on Mac 
OS, so please correct for Windows if needbe)

I'm not sure the cases where "alt-enter" means "show properties" overlap with the 
link opening stuff?

Comment 8

[Troy Telford]

I simply am trying to better explain why the differences do and /should/ exist
between Mac & Windows & UNIX &...  That is, of course, until Apple, Microsoft,
Sun, the Open Group, the FSF, and every other OS/environment designer decides to
scrap all current keyboard conventions, and actually agree on a single keyboard
layout and function set.  (I doubt anybody alive will live to see that happen...)

Using the <Alt>+<Enter> combination, rather than the <CTRL>+<Enter> combination,
as well as the <Alt>+Click vs. <Ctrl>+Click goes against one of either the
'standard' conventions used in Windows, or Windows UI design rules.

As I recall, Apple has similar (although different) rules for Macintosh Apps. 

For a Windows app, you simply don't break the Windows rules and/or conventions
just to satisfy the users of a non-Windows OS.  Just like the final version of
any Mac app shouldn't break the Macintosh rules just to satisfy a non-Mac OS, etc.

In all OSes, you satisfy the needs and conventions of the OS you are writing for.

Keyboards also have different physical layouts, as well as different purposes
for modifier keys.  You don't change them around to satisfy the purpose for a
different OS.  (A personal sore point is the difference between the physical
locations of the <Caps Lock> and the <Ctrl> key between a 'standard' UNIX, and a
Win32 keyboard.)

This is simply because the 'standard' for the key layouts are different, and
changing them will therefore confuse the average user, who typically only uses
one OS  (and, most of the average users are Windows users, like it or not.)  It
just doesn't make sense to make Windows users use or limit themselves to a
convention used by Macintosh or UNIX.  The reverse situation applies as well. 
Cross-Platform software, such as Mozilla, simply /can't/ use the same key
layouts for everything, because the UI design rules and keyboard layouts
conflict.  (As well as the number of Mouse Buttons.  eg.  I find having only one
mouse button terribly limiting, but that's my opinion, and is only as valid as
the next person's opinion.)

This is, after all, a /testing/ version of Mozilla.  As most of Mozilla is
eventually rolled into Netscape, as well as most of the Mozilla developers I
know of are employed by Netscape, it makes sense to focus on the OS which is
used the most-- which is Windows by a huge margin.  It also makes sense that the
builds of Mozilla -- which are all beta/testing versions, will have some issues
with operating systems other than Windows.

In this case the original prototype does use a Windows convention.  The error
has been reported, and noted.  So has a solution useful for MacOS.  

For those more accustomed to working with a standard Win32 keyboard,
<CTRL>+<Enter> *is* the logical choice.  Alt is nearly always grouped with a
different set of tasks than Ctrl.  The Ctrl key on Mac and the Windows Ctrl key
have different meanings/task sets from each other as well.  

As is already mentioned, <Alt>+<Enter> opens up the properties list for whatever
object you're working on/with.  The proper (although unimplemented) thing to do
when pressing <Alt>+<Enter> would be to open the properties of the webpage in
question.  (Using various W3C HTML tags such as the author tag, etc., as well as
showing the actual size of the HTML document, and other types of information
about the web page itself.)  <Alt>+<Enter> is also used often to change between
"Full-Screen" and "Windowed" DOS/Command Prompts.  (This also holds true for
WinXP).  For the Win32 version, and for Windows users, you just don't break the
Windows UI design rule to satisfy Mac users.  This is for the same reason you
don't just break an app design rule on a Mac to satisfy Windows users:  It
confuses the users of the corresponding OS.  Neither rule set is superior to the
other... both serve to help users.  But they are different, and it /is/
important to use the particular OSes rules.

In Windows, <Ctrl>+<Enter> is grouped as a 'companion' of the <Enter> key, doing
a slightly different task then enter alone.  eg. <Ctrl>+<Enter> inserts a hard
page break in Win32 Word Processors; essentially the same as hitting enter
alone, but with the additional (and slightly different task) of starting a new
line on a new page, rather than simply a new line.  There are other similar
uses.  And if you *really* want to do your homework, look at what <Ctrl>+<Enter>
was used for before the Windows UI rules came out!

Also, the problem  of <Ctrl>+click/middle-click on toolbar and bookmarks
(Although <Alt>+click is what is mentioned-- I thought Option-Click would be
what Mac users would use; but then again my Mac is a bit rusty) has most likely
not yet been implemented.  (Mozilla is still in its testing stage, after all,
and other bugreports for tabbed-pages speak of unimplemented features)

Comment 9

[timeless]

fwiw alt-double click in explorer (non web mode) opens properties, i think we 
have this binding in bookmarks (win). In webmode, i'd expect alt-single click 
to do this, but i'm not sure and webview is disabled so i can't easily check 
:).

Comment 10

[timeless]

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

Comment 11

[timeless]

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

Comment 12

[sairuh (rarely reading bugmail)]

nominating --no longer a prototype :)

jatin/mpt, have any phrasing suggestions here?

Comment 13

[Andrew Thompson]

Phew... wasn't getting emails on this bug for some reason.
That's a very balanced argument Troy, and I agree with what you said. Therefore 
I'm floating this:

By default open documents in new:

(*) Windows
( ) Tabs

Hold (mac: option) (windows: ctrl) (linux: ???) to temporarily reverse this 
setting.

In other words, lets use the right key on each platform. Does anyone really think 
we need a UI as complex as the current one? The option to override on a per click 
basis should satisfy power users.

The only question is whether Ctrl-click conflicts with any other shortcuts on 
Windows (or if option click conflicts on Mac OS, Linux etc). If so, the simplest 
solution is to add Shift to the mix.

AFAIK Shift-Ctrl/Shift-Option is a valid modifier pair on Mac/Win/Linux (well, 
one can always conflict with the Window Manager on Unix, but that's hard to 
avoid, so unless KDE/GNOME reserve this by default?)

Comment 14

[David Hyatt]

Reassigning to new component owner.

Comment 15

[jag (Peter Annema)]

I think this should be fixed for 1.0.

Comment 16

[Peter Trudelle]

nsbeta1- per ADT triage team, ->1.2

Comment 17

[sairuh (rarely reading bugmail)]

why was this minused? because the info in this pane is win32-centric, it'll be
both misleading [as well as incorrect] on Mac.

feel free to discuss with me offline if i'm misunderstanding things here.

Comment 18

[Peter Trudelle]

nsbeta1+ per ADT triage team to change pref wording (e.g. 'control' to
'command')  on Mac to match actual keys used.

Comment 19

[Blake Ross]

I have a fix for this. -> me

Comment 20

[Blake Ross]

Attachment: patch to fix wording of pref on mac

Comment 21

[Joe Hewitt (gone)]

Comment on attachment 76432 [details] [diff] [review]
patch to fix wording of pref on mac

Let me go on record as saying I'd rather created a platform dtd for all of
prefs than do it this way.  Even if it is only one string, it's a good policy,
and perhaps someday that dtd will grow.

Anyway, it's only one string so I'll give in.  

sr=hewitt

Comment 22

[jag (Peter Annema)]

Comment on attachment 76432 [details] [diff] [review]
patch to fix wording of pref on mac

r=jag

Comment 23

[Blake Ross]

This went in with the landing.

Comment 24

[sairuh (rarely reading bugmail)]

tested using 2002.04.09.08 comm bits on mac 10.1.3.

(a) "Middle-click or control-click of links in a Web page." --this is icorrect.
it should be "Middle-click or Command-click of links in a Web page."
                           ^
                           |
                           Command is the correct modifier. Control brings up the
                                  context menu.

(b) "Command+Enter in the Location bar" is fine, however.

Comment 25

[Brice Ruth]

Note: what is 'middle-click' in OS 9/X? I have a macally 3-button mouse (2
button+scroll wheel) and pushing on the scroll wheel (to middle click) does
absolutely nothing in any application. Only left/right buttons + scrolling work ...

Just a thought :)

Oh - running OS X v10.1.3

Comment 26

[Andrew Thompson]

I have a 5 button mouse and can persuade all 5 to do things, albeit only fairly 
inconsistently, so I don't think we should discount "middle click". 

As for the "Command + Enter" thing:

are you *sure*? "Enter" is the key on the numeric keypad, if you don't mean this 
one you should say "Return".

Comment 27

[Peter Trudelle]

ADT3

Comment 28

[sairuh (rarely reading bugmail)]

suggestions for rephrasing:

"Command-click of links in a Web page"
"Command+Return in the Location bar"

jatin, sound okay?

Comment 29

[Jatin Billimoria]

Corrections to Sarah's suggestions:

"Command+click of links in a web page"
"Command+Return in the Location bar"

I don't know enough about the middle-mouse button on Mac to say whether or not
we should have it included in the wording.

I've used "web page" instead of "Web page," since "web page" is a generic term
and requires no capitalization.

Comment 30

[Brice Ruth]

In both Mac OS 9 as well as Mac OS X (especially in the latter) their appears to
be a concept of a "main" mouse button (the only mouse button for the standard
Apple mice) and a second mouse button (or ctrl-"main"-click). On all 2-button
mice I've encountered, the right mouse button is this second mouse button. So,
for all intents & purposes, you can say that Mac OS is aware of 2 buttons, not
three, so no middle click is relevant. Now, some have noted that mice with many
more than three buttons are available for Macs and each button can be made to do
something different. Very, very true. However, this isn't "standard" behaviour.
My simple point is: on my Mac, with a relatively standard Mac mouse with 2
buttons + scroll wheel which can be clicked (acting as the middle button),
clicking the scroll wheel does nothing (and in my case, cannot be configured to
do anything) in any standard Mac OS application.

Now, in XDarwin (Mac OS X's XFree86 server), I've found that I *can* in fact use
my middle mouse button as would be typical in the UNIX world (copy/paste in
xterm, etc.) However, Mac OS 9 and OS X's Aqua/Quartz interface do not appear to
have any use for the middle button, that I have come across yet.

To be *most* safe, I would stick to verbage that only uses the ONE main mouse
button that ALL Mac OS users are guaranteed to have. That way, if it says
"ctrl-click" and I (as many users) know that "right-click" is equivalent to
"ctrl-click" on a Mac, I can commence using my mouse's right button instead of
ctrl-click. Same for "cmd-click" - if I happen to have my middle button
(somehow) mapped to "cmd-click" - (a) I'll know I do and (b) I can commence
using my middle button instead of "cmd-click".

Does this all make ANY sense?

Comment 31

[Andrew Thompson]

Yes, it makes sense... but as MacOS uses USB, infact the OS can distinguish many 
mouse buttons. The driver I have for my mouse will let me set up to 5 buttons, 
all of which are real distinct buttons.

However, outside of Maya there's really nothing much that uses a middle button, 
and certainly not much that can usefully use buttons 4 or 5.

Apple have only ever shipped one button mice, so their habit is to refer to 
clicking with "the mouse button" or "holding control and clicking". As this is 
the configuration of the majority of Macs out there, that's pretty much the 
terminology we should stick too, I think.

The only slight wrinkle would be that Netscape, being an application that has 
always run on Unix supports 3 buttons. Going back to 4.X the middle mouse button 
was emulated by holding command and clicking. This is still true in Mozilla (try 
it on a link command+click does "open in new window").

As multiple physical buttons is not the situation most Mac users find themselves 
in, I'd think we'd want to stick to 'click', 'control-click' and 'command-click' 
- those are the only terms that will work with Macs as shipped.

That's not to say the code can't support the "real physical" right and middle 
(and 4 and 5) buttons - but that's not what this bug is about. Power users will 
configure things to their liking in any case.

Comment 32

[Peter Trudelle]

Mass moving nsbeta1+/adt3 bugs assigned to Navigator team engineers out to
target milestone 1.0.1.  Please confine your attentions to driving down our list
of TM 1.0 bugs for beta.  Better to help, debug, or test one of them than fix
one of these.

Comment 33

[Christopher Aillon (sabbatical, not receiving bugmail)]

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

Comment 34

[scottputterman]

Changing nsbeta1+ [adt3] bugs to nsbeta1- on behalf of the adt.  If you have any
questions about this, please email [e-mail].  You can search for
"changing adt3 bugs" to quickly find and delete these bug mails.

Comment 35

[scottputterman]

Changing nsbeta1+ [adt3] bugs to nsbeta1- on behalf of the adt.  If you have any
questions about this, please email [e-mail].  You can search for
"changing adt3 bugs" to quickly find and delete these bug mails.

Comment 36

[mental]

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

Comment 37

[timeless]

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

Comment 38

[R.K.Aa.]

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

Comment 39

[sairuh (rarely reading bugmail)]

renominating...

Comment 40

[Samir Gehani]

Nav triage team: nsbeta1+/adt3

Comment 41

[Jo Hermans]

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

Comment 42

[Jo Hermans]

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

Comment 43

[Andy Lyttle]

FYI:  Middle click not working on Mac OS X is bug 151249, it's supposed to work
but it's broken at the moment, so the wording in preferences should stay.

No wonder this bug has eight dupes, with a summary like that. ;-)

Comment 44

[jag (Peter Annema)]

See bug 176095

Comment 45

[sairuh (rarely reading bugmail)]

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

Comment 46

[Aaron Leventhal]

Taking, to finish it up

Comment 47

[Aaron Leventhal]

Attachment: Fixes wording

For all platforms, this mentions control+Enter or command+Return, which was
ignored before.

For mac, this removes the mention of middle click and changes the Control+Enter
to Command+return.

Comment 48

[Aaron Leventhal]

Comment on attachment 109264 [details] [diff] [review]
Fixes wording

Oops, need to change 1 thing

Comment 49

[Aaron Leventhal]

Attachment: Correct patch

For all platforms, this mentions control+Enter or command+Return, which was
ignored before.

For mac, this removes the mention of middle click and changes the Control+Enter

to Command+return.

Comment 50

[sairuh (rarely reading bugmail)]

afaict, the wording in the patch looks fine, except for a minor thing in
mac/platformPrefOverlay.dtd --you should prolly be consistent in your use of "-"
vs "+" in the panel. that is, use the same symbol throughout the panel.

so, i would change

+<!ENTITY urlbar.label "Command+Return in the Location bar">

to this:

+<!ENTITY urlbar.label "Command-Return in the Location bar">

mainly since you appear to be using "-" for the other things (and for the other
platforms). what d'you think?

Comment 51

[Aaron Leventhal]

Okay, fixed -- do I need to submit a new patch?

Comment 52

[John Gaunt (redfive)]

Comment on attachment 109265 [details] [diff] [review]
Correct patch

r=jgaunt, looks good, with the comment above about consistency in +/-.
Personally I'd say change them to '+', but go with whatever as long as they are
consistent.

Comment 53

[Aaron Leventhal]

They're all changed to + except middle-click

Comment 54

[Simon Fraser [no longer active]]

Comment on attachment 109265 [details] [diff] [review]
Correct patch

I think you should use uppercase for "Command" and "Control" everywhere
(Command-Return, Control-click etc.).

Comment 55

[sairuh (rarely reading bugmail)]

i agree with what simon mentions in comment 54 --thanks for catching that!

Comment 56

[Aaron Leventhal]

Checked in with caps for Command and Control.

I definitely agree too -- originally I was just following what was there.

Comment 57

[sairuh (rarely reading bugmail)]

excellent. vrfy'd fixed with 2003.01.28.03 mach-o bits.