36848 - Should only be one text selection per window

Status: NEW

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

Description

[Blake Ross]

Build ID: 2000042208

This must be isolated on machine for one reason or another (despite a complete 
reinstall) since no one else has reported this yet, but...

Highlighting something and then highlight something else will cause the 
selection color of the first highlight to turn gray, but still highlighted.  
This occurs in any place where you're highlighting two things that aren't part 
of the same widget/component (i.e., if you highlight something in a site and 
then highlight other text in a site, the first highlight disappears as it 
should).

This is very strange, but I'm able to reproduce every time.  To try reproducing 
it yourself, highlight something in the browser content area and then highlight 
the URL in the location bar.  For me, this turns the initial selection in the 
browser content area gray, and highlights the URL in blue as it should.

Also, if something is highlighted and then the window loses focus, the 
selection color turns gray (i.e. if you have something selected in a site and 
then you click within a tab in the sidebar, the selection turns gray).

Is this just a problem with my comp's global.css or can anyone else with win98 
verify/repro this?

Comment 1

[Blake Ross]

Attachment: screenshot of problem

Comment 2

[Sean Richardson]

Reproduced on WinNT exactly as reported with the 2000-04-22-08-M16 nightly
binary; 100% reproducible over several Mozilla sessions.

Comment 3

[Blake Ross]

Hmm...I wonder what's causing this?  I didn't see any checkins that might have 
had any effect here.  In any case, ignore my original comment about this 
possibly being a problem with my global.css - I didn't realize that selection 
color wasn't handled by it.  I just assumed it was related to global.css since 
I'd been fooling around with it for about an hour before I discovered the bug.

Comment 4

[Blake Ross]

Perhaps this a pp?  Can anyone with linux/mac repro this?  

I'd assume there's an easy fix for this, but if not, I'd recommend nominating 
for beta2.

Comment 5

[Eli Goldberg]

I believe this is a feature, actually. ;)

Comment 6

[Chris Siebenmann]

 I can reproduce this under Linux; under Linux, it also happens if
you select text and then change the (X) mouse & keyboard focus to
another window. When you return the focus to the Mozilla window,
the text goes black again.

 I'm not certain if this is a bug or a feature, since I'm not sure
what the intended point of turning the selected text grey is. (The
selection remains as active or inactive in X as it was, whether or
not Mozilla holds mouse/keyboard focus at the moment.)

Comment 7

[Chris Siebenmann]

 I can reproduce this under Linux; under Linux, it also happens if
you select text and then change the (X) mouse & keyboard focus to
another window. When you return the focus to the Mozilla window,
the text goes black again.

 I'm not certain if this is a bug or a feature, since I'm not sure
what the intended point of turning the selected text grey is. (The
selection remains as active or inactive in X as it was, whether or
not Mozilla holds mouse/keyboard focus at the moment.)

Comment 8

[Blake Ross]

This is a feature?  How so?  What's the advantage of having text without focus 
be selected gray?

If it *is* intended as a feature, I have quite a few bugs to report regarding 
it...

Comment 9

[Eli Goldberg]

mjudge? ;)

Comment 10

[Eli Goldberg]

CC'd German & Matthew Thomas, in case they have anything to add on the usability 
side. 

Comment 11

[Matthew T (active 1999-2002)]

I seem to recall reading somewhere that this is mjudge's idea of a feature -- 
multiple selections in the same window. If you use Tab to get back to the 
original frame (e.g. from the location bar back to the page), your original 
selection is highlighted properly again.

However, this is misguided. To allow multiple unrelated selections in a single 
window is highly confusing to all but the most expert users. And if you think 
that removing this feature would be penalizing expert users, recall that for Unix 
users in bog-standard X (without GNOME or KDE) you don't have more than one 
selection at any one time in the entire *screen*, let alone one in each window.

So, to recap: You should only have one selection per window. The selection in the 
current window should be highlighted with the CSS2 UI selection color; the 
selections in windows other than the current window should be shown with a border 
around the selection in the CSS2 selection color -- if they are indeed shown at 
all.

Comment 12

[Matthew T (active 1999-2002)]

