19191 - [Mac] Text selection not per HIG (not selecting entire line)

Status: VERIFIED FIXED

(Core :: DOM: Selection, defect, P3)

Description

[Adam Masri]

Build ID: 1999111612 (M11)
MacOS 9 (please add to list of OSes)

System: PowerBook G3/300, 128Mb RAM, VM off.

Text selection is not following Apple's Human Interface Guidelines. Currently,
 it's working the way Windows &UNIX do. Easy way to see this: move mouse to end
of URL in location bar, hold mouse button down, drag up. Currently, a single
character (if any at all) is selected. This is incorrect; according to Apple
HIG, the entire line should have been selected, since (in theory) you were
"dragging up" to the line above the one you were at, or the beginning of the
line, whichever comes first.

Comment 1

[Eli Goldberg]

[cc'ing Simon. I think this issue was bothering him.]

Comment 2

[Adam Masri]

Please note that the opposite is also true: dragging from the beginning of the
line down should select all text to the end of the line; according to Apple HIG,
you are selecting to the next line down, or the end of the current line,
whichever comes first.

Comment 3

[Sean Richardson]

The location bar is s special case: the line in it is always both the first
and last line in its editng field. This is the subtle point: does the Apple
HIG get this right by common sense, or does it wimp out and not handle the
first-line and last-line special cases?

By common sense, I mean that the area where no line is possible is going to get
considered by most as a null line, not as an undefined area, so most people
will consider click-drag (or shift-arrowkey) down from the beginning of the
last line or up from the end of the first line something that should work as
well against the edit field boundaries as it does in the middle of a number
of lines.

The question is, do HIG-conforming apps on the Mac properly handle the
first- and last- line special cases? If so, this report is 100% valid.

If not, I'd warn against doing anything. I'd love to see this handled
sensibly on MS-Windows and X-Windows as well, but so long as Mozilla must
live within legacy platforms, fixing (in just one app) a broken behaviour that
tens or hundreds of millions of people have had to train themselves to work
around doesn't seem wise.

Quoting from [e-mail]:
>according to Apple HIG, you are selecting to the next line down,
>or the end of the current line, whichever comes first.
That language sounds like it's meant to handle the special cases.

Comment 4

[Adam Masri]

[e-mail],



"The question is, do HIG-conforming apps on the Mac properly handle the

first- and last- line special cases? If so, this report is 100% valid."



I think that what is "right" is entirely dependent on the platform you're using.

You can check any Macintosh application available, including Netscape

Communicator 4.7. If you click-drag in a text block (block or single line), you

can drag in any direction you want. All text towards the direction you're

dragging, as far as you've dragged, will be selected. If you drag outside the

bounds of a text area, the mouse remains the insertion cursor; it does not revert

to the arrow. IMHO, this is preferred behavior: it makes it easier to select

text. I can be "sloppy" in my selection, meaning that I do not have to precisely

drag across the text that exists. I can drag in the direction that makes sense,

and the Macintosh "does the right thing." It's also faster to hold the mouse

button down and drag up to select an entire line, whether the text is in a text

block or a single-line field.



A database application is a typical example. In every database application on the

Macintosh, you can click-drag in a single-line text field in any direction you

want, including outside the bounds of the text field rectangle. The rules I've

outlined above stand. Holding the mouse button at the beginning of the field and

dragging down selects the entire field. Holding the mouse button at the end of

the field and dragging up selects the entire field. Click-dragging from the

middle of the text in the field down selects from the insertion point to the end

of the field, and click-dragging from the middle of the text in the field up

selects from the insertion point to the beginning. It is easier, faster for the

user, and makes sense. This is the way things have been done since 1984, and I'd

know. I've been using Macs since then.



Perhaps most importantly, Macintosh HIG specifically states that once the user

has learned to do something in a particular way, you do not change the behavior

on them in a similar circumstance just because you don't like Macintosh HIG. If

every other program on the Macintosh handles text selection one way, and you

change it for Moz, Macintosh users will absolutely revolt.



Unfortunately, I cannot find a precise definition of this behavior in Apple HIG

manuals.



http://developer.apple.com/techpubs/mac/HIGuidelines/HIGuidelines-

217.html#HEADING217-0



If Mozilla engineering will not work on this issue until an official response is

registered, then I will attempt to get one. Please post if this is necessary.

However, I believe that you can run 100 different Mac applications, and you will

always see this exact same behavior... Except for maybe Microsoft applications.

They violate Apple HIG all over the place. :)



What's unfortunate is that you're assuming that current Moz behavior is correct

because it's what X & Windows use. I do not want to get into a "who's got the

better OS" argument, because I truly believe that different OSes are good for

