141007 - Selections in text controls in inactive windows "cleared" instead of being drawn as inactive selections

Status: NEW

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

Description

[The Cunctator]

(reported under Build 2002031005)

There needs to be a difference in visuals between active, inactive, and no
selection.

Currently Mozilla only renders active and no selection. Active selections are
rendered by the background color being changed to the selection color (e.g. gray).
 
Examples where this happens:

1) Selected text in a window which has lost focus should be rendered as an
inactive selection. Currently the behavior is inconsistent: 
  a) selected text in the url bar loses its highlighting entirely when 
     its containing window loses focus. It should instead be rendered as 
     an inactive selection. (Note that the url bar text does not lose 
     the selection; if focus returns to its containing window, the 
     highlighting is again rendered.)
  b) selected text within the browser window does not change its highlighting 
     when its containing window loses focus. It should instead be rendered
     as an inactive selection.

2) in a window with a textarea, if the main window text is selected (by dragging
or command-A), then focus is changed to the textarea, the selection should be
evidently inactive. In this case the inactive selection looks like the active
selection, whereas it should be visually different from the active selection.
(It's questionable whether any text should remain selected, but that's a
discussion for another bug).


Inactive selections in Mac UI (and probably others) should be rendered only as a
bounding box or in a secondary color, not as the primary selection color.

Here's the official Apple line on this:

http://developer.apple.com/techpubs/macosx/Essentials/AquaHIGuidelines/AHIGUserInput/iSelections_in_Text.html

They want inactive selections to be rendered in the secondary color, a
percentage of the primary selection color (the Stickies app is a good example of
this at work).

Other programs (such as Mac IE, BBEdit) instead use a bounding box with border
color of the primary selection color to indicate inactive selections.

Comment 1

[The Cunctator]

Previous discussion of this bug is at
http://bugzilla.mozilla.org/show_bug.cgi?id=124617

Comment 2

[The Cunctator]

See also http://bugzilla.mozilla.org/show_bug.cgi?id=141011 (RFE: Clicking in
textarea should deselect text outside of textarea) for an alternate take on
Example 2 above.

Comment 3

[The Cunctator]

See also bug 36848 (Should only be one text selection per window) and bug 73373
(Multiple Selection of Text with CTRL)

Comment 4

[Boris Zbarsky [:bzbarsky]]

Over to selection.  This is pp, since on Linux we do the
blue=active/gray=inactive thing correctly.

Comment 5

[saari (gone)]

er, we should be doing this on OSX too, that implies there may be a focus/blur
issue on X

Comment 6

[Frankie]

Still incorrect in Moz 20030312 OSX; deleting the missed target of 1.1.

Comment 7

[Smokey Ardisson (offline for a while; not following bugs - do not email)]

So the only thing I still see here is selected text in HTML text form controls (which is sorta 1a) and probably a bunch of Fx chrome/XUL (i.e., the location bar, 1a).

When there is text selected in a form control (e.g., the Additional Comments textarea) and that window loses focus (either to another window in the app, or from the entire app losing focus to another app), the active selection color is "cleared" entirely (it's restored when the window regains focus).

Instead of "clearing" the selection color when the window loses focus, we should use the inactive selection color like we do on all other selections.

If the issue is pp as bz says in comment 4, I'm not sure the bug really lies in editor/selection code, but what do I know—and we know bz is waaay smarter than me ;)

Comment 9

[Jens Stutte [:jstutte]]

Bulk-downgrade of unassigned, untouched DOM/Storage bug's priority.

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