Bug 132111

Summary: Text caret disappears in Mail after returning from another application
Product: WebKit Reporter: Ryosuke Niwa <rniwa>
Component: WebKit Misc.Assignee: Ryosuke Niwa <rniwa>
Status: RESOLVED FIXED    
Severity: Normal CC: ap, commit-queue, darin, enrica, mitz
Priority: P2 Keywords: InRadar
Version: 528+ (Nightly build)   
Hardware: Unspecified   
OS: Unspecified   
Attachments:
Description Flags
Fixes the bug
none
Patch for landing none

Description Ryosuke Niwa 2014-04-24 00:19:11 PDT
Reproduction steps:
1. Run Mail.
2. Create a new blank message
3. Type something into the message
4. Click in Finder.
5. Select Finder>Hide Others (Mail disappears)
6. Click on Mail in the Dock (Mail reappears)

Expected result:
The text caret blinks

Actual result:
The text caret is never rendered :(

<rdar://problem/12328567>
Comment 1 Ryosuke Niwa 2014-04-24 00:47:54 PDT
Created attachment 230059 [details]
Fixes the bug
Comment 2 Darin Adler 2014-04-24 07:57:04 PDT
Comment on attachment 230059 [details]
Fixes the bug

View in context: https://bugs.webkit.org/attachment.cgi?id=230059&action=review

I’m saying review+ but I am not sure about a few aspects of the patch.

> Source/WebKit/mac/WebView/WebView.mm:5227
> +        [[NSNotificationCenter defaultCenter] addObserver:self selector:@selector(_windowKeyStateChanged:)
> +            name:NSWindowDidBecomeKeyNotification object:nil];
> +        [[NSNotificationCenter defaultCenter] addObserver:self selector:@selector(_windowKeyStateChanged:)
> +            name:NSWindowDidResignKeyNotification object:nil];

This says we want a notification any time *any* window in this app becomes or resigns key, since we pass an object of nil. Is that really what we want? I think we want to pass object:window here, but then we’ll have to retest to be sure this actually fixes the bug.

> Source/WebKit/mac/WebView/WebView.mm:-5335
> -- (void)_windowChangedKeyState

I’m not sure exactly why I overrode this internal AppKit method in 2007 rather than using the notifications. I am concerned that this might have significantly different behavior from the old code in ways that go beyond fixing this bug.

I think that in 2007 this exactly matched how AppKit itself kept controls up to date, so maybe that’s why I did it that way.

> Source/WebKit/mac/WebView/WebView.mm:5342
> +- (void)_windowKeyStateChanged:(NSNotification *)notification

I know WebKit does this all over the place, but it’s dangerous to use an underscore prefix because this could easily conflict with a same-named method inside a future version of AppKit. Given that names without prefixes and names with an underscore prefix are both fair game for both AppKit and for apps who might subclass WebView, we should probably use some kind of crazy wk_ prefix on our internal methods. Sorry, not really specific to this patch, and really ugly so maybe others on the project won’t agree.
Comment 3 Ryosuke Niwa 2014-04-24 12:45:42 PDT
(In reply to comment #2)
> (From update of attachment 230059 [details])
> View in context: https://bugs.webkit.org/attachment.cgi?id=230059&action=review
> 
> I’m saying review+ but I am not sure about a few aspects of the patch.
> 
> > Source/WebKit/mac/WebView/WebView.mm:5227
> > +        [[NSNotificationCenter defaultCenter] addObserver:self selector:@selector(_windowKeyStateChanged:)
> > +            name:NSWindowDidBecomeKeyNotification object:nil];
> > +        [[NSNotificationCenter defaultCenter] addObserver:self selector:@selector(_windowKeyStateChanged:)
> > +            name:NSWindowDidResignKeyNotification object:nil];
> 
> This says we want a notification any time *any* window in this app becomes or resigns key, since we pass an object of nil. Is that really what we want? I think we want to pass object:window here, but then we’ll have to retest to be sure this actually fixes the bug.

Oops, fixed that.

> > Source/WebKit/mac/WebView/WebView.mm:-5335
> > -- (void)_windowChangedKeyState
> 
> I’m not sure exactly why I overrode this internal AppKit method in 2007 rather than using the notifications. I am concerned that this might have significantly different behavior from the old code in ways that go beyond fixing this bug.
> 
> I think that in 2007 this exactly matched how AppKit itself kept controls up to date, so maybe that’s why I did it that way.

We can make a more conservative change to observe these two notification as well as overriding _windowChangedKeyState.  But given WebKit2 only uses the notifications, I'd rather stick to the standardized API surface.  We can always add the code back.

> > Source/WebKit/mac/WebView/WebView.mm:5342
> > +- (void)_windowKeyStateChanged:(NSNotification *)notification
> 
> I know WebKit does this all over the place, but it’s dangerous to use an underscore prefix because this could easily conflict with a same-named method inside a future version of AppKit. Given that names without prefixes and names with an underscore prefix are both fair game for both AppKit and for apps who might subclass WebView, we should probably use some kind of crazy wk_ prefix on our internal methods. Sorry, not really specific to this patch, and really ugly so maybe others on the project won’t agree.

Removed the leading _.
Comment 4 Ryosuke Niwa 2014-04-24 12:46:00 PDT
Created attachment 230098 [details]
Patch for landing
Comment 5 WebKit Commit Bot 2014-04-24 13:24:44 PDT
Comment on attachment 230098 [details]
Patch for landing

Clearing flags on attachment: 230098

Committed r167770: <http://trac.webkit.org/changeset/167770>
Comment 6 WebKit Commit Bot 2014-04-24 13:24:48 PDT
All reviewed patches have been landed.  Closing bug.