different things. But I would say that Microsoft's poor copy of the MacOS, and

X's adoption of that poor copy's UI, should not penalize Macintosh users simply

because Apple did things right. (At least, right in my opinion, anyway.) Using

your logic, why doesn't the arrow look like MS Windows' arrow on all platforms?

Or, why does text selection not work the way "millions" of Mac users are used to?

Or, why can't all platforms minimize Moz's window the way you can on X? Some

violations of Apple HIG will be tolerated by the Macintosh audience in order to

yield a truly cross-platform application. But when violations have NOTHING to do

with the cross-platform nature of Moz, and are simply "dumbing down" the Mac

version in order to match the poor featureset of other OSes, then Macintosh users

will complain bitterly about Mozilla.



I believe that Moz can be a well behaved application on all platforms. On the

Macintosh, that means following Apple HIG, and doing things the way Mac users

expect. I would venture to guess that Mac users are far more adamant about their

UI respecting HIG than on any other platform. When you violate the rules, you get

rants written about you. Hence, all the users in the Mac Chat log on mozillazine

getting pissed off about Moz not following Apple HIG.



In writing this diatribe, I noticed that Mozilla is violating HIG in a few other

places as well. I will attempt to list links to specific portions of Apple's HIG

manual as I post bugs.



Please note, I'm not spending my time doing this because I want to be a thorn in

anybody's side. I'm doing this because I believe 100% in the Mozilla project. I

believe that if Moz offers a true cross-platform interface for web-based

applications, AND respects platform differences and UI standards when those

differences do not impact the cross-platform nature of Moz, then Moz will be a

pleasant application to use for everybody. Nobody will end up feeling that the

benefits of this cross-platform product are outweighed by the total disregard for

their platform's strengths. IMO, respect for platform differences is what lead to

Netscape's incredible adoption rate. Let's not make people hate Moz for something

as silly as this.



- Adam

Comment 5

[Adam Masri]

Before everybody flames me, I did NOT doubles-space that msg. Posting with
Communicator 4.7 did that; why, I have no idea.

Comment 6

[Eli Goldberg]

Yup. Bugzilla problem.

Noting that I don't speak for Netscape (and keep copies of the 1992 HIGs in my
cubicle at work, and in my bedroom at home ;), Mozilla is using an XML-based
cross-platform user interface with affordances for certain platform-specific
issues.

There will, inevitably, be compromises as a result of the architecture and
limited engineering resources.

Fortunately, this is open source, so enjoy being part of those decisions.  Moof.
;)

Comment 7

[Sean Richardson]

Ouch. I obviously didn't communicate well enough. What I was trying to say
is that I'd prefer it that MS-Windows and X-Windows work the same way that
the Mac does do for selecting text in the top, bottom, or only line of a
text field, but it's too late now to try to change that, *for those platforms*,
or, if-and-only-if Mac HIG-confirming apps didn't already work that way, for
the Mac either (it's been a while since I've been able to use a Mac regularly).

The real problem is that I added a paragraph that was just too complex,
only applying to the Mac if the HIG didn't read the way I expected it did
read (previous paragraph), causing confusion as I did so. Sorry about that.

[e-mail], based on your observation that the type of drag-selection you
are asking for works the same way in all Mac Apps other than MS apps, it does
look like you have found a valid problem, but a [Mac-Only] problem, not a [PP]
(platform parity) problem. The reason I wrote the paragraph beginning "The
question is," was because you could strengthen your case considerably by
confirming that other Mac apps work the way you want Mozilla to work for
single-line text fields - but without that confirmation, making such a deep UI
behaviour change would be hard to justify no matter how much better it could
be, due to the confusion caused by inconsistency with other apps. That same
reasoning is the strongest rationale for doing what you propose, given the
facts you cite.

As far as exemplars of drag-selection of top, bottom, or only lines the HIG
way goes, I'd look to text-entry fields that are part of the Mac Operating
System itself - i.e., most control panels, the chooser, etc - if they work the
way you describe, it would be hard to argue that the HIG meant otherwise.

Changing [PP] to [Mac] because this is an area where within-platform
consistency seems much more important than cross-platform parity;
plus, this never was a [PP]-wanted bug report - parity is what exists now!

Comment 8

[Adam Masri]

[e-mail],

Thanks for explaining, and sorry for the vitriol. I really love Netscape &
Communicator, I really believe that Mozilla will be a powerful cross-platform
development environment that goes far beyond Web pages, and I believe that we can
all "just get along" if Moz follows UI conventions on all platforms that do not
affect its cross-platform nature. As a Macintosh consultant, it is in my best
interest to see Moz follow Mac UI conventions, since I will be installing it on
my customers' Macs when it is released. Mac users tend to be less technically
inclined than Win & UNIX users, and UI differences are noticable and aggravating
to them. The first thing out of their mouth will be, "why doesn't this FEEL like
a Mac application?"  They don't care if Moz is available for 100 platforms, they
just want it to be a well behaved Mac app.

