[Webkit-unassigned] [Bug 107509] [Mac] Update PageVisibilityState when WebView is hidden / visible

[bugzilla-daemon at webkit.org]

https://bugs.webkit.org/show_bug.cgi?id=107509





--- Comment #8 from Joseph Pecoraro <joepeck at webkit.org>  2013-01-24 14:50:03 PST ---
(In reply to comment #7)
> (From update of attachment 184355 [details])
> View in context: https://bugs.webkit.org/attachment.cgi?id=184355&action=review
> 
> So I guess when you switch tabs, we still have to programmatically change page visibility?

Correct, that is a browser level feature, not a WebView level feature.

> What if someone move the view between windows? Let say I minimize Window 1, and some asshat move the view to Window 2?

When the WebView's superview / window hierarchy changes it will always get -[WebView viewDidMoveToWindow], which will update visibilityState.

> > Source/WebKit/mac/WebView/WebView.mm:3691
> > +- (void)_windowDidMiniaturize:(NSNotification *)notification
> > +{
> > +    [self _updateVisibilityState];
> > +}
> > +
> > +- (void)_windowDidDeminiaturize:(NSNotification *)notification
> > +{
> > +    [self _updateVisibilityState];
> > +}
> > +
> > +- (void)_windowDidOrderOnScreen:(NSNotification *)notification
> > +{
> > +    [self _updateVisibilityState];
> > +}
> > +
> > +- (void)_windowDidOrderOffScreen:(NSNotification *)notification
> > +{
> > +    [self _updateVisibilityState];
> > +}
> 
> Why not just make
> - (void)_windowVisibilityChanged:
> And register all notifications to that?

I thought of that, but I wanted to be as explicit as possible. I'll make this change.


> > Tools/TestWebKitAPI/TestWebKitAPI.xcodeproj/project.pbxproj:1076
> > +				A57A34F016AF677200C2501F /* PageVisibilityStateWithWindowChanges.mm in Sources */,
> 
> Build section could be sorted (my new favorite trick to r- patches) :)
> 
> > Tools/TestWebKitAPI/Tests/mac/PageVisibilityStateWithWindowChanges.mm:34
> > +static bool didGetPageSignal;
> 
> The name is a little generic.
> 
> > Tools/TestWebKitAPI/Tests/mac/PageVisibilityStateWithWindowChanges.mm:68
> > +    virtual NSURL *url() const { return [[NSBundle mainBundle] URLForResource:@"PageVisibilityStateWithWindowChanges" withExtension:@"html" subdirectory:@"TestWebKitAPI.resources"]; }
> > +    virtual void didLoadURL(WebView *webView) { runTest(webView); teardownView(webView); }
> > +    virtual void didLoadURL(WKView *wkView) { runTest(wkView); teardownView(wkView); }
> 
> Not a fan of inline implementation here.
> Missing OVERRIDE?

Inline is the convention here. All other didLoadURL implementations are inlined. I'll add OVERRIDe.

> 
> > Tools/TestWebKitAPI/Tests/mac/PageVisibilityStateWithWindowChanges.mm:74
> > +    virtual void initializeView(WebView *) OVERRIDE;
> > +    virtual void initializeView(WKView *) OVERRIDE;
> > +    virtual void teardownView(WebView *);
> > +    virtual void teardownView(WKView *);
> 
> Style? Missing OVERRIDE?

Nothing to override. This is new. I could upstream an empty impl to WebKitTestAgnostic and call it appropriately. Maybe "deinitializeView".

> > Tools/TestWebKitAPI/Tests/mac/PageVisibilityStateWithWindowChanges.mm:79
> > +    webView.UIDelegate = [[PageVisibilityStateDelegate alloc] init];
> 
> This looks like a leak.
> 
> > Tools/TestWebKitAPI/Tests/mac/PageVisibilityStateWithWindowChanges.mm:86
> > +    id uiDelegate = webView.UIDelegate;
> > +    webView.UIDelegate = nil;
> > +    [uiDelegate release];
> 
> ahahaha, okay.
> Maybe a RetainPtr as an attribute would makes things simpler?

This is exactly why I couldn't use RetainPtr and added teardownWebView. Because the WebView does not retain the delegate, I had to come up with something hacky. I could add a comment.

-- 
Configure bugmail: https://bugs.webkit.org/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the assignee for the bug.