Summary: | REGRESSION: controls in a background Safari window maintain active appearance if the address bar has focus | ||||||
---|---|---|---|---|---|---|---|
Product: | WebKit | Reporter: | mitz | ||||
Component: | Forms | Assignee: | Darin Adler <darin> | ||||
Status: | RESOLVED FIXED | ||||||
Severity: | Normal | CC: | adele | ||||
Priority: | P1 | Keywords: | InRadar, Regression | ||||
Version: | 523.x (Safari 3) | ||||||
Hardware: | Mac | ||||||
OS: | OS X 10.4 | ||||||
Attachments: |
|
Description
mitz
2007-04-07 15:48:29 PDT
Forcing a repaint corrects the widgets' appearance. Using Quartz Debug you can see that if the WebView is first responder when sending the window to the background, the widgets repaint, but if the address bar is first responder, they don't. (To force a repaint while the window is in the background, have another tab open in the window and command-click that tab to switch to it while keeping the window in the background). The problem here is that repainting the widgets when the control tint changes is done in Frame::setIsActive. But the rule for when the widgets have active vs. inactive tint is not "is active". Should not be too difficult to fix. Will require changes to Frame and to WebHTMLView as well. Created attachment 14046 [details]
patch that updates the tint based on the appropriate AppKit method
Comment on attachment 14046 [details]
patch that updates the tint based on the appropriate AppKit method
I think the names "setSecureKeyboardEntry()" and "setNeedsSecureKeyboardEntry()" are confusingly similar.
Also, you probably realize that you could learn of changes to the window's key state by listening to NSWindowDidBecomeKey/NSWindowDidResignKey rather than using _windowChangedKeyState. I presume you chose _windowChangedKeystate for simplicity/performance. Maybe worth a comment.
r=me
Comment on attachment 14046 [details]
patch that updates the tint based on the appropriate AppKit method
Typo:
+ // We do a "fake" paintm, and when the theme gets a paint call, it can then do an invalidate.
(In reply to comment #5) > I think the names "setSecureKeyboardEntry()" and > "setNeedsSecureKeyboardEntry()" are confusingly similar. OK. Maybe I can think of better names. > Also, you probably realize that you could learn of changes to the window's key > state by listening to NSWindowDidBecomeKey/NSWindowDidResignKey rather than > using _windowChangedKeyState. I presume you chose _windowChangedKeystate for > simplicity/performance. Maybe worth a comment. Actually, _windowChangedKeystate sounds like it's the same thing as NSWindowDidBecomeKey, but it's actually *quite* a bit different. It does just the right thing for control appearance which is way more than just "is this particular window key". I would like to add a comment about that. Sending WebCore/ChangeLog Sending WebCore/WebCore.exp Sending WebCore/html/HTMLInputElement.cpp Sending WebCore/page/Frame.cpp Sending WebCore/page/Frame.h Sending WebCore/page/FramePrivate.h Sending WebCore/page/FrameView.cpp Sending WebCore/page/FrameView.h Sending WebCore/page/mac/FrameMac.mm Sending WebCore/rendering/RenderTheme.cpp Sending WebCore/rendering/RenderThemeMac.mm Sending WebKit/ChangeLog Sending WebKit/WebView/WebHTMLView.mm Transmitting file data ............. Committed revision 20901. |