Ah there we are, found it. From bug 28999:
|
| ------- Additional Comments From [e-mail] 2000-04-03 14:29 -------
|
| hmm 4.x allowed the url bar to be selected and the content area to also be
| selected. Depending on focus I will change the color but not get rid of the
| selected text i dont think.
|
| ------- Additional Comments From [e-mail] 2000-04-07 17:31 -------
|
| hard part is done. only thing left now is the setting selection color to be
| different on lost focus. m16 i think
|
| ------- Additional Comments From Matthew Thomas 2000-04-07 17:56 -------
|
| Which version of 4.x allowed you to simultaneously select URL text and content
| text? (It wasn't the Mac version ...) That sounds like a bug to me.

Resummarizing, since this is now known to be a `feature' rather than just a color 
issue.

Comment 13

[sujay]

still a problem...

Comment 14

[leger]

Adding sujay to QA Contact.

Comment 15

[sujay]

marking nsbeta2...

Comment 16

[sujay]

marking this nsbeta2 because its very easy to reproduce
and is annoying when using the context menu....would like to see it
fixed for beta2

Comment 17

[Blake Ross]

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

Comment 18

[rubydoo123]

assigning this to anthonyd -- Anthony -- can you track this one please?

Comment 19

[leger]

Putting on [nsbeta2-] radar.  

Comment 20

[Blake Ross]

Can we get some info about this, please?  In bug 40433, brade and saari both 
seem to agree that this is working as intended and (as eli says a couple 
comments up in this bug) is a feature.  If this is, indeed, a feature then 
there's quite a couple bugs that have to be filed about it.  

First, I don't think highlighting in two separate frames should be considered 
highlighting in two separate areas, since it's hard to even tell that some 
pages even have frames if they're borderless and they have no scrollbar.  This 
would be quite confusing to the user - in other words, selecting text in one 
frame and then selecting text in another should probably clear the older text 
selection, rather than making it gray.

Second, if this is going to stay, there should probably be an easier way 
to "set focus" back to gray highlighted text.  Right now, if you select text in 
the URL bar, then in the content area, there's really no way to again get the 
text in the URL bar blue again - thus, there appears to be no way to copy it 
until you clear the selection and redo it, making this whole "feature" 
useless.  Same goes for the content area - highlighting text in the content 
area and then in the URL bar, makes it pretty hard to get the selected text in 
the content area "focused" (blue) again.  You _can_ mousedown on a link and 
then drag it into dead mozilla space, but this is pretty silly.  If this 
feature is to stay, perhaps clicking on the scrollbar should appear to restore 
focus to the whole content area (which should appear to be a different entity 
altogether), which would also refocus existing selections.

I guess there should be a way to select text in the URL bar and the content 
area (as IE lets you do), but there needs to be an easier way to "set focus" 
back to each. 

Comment 21

[Blake Ross]

hmm..n/m 'bout part of my last comment, clicking on scrollbars *does* seem to 
restore focus to the highlights in the content area

Comment 22

[anthonyd]

I might be getting this bug confused with 40433, but it was marked as a dup of 
this one.  So is this bug report for the greyed out text selection (or ghosted 
selection) OR is it for the multiple selections on windows with frames?  My 
following comments are based on if this bug report is for the former:

From my testing, this behavior with the ghosted selections (which is a feature) 
is the same behavior exhibted in IE and in Communcator 4.X.  The ONLY difference 
I can see is the 'lost focus' selection is greyed (or ghosted) instead of 
remaining the current selection color.  I personally think is a good thing 
because it allows users to follow which selection is current and in focus more 
intuitivly.

If someone can tell me certain areas that should not ghost the selection (for 
example, I believe I took the ghosted selection OUT of input fields) then please 
tell me.  

As for the frames issue Blake has raised, I will need to look into that, and I 
do agree with Blake that with a borderless and scroll-less frames page could be 
confusing.  But even if we take out the ghosted selection in this one case Blake 
mentioned, REGULAR slection will still remain, and you will STILL be able to 
select content in BOTH frames, in any case that should be a seperate bug.  This 
bug is only for the ghosted selection, am I right?

Anthony

Comment 23

[Blake Ross]

Hi Anthony:

Sorry 'bout raising that frames issue in this report; that was raised based on 
the assumption that multiple selections per window wasn't deliberate (in which 
case, this bug would cover the removal of these multiple selections).  Since 
you've confirmed now that there are, in fact, supposed to be multiple 
selections per window, I'll probably end up splitting the frames issue into a 
separate bug.

Since we'll be supporting multiple selections per window, I do agree 
that "unfocused" highlights should be gray. That's what this bug was originally 
about, but it got morphed into "Should only be one selection per window" 
somewhere down the line.  In either case, it looks like both "bugs" are really 
what's intended.  Sounds to me like we should close this bug up as a wontfix - 
what do you think?

Aside from splitting off the frames issue, I'll likely also split off an issue 
regarding context menus and unfocused selections.  Specifically, right clicking 
on unfocused selections (i.e. in the content area) should "refocus" the 
selection (i.e. revert it back to default selection color), and the clipboard 
functionality on the context menu should then be related to that selection.  
That's how it is in IE 5.x, but not in the latest nightlies.  

My vote is to close this one up as WONTFIX and I'll split off a couple of 
related bugs.

Comment 24

[anthonyd]

you da man Blake. I agree, if no one has any further issues with ghosted 
selection, then lets mark this as WONTFIX or something.  I think we should open 
a new bug for the multiple selections in a framed window, if at least to discuss 
it.

Anthony

Comment 25

[Blake Ross]

k.  I've split off related bugs 40797 (frames issue) and 40796 (context menu 
issue), both of which I mentioned earlier.

finally (!) closing this one up as wontfix, unless anyone has objections :)

Comment 26

[Matthew T (active 1999-2002)]

WONTFIX it might be, but my bet is that this bug will keep collecting duplicates 
until it gets fixed. I've tried and tried, but I can't think of any situation 
where allowing multiple simultaneous text selections in the same window would be 
useful. So the usefulness/confusion ratio is really far too low for this to be 
anything but a bug.

Comment 27

[Blake Ross]

german, you've been quiet - any thoughts?

Comment 28

[sujay]

verified in 5/30 build.

Comment 29

[Eli Goldberg]

This is likely to remain an active issue; QA Assigning back to self.

Comment 30

[Blake Ross]

I'm going to reopen this for more discussion.  I keep getting caught in cases 
where I'm actively highlighting something, but it's still appearing 
`inactive'.  I've filed bugs for all of these cases (of which there are many), 
but are they are [understandably] low priority, I don't expect them to be fixed 
any time soon.

I think that, as Matthew said, the usefulness/confusion ratio is far too low to 
have multiple selections like this.  It was interesting to try, and I 
appreciate its implementation, but it's a radical and unstandard change to a 
basic, familiar action whose behavior should be completely predictable for the 
user.

Comment 31

[anthonyd]

this is an event problem, not a selection problem.  For some reason, blur events 
are getting triggered sometimes, I dont know why.  Should prbably belong to 
saari, though I will help him.

anthonyd

ps. changing summary to reflect actual problem.

Comment 32

[anthonyd]

this really needs to go to saari, i will be glad to work with him, or whatever.  
if he wants to retire this bug, his call. :-)

