7465 - selected text not deselected when focus switched to other window

Status: RESOLVED FIXED

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

Description

[cpratt]

build id: 1999060108
platform: windows nt

to reproduce: launch apprunner. create a second browser window. position them on
the screen so that you can see the location control in each of the two windows.
in window a, select the text in the location control (it will be highlighted).
then, switch focus to window B by clicking its title bar or alt-tabbing to it.
result: the text in the location control of window a remains highlighted.
expected result: it is deselected/de-highlighted upon loss of focus.

Comment 1

[Claudius Gayle]

cc'ing radha b/c Mike is going to say he doesn't own selection in the location bar.
Following the above directions to reproduce on all three platforms in Nova and Seamonkey yields six(6) different results.
I imagine some of the behavior is OS specific/related but since in no case does Seamonkey do the same thing as Nova i'm at a
loss to say what's right/wrong/desired.

Now for the definitive treatise on switching focus while location bar text is selected:

On the Mac:
Nova - Upon clicking the second window, the location field text is deselected. Nova 'remembers' the selection when the focus
returns to the first window and the text is subsequently rehilighted.
Seamonkey -  Upon clicking the second window, the location field text is deselected. No 'remembering'

On RHLinux 5.2 with KDE:
Nova - Upon clicking the second window; nothing. When you select text in the second location field then the original text
deselects.
Seamonkey - Upon clicking the second window; nothing. When you select text in the second location field then selection in the
first field changes color (from blue to grey). Returning focus to the first window still leaves you grey.

On WinNT:
Nova - Upon clicking the second window, text is immediately deselected. No 'remembering' upon return.
Seamonkey - Location text never gets deselected until you click in the smae location field again.

Comment 2

[Kathleen :Brade]

claudius:  it would be useful if we knew what the seamonkey behavior for this is
in the editor (since someday the editor may be the widget in the location area);
could you check?  THANKS!

Comment 3

[leger]

Per a request from Selection and Search component eng (mjudge) and qa (elig),
moving all "Selection and Search" bugs to new "Selection" component.  Original
"Selection and Search" component will be retired.

Comment 4

[Eli Goldberg]

[QA Assigning to self.]

Comment 5

[Kathleen :Brade]

set to M11; change to all platforms since we want it unified

Comment 6

[buster]

I believe the right behavior is this:
1. when any editor (editor window, embedded editor component, text widget...)
loses focus to another control within the same application, selection should be
cleared from that editor and not "remembered."  This scheme assumes things like
menus and buttons don't steal focus from the editor.  Any blur/focus events that
are the result of chrome focus switches should be ignored, so that selection in
the editor is always displayed.
2. when a top-level window ("the app") loses focus to another app, selection
should be hidden, but remembered, so that when the top-level window regains
focus, selection is displayed again.
This depends on the event system giving the editor the ability to differentiate
between different kinds of focus/blur events.

Comment 7

[mjudge]

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

Comment 8

[mjudge]

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

Comment 9

[Kathleen :Brade]

m12
mike--consider moving to M14 (post-beta) if you think there aren't any
architectural issues involved.

Comment 10

[rubydoo123]

changing the milestone to M15, this can wait till after beta. I am also changing
status to assign.

Comment 11

[rubydoo123]

Using the 19991102 build on win95, if I open the editor, enter some text,
highlight the text and then select another control and return to the editor, the
text selection is remembered. If I select another app like Word or Notepad, the
behavior is the same. This is the same same behavior that Word has. If I have a
Word document open, enter text, highlight some text and then select another app,
the selected text is remembered. If I have 2 Word documents open and I toggle
between the documents, the selection is also remembered. So, isn't this now
working like it should be? Christopher -- can you try this out on a more current
build and see if you agree with how it is working?

Comment 12

[cpratt]

I'm doing to do a complete 180 degree turn here. :) - Based on Beth's comments,
idea/expected behavior would be for selections to be the same upon returning to
a window. Currently (the 1999110313 build under Windows 98) the selected text in
the Location: control is not remember when returning to the window after
switching to another window/app. I would expect it to be.

beppe is speaking specifically about Editor behavior, but this bug was
originally to do only with the text in the Location: control in the browser.

Comment 13

[Eli Goldberg]

[note to self: be sure to check scenario of a frames-based page when verifying
this bug. See bug #12047 for more info.]

Comment 14

[Eli Goldberg]

[Note to self: When verifying this bug, be sure to check endico's scenario from 
bug #14026]

>Copy/paste from browser windows seems fine except that when you have something
>highlighted in the browser window and then highlight text in the url bar, the
>text in the browser window doesn't unhighlight. (this doesn't prevent
>copy/paste though) (I tried both ctrl-C and menu)

Comment 15

[rubydoo123]

moving over to M17

Comment 16

[Matthew T (active 1999-2002)]

The problem with more than one selection in the same window is bug 36848.

As for this bug, I believe the most useful behavior is to remember the selection 
in a non-active window. If I accidentally moused out of a window on a Unix window 
manager which had hover-to-focus, and lost a carefully-prepared selection, that 
would be pretty annoying.

But that non-active selection should be shown in a different style from the 
active selection. Common rendering on Mac OS is to replace the filled block of 
the selection color with a 1-pixel border in the selection color. And common 
rendering on Windows is to hide the non-active selection completely until the 
window is given focus again.

This should apply whether or not it's the location bar we're talking about, and 
whether or not the other window is a Mozilla window.

Comment 17

[anthonyd]

by adding the selection attribute SELECTION_HIDDEN, this is now working as the 
selection is now remembered.  marking bug as FIXED.

Comment 18

[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...