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 <http://www.mozilla.org/>, 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
Status: UNCONFIRMED → NEW
Ever confirmed: true
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 WindowDataMap. 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.
Status: NEW → ASSIGNED
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.
Status: ASSIGNED → RESOLVED
Closed: 14 years ago
Resolution: --- → FIXED
You need to log in before you can comment on or make changes to this bug.