anthonyd

Comment 33

[Blake Ross]

I actually reopened this for the former summary -- should only be one selection 
per window.

Comment 34

[saari (gone)]

Targeting mozilla 0.9 since it is a usability issue

Comment 35

[Jesse Ruderman]

I like the way non-active tree selections turn gray in Mozilla MailNews and in 
Outlook Express.  I hope we keep that color change.  (I'm not sure if that's a 
selection in the same way that selected text on a page is a selection, but the 
colors are the same...)

Comment 36

[Jesse Ruderman]

Btw, fixing this bug might lead to a performance gain: unfocused textboxes 
wouldn't need to remember what part of the text is selected.  (Making them not 
remember what's selected would also take care of the problem where invisible 
selections within unfocused textboxes can be dragged, when you expect dragging 
to create a new selection.) 

Comment 37

[Matthew T (active 1999-2002)]

Ok, clarifying summary. This doesn't cover tree selection, just text selection. 
For trees, having an inactive selection is fine (albeit that it shouldn't be gray 
on Mac OS -- it should be a 1px outline of the selection color).

> unfocused textboxes wouldn't need to remember what part of the text is
> selected.

They shouldn't anyway. Tabbing to a textbox should select all its content (bug 
28583), and clicking in it should collapse any existing selection. So there is no 
point in remembering the existing selection.

Comment 38

[Jesse Ruderman]

See also bug 73373, "Multiple Selection of Text with CTRL".

Comment 39

[Jesse Ruderman]

See also bug 56472, focus not clearing highlighted text.

Comment 40

[saari (gone)]

I don't think I'm going to fix this anytime soon and I think it got wrapped up
with other focus bugs and topembed keyworded that way (based on discussions with
a certain embedding customer).

I'm going to remove the topembed keyword unless someone protests...

Comment 41

[saari (gone)]

removing topembed after discussion about the bug

Comment 42

[Blake Ross]

changing selection qa to tpreston.

Comment 43

[Ryan Benech]

I voted for this cause in my mind it SHOULD BE A BUG not a feature.  I have
consensus from the 4 other people sitting around me (as I try to report my first
bug).  Although, I like the idea that clicking back to the unfocused selected
text doesn't immediately loose the selection, this should really only apply to
the 'address bar', not everything (like this <a
href=http://bugzilla.mozillduct=Browser&format=guideda.org/enter_bug.cgi?pro
page>Report a bug</a> page) 

I came here to report strange behavior in the mail client (which I'm sure is
this same issue).  I was selecting text out of the Mozilla mail window starting
with the body and then selecting the subject line.  The body was still the same
color (or maybe the greys were very similar for Modern theme) as the newly
selected subject... same when i selected the "to"... Strange huh...  I thought
it could be a 'misguided' feature or a bug... either way - I vote No!

If you wanted to know:
I had to copy all the text out of a mail message (recipient, subject, and body)
into my Lotus Notes client.  SMTP had to be lcoked down cause I don't want to
risk any outlook nimba clients giving us a bad name.

Comment 44

[Jesse Ruderman]

Bug 56472 (focusing form element does not clear selected text in page) is fixed,
but it's still possible to select text on the page and in Firefox's address bar.

Comment 46

[Jens Stutte [:jstutte]]

Bulk-downgrade of unassigned, >=3 years untouched DOM/Storage bug's priority.

If you have reason to believe this is wrong, please write a comment and ni :jstutte.