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

RESOLVED DUPLICATE of bug 182783

Status

RESOLVED DUPLICATE of bug 182783
15 years ago
13 years ago

People

(Reporter: dereks, Assigned: mikepinkerton)

Tracking

unspecified
Camino0.9
PowerPC
Mac OS X

Details

(Reporter)

Description

15 years ago
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

15 years ago
Confirming using Camino 20030708.
(Assignee)

Comment 2

15 years ago
ugh, you're right. 
Assignee: saari → pinkerton
Target Milestone: --- → Camino0.8
(Assignee)

Updated

15 years ago
Target Milestone: Camino0.8 → Camino0.9

Comment 3

14 years ago
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

14 years ago
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

14 years ago
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

13 years ago
Dup.

*** This bug has been marked as a duplicate of 182783 ***
Status: NEW → RESOLVED
Last Resolved: 13 years ago
Resolution: --- → DUPLICATE
You need to log in before you can comment on or make changes to this bug.