212971 - Selected text does not change back to highlight color when you switch back to Camino

Status: RESOLVED DUPLICATE of bug 182783

(Camino Graveyard :: General, defect)

Description

[Derek Schrock]

User-Agent:       Mozilla/5.0 (Macintosh; U; PPC Mac OS X Mach-O; en-US; rv:1.5b) Gecko/20030715 Camino/0.7+
Build Identifier: Mozilla/5.0 (Macintosh; U; PPC Mac OS X Mach-O; en-US; rv:1.5b) Gecko/20030715 Camino/0.7+

If you have text selected in Camino then switch to another app or Camino window
the highlight color does not change back (it stays gray)

Reproducible: Always

Steps to Reproduce:
1. Open a new window (command-n)
2. Load something (that has text)
3. Select said text
4. Change apps (Finder, whatever) Notice the text selection is gray
5. Switch back to Camino

Another way
1. Have two Camino windows open
2. Load something with text
3. select text
4. Change to the other window
5. Switch to the original window
Actual Results:  
Text selection is gray

Expected Results:  
Text selection should have switched back to my Hightlight Color preference from
the General Preference Pane

Even though the highlight color isn't set back you can still perform actions on
the selected text such as copy

Comment 1

[Jasper]

Confirming using Camino 20030708.

Comment 2

[Mike Pinkerton (not reading bugmail)]

ugh, you're right. 

Comment 3

[Julian Pellico]

Hi,

I looked at this for a bit. When you switch tabs in the same window, the
selection is colored fine.

When -[CHBrowserView setActive:] gets called from -[BrowserWrapper
makePrimaryBrowserView:status:windowController:], the color of the selected text
is restored.

When -[CHBrowserView setActive:] gets called from -{BrowserWindowController
windowDidBecomeKey:], the color of the selected text isn't restored.

So I tried changing the line (BrowserWindowController.m:418, windowDidBecomeKey) to
    [mBrowserView makePrimaryBrowserView:mURLBar status:mStatus
windowController:self]

but that didn't do it. So something deeper is going on.

Pinkerton, any thoughts? I looked through some of the code and found a lot of
polymorphism going on, so it was hard to figure out what's different in the code
paths between the 2 cases.

Comment 4

[Simon Fraser [no longer active]]

The selection is redrawn with the hilite color in response to the dispatch of a
NS_GOTFOCUS event from [nsChildView becomeFirstResponder], which happens when
the tab control calls makeFirstResponder on the tab content.

This all happens before we call into the nsIWebBrowserFocus interface.

When activating and deactivating the window, the firstResponder doesn't change,
so these events don't get dispatched. (Another instance of mozilla's confusion
about focus vs. activation).

Comment 5

[Simon Fraser [no longer active]]

Here's why we do disable the selection on deactivate, but we don't enable it on
activate.

Selection disable/enable relies on focus and blur events getting to the
nsDocViewerFocusListener. On deactivate, the NS_DEACTIVATE event is handled by
the nsEventStateManager (ESM for short), and part of that handling is to "fire
blur on document and window" by sending a NS_BLUR_CONTENT event (sent to the doc
via mDocument->HandleDOMEvent() on line 872).

What I don't understand is why there is no corresponding NS_FOCUS_CONTENT event
sent out as a result of NS_ACTIVATE handling. That's why we never restore the
selection color.

Bryner, any enlightenment on the focus code?

BTW, neither Mozilla nor Firefox on Mac correctly disable the selection when the
app is deactivated; only when you switch between windows in the app.

Comment 6

[Simon Fraser [no longer active]]

Dup.

*** This bug has been marked as a duplicate of 182783 ***