47796 - selected text loses background color when dialog box opens

Status: NEW

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

Description

[Greg Roelofs]

Linux/x86/glibc with talkback nightly 2000-08-05-04-M17.

Select some text on a page; on Linux, color changes from default
black-on-gray192 to white-on-blue.  Do "save image as..." or another operation
that opens a dialog box; as soon as dialog box appears, blue background changes
to gray176, but foreground remains white (and text remains selected/pastable). 
In my tests, the dialog box opens completely outside the browser window (upper
left corner of display); the selected text is never covered.

Subsequently covering the selected text, either with another window or by
scrolling, fails to affect the white-on-gray176 appearance.

Comment 1

[Sean Richardson]

This looks like the issue raised in bug 36848, "Should only be one selection per 
window" again, as you predicted, Eli.

Greg, the selected text does revert back to normal white-on-blue colours
once you close the dialog, right? If so, take a look at bug 36848 and
say whether you think this bug is about the same issue (and whether you 
agree with WONTFIX); if not, please give details about what *does* happen.
Thanks.

Comment 2

[Greg Roelofs]

Yes, it's similar or identical to bug 36848.  It does NOT revert to "normal"
highlight colors when the dialog box goes away, nor (per 36848) when I click on
the scrollbar, nor when I hit the Tab key.

Eli and/or Mike, it's your call whether this one remains open or the older one
reopens, but it's definitely broken.  To wit:

(1) The dialog box contains no highlighted text, yet the main-window selection
turns gray.

(2) The selection is still active (i.e., what gets pasted) even though it's
gray.

(3) Selecting main-window text, then URL-bar text, then *clicking* in the URL
bar to make its highlight go away, does not deactivate the formerly selected
text in the URL bar; it's still active, but it isn't highlighted.  I was also
able to trigger a crash this way (once), but I can't reproduce that.

(4) Pasting ex-URL-bar text into the main window area causes the grayed-out
selection there to re-blue itself, but the pasting actually goes *into* the URL
bar (replacing the entire contents *and entering it* even though the selection
did not include a newline), and a new page comes up shortly thereafter.  Also,
the brief blue-highlight does not "take"; the ex-URL-bar text remains active
even though the main-window text was blue before going to the new page.

(5) Mozilla has no clue about selected X text in *other* applications, so its
selections remain blue even when they're not active.  It only turns gray when
the other text is pasted in Mozilla's window, by which time it's too late.

(6) If the selected text is already white-on-blue, there is absolutely no visual
feedback that it's also selected.  I assume this is similarly true of
white-on-gray176.

So call this a feature if you wish, but it violates the Principle of Least
Astonishment in multiple regards and will cause you endless grief until you do
something sensible about it.  My recommendation would be to disable it entirely
until it's at least vaguely close to working.  (And maybe talk to some UI
experts, too. :-) )

Greg

Comment 3

[rubydoo123]

setting to nsbeta3+

Comment 4

[Blake Ross]

*SPAM*: Changing the QA contact of all open/resolved Selection bugs from 
[e-mail] to [e-mail].  After the many great years of service 
Eli has given to Mozilla, it's time for him to move on; he has accepted a 
position at Eazel.  We'll be sad to see him go, and I'll do my best to fill his 
spot...

Comment 5

[rubydoo123]

will try to get to this before nsbeta3

Comment 6

[mjudge]

this appears to be different on different window managers.  I am looking into 
the ability for mozilla with autocopy on to not grey the selection on blur. and 
to only grey it when it is notified that it has lost the clipboard.  not sure if 
i can get to this or not. i need pavlov for assistance i believe.

Comment 7

[mjudge]

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

Comment 8

[mjudge]

i have been looking at this. it is a problem on akkanas machine but not on 
saari's machine. it seems that blurs/focus are being fired differently depending 
on your window manager.i honestly dont have a clue here whats going on the unix 
side.  part of me wants to give this to saari, but i know he has allot to do 
right now.  So if I give it to him I dont know how he will fix it since its so 
hard for him to reproduce on his machine. I will talk to him again about this 
today.

Comment 9

[Greg Roelofs]

FWIW, I'm using fvwm2 on Slackware 7.0 (glibc 2.1.2, basically pretty up-to-date).

Comment 10

[rubydoo123]

moving this out to future

Comment 11

[Blake Ross]

changing selection qa to tpreston.

Comment 12

[rubydoo123]

removing myself from the cc list

Comment 13

[Jon Henry]

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

Comment 14

[Jon Henry]

Changing OS to All per the bug I just duped here, I can reproduce on Win 2000 by
selecting text and opening the Find dialog (Ctrl-F).

Comment 15

[RNicoletto]

Up to date situation:
- Ctrl+O (Open File...), Ctrl+S (Save Page As...) don't change the background color of text selection (HEX 5075CE)
- Ctrl+L (Open Location...), Ctrl+F (Find in page...), Ctrl+J (Downloads Panel) do change the background color of text selection (HEX B0B0B0)

Mozilla/5.0 (Windows; Windows NT 5.1; en-US; rv:2.0b2pre) Gecko/20100716 Minefield/4.0b2pre

Comment 16

[John Drinkwater (:beta)]

Noticed this behaviour while debugging some ::-moz-selection CSS, while in the style editor it keeps reverting to the default grey selection.

Additionally window focus triggers this.

Comment 15 mentions Ctrl+O etc don’t change the background colour; this might have reverted since, as that also does so now.

> Aurora 32 on Linux