Background selection's color is not always changed



17 years ago
14 years ago


(Reporter: stf, Assigned: sfraser_bugs)





(1 attachment)

User-Agent:       Mozilla/5.0 (Macintosh; U; PPC Mac OS X; en-US; rv:1.0.1) Gecko/20021128 Chimera/0.6+
Build Identifier: Mozilla/5.0 (Macintosh; U; PPC Mac OS X; en-US; rv:1.0.1) Gecko/20021128 Chimera/0.6+

Selected text in background window should become gray and not remain with the
highlight color. Sometimes it's not becoming gray.
It only becomes gray between 2 frames, not between 2 windows or 2 applications.

Reproducible: Always

Steps to Reproduce:
WorksForMe using Chimera/2002112604. I access <>, select
some text, click the Finder, and click back on the selected text in the Chimera
window to return it to the front which keeps it selected and ensures the content
pane has focus). Text is blue when selected, turns grey when Finder gets focus,
and becomes blue again when I click on it.
Summary: Background Selection's color is not always changed → Background selection's color is not always changed
WFM 2002112805. Stephane, "sometimes" doesn't mean the same thing as
Reproducible Always. Please provide an example of how to reproduce. Thanks!
Sorry, I forgot to change Sometimes.
Here is another example, but when I found that it was not involving the Sidebar,
so wait before changing the status of this bug, I'll try to reproduce other ways.
Make a selection, open the sidebar, select one link (no double click), (close or
leave the sidebar opened), scrolldown the main page, not the sidebar, Cmd-C and
the grey text is copied ??
Another one.
Make selection in a page, click the Finder, it becomes gray.
Click inside the page, it becomes blue.
Click again the Finder, it becomes gray.
Click inside the page and now it will (always) remain gray.
If you are in the page and hold down the mouse, it becomes blue and of course it
disappear when you release the mouse button.
OK, I can reproduce that. 2002112805
Ever confirmed: true
Focus, ->bryner
Assignee: saari → bryner
Still present in 2003082402
Verified. Still present in 2005-03-21. Text changes to gray but does not return
to blue on re-active window state.
Severity: normal → minor
Priority: -- → P3
Target Milestone: --- → Camino1.2
*** Bug 212971 has been marked as a duplicate of this bug. ***
Assignee: bryner → sfraser_bugs
Severity: minor → normal
Target Milestone: Camino1.2 → Camino0.9
This patch fixes the bug by making sure that we dispatch a NS_ACTIVATE event
when the window becomes the key window. It does this via a new window-level
data structure, TopLevelWindowData, which is maintained, one per window, by

This patch also contains some IME NSLog cleanup, and fixes for bug 280894, and
bug 292473.
Attachment #186637 - Flags: review?(pinkerton)
Note that camino code is calling nsIWebBrowserFocus::SetActive on window
activate/deactivate, but that apparently isn't enough to fix up the focus color.
There is some discussion in bug 212971 comment 4.
Josh should look at that patch too.
Comment on attachment 186637 [details] [diff] [review]
Patch to fix this bug and IME issues

+- (id)init;

no need to put init here, as nobody actually calls it publically.

+- (void)setData:(id)inData forWindow:(NSWindow*)inWindow;

be explicit that this takes ownership of |inData|. Also, why not just have
clients register their NSWindow, rather than making them create the object and
pass it in? Seems cleaner to have the windowMap handle all the details.

r=pink otherwise. looks good.
Attachment #186637 - Flags: review?(pinkerton) → review+
This patch will also fix the bug where the caret for background tabs can show
through, if you've deactivated then reactivated Camino while on a page with a
blinking caret.
Patch checked in.
Closed: 14 years ago
Resolution: --- → FIXED
You need to log in before you can comment on or make changes to this bug.