"[e-mail], based on your observation that the type of drag-selection you
are asking for works the same way in all Mac Apps other than MS apps, it does
look like you have found a valid problem, but a [Mac-Only] problem, not a [PP]
(platform parity) problem."

Please, call me Adam. ;)  Yes, you are correct, this is Mac-specific. I do not
expect the UI to change on UNIX or Win, because text selection works as expected
on those platforms now.

"As far as exemplars of drag-selection of top, bottom, or only lines the HIG
way goes, I'd look to text-entry fields that are part of the Mac Operating
System itself - i.e., most control panels, the chooser, etc - if they work the
way you describe, it would be hard to argue that the HIG meant otherwise."

Here's a quick top-6 examples of this behavior in MacOS and MacOS apps now. I'm
currently running MacOS 9, but many of these will be similar in MacOS going back
to System 1. For each of the below listed examples, try the selections I listed
in my (double-spaced) rant, and you will see that this is SOP on the Mac.

1) In the Finder, select the name of a file/folder to rename it.
2) Use the Find command in the Finder; whether you're running Sherlock or the
older Find system, try typing and selecting text in the single-line text box.
3) In AppleCD Player, stick a CD in, open the disclosure triangle, and try
editing the CD name fields.
4) In Key Caps (in Apple menu), try typing text and editing in the single-line
text field.
5) In Netscape Communicator, try editing the site field, or go to Find and try
editing text in the Find single-line text field. Bookmark name/URL editing too.
6) In MacOS 9 go to Edit menu, Preferences, Labels. Try editing text in the
single-line label fields. (In older revs of the MacOS, this should be in Control
Panels, Labels or General control panel I think.)

I think that's enough. All of these will allow you to select text as I've stated.
This is standard on the Mac.

- Adam

Comment 9

[mjudge]

umm i think i have fixed this.  I have added a preference called...
browser.drag_out_of_frame_style to the users preferences and this will have the
effect of dragging to end or beginning of block if you pass the frames
dimensional limits.

(i see alot of statements here in the bug coments i dont understand. if there is
something i missed in what people wanted please let me know.)

the default is the OLD way since this is the way for X and Win32. you need to
add the pref statement of "browser.drag_out_of_frame_styl",1 please give it a go
and let me know. (this is of tonights build, please make sure you get the build
with 11-22 changes in it)
MJ

Comment 10

[Eli Goldberg]

Hmm...I believe masri's request is that it should be the default behavior on Mac
OS Mozilla; e.g. users probably won't expect to have to manually set a hidden
preference to make this aspect of the product behave how they'd expect it to.

Comment 11

[Adam Masri]

elig is correct. This should be default behavior on MacOS, because this is what
Mac users would expect. Please do not make this a hidden text file modification;
this behavior should be automatic. Users should have to modify the file if they
want non-conformant (Win & Mac GUI) behavior.

Comment 12

[Adam Masri]

That was supposed to be "Win & UNIX" behavior, obviously.

Comment 13

[Eli Goldberg]

Re-opening, per consensus that this should be the behavior by default on Mac OS;
users will not know to flip a hidden switch to receive the behavior they'll be
expecting as default.

Comment 14

[Kathleen :Brade]

reassign to myself to fix mac default prefs

Comment 15

[mjudge]

kathy want to do this herself. gooo kathy

Comment 16

[mjudge]

m13 one line fix that will please alot of people.

Comment 17

[Kathleen :Brade]

This is fixed but it may not appear fixed until bug #24232 is fixed.

Comment 18

[Kathleen :Brade]

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

Comment 19

[Eli Goldberg]

Adam, might you possibly wish to verify this one? You'd do the best job, so it 
would be much appreciated.

Otherwise, I'll give it a whirl. Thanks!

Comment 20

[Adam Masri]

This appears to be fixed. However, it has spawned a new one, bug 25385.

I think we can close this one now.

- Adam

Comment 21

[Eli Goldberg]

Adam, you do your cousin's last name justice. ;) Thanks again.

Rubber-stamping verified based on Adam's comments.

Comment 22

[Uri Bernstein]

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

Comment 23

[Pulsebot]

Pushed by ffxbld-merge:
https://hg.mozilla.org/releases/mozilla-beta/rev/86db4d95f34c
[fenix] For https://github.com/mozilla-mobile/fenix/issues/19191 - Fixes missing multi-select checkmarks