Bug 159068 - [iOS] A WebPageProxy in closed state should not be allowed to hold a process assertion
Summary: [iOS] A WebPageProxy in closed state should not be allowed to hold a process ...
Status: RESOLVED FIXED
Alias: None
Product: WebKit
Classification: Unclassified
Component: WebKit2 (show other bugs)
Version: WebKit Nightly Build
Hardware: Unspecified iOS 9.3
: P1 Normal
Assignee: Chris Dumez
URL:
Keywords: InRadar
Depends on:
Blocks:
 
Reported: 2016-06-23 12:22 PDT by Chris Dumez
Modified: 2016-06-23 12:59 PDT (History)
8 users (show)

See Also:


Attachments
Patch (1.93 KB, patch)
2016-06-23 12:26 PDT, Chris Dumez
no flags Details | Formatted Diff | Diff

Note You need to log in before you can comment on or make changes to this bug.
Description Chris Dumez 2016-06-23 12:22:49 PDT
A WebPageProxy in closed state should not be allowed to hold a process assertion. It currently happens that WebPageProxy::close() gets called but that the WebPageProxy is kept alive by Safari (e.g. In case of top-hit preloading). In such cases, we fail to release the foreground process assertion that the WebPageProxy holds.

We should clear the foreground process assertion that the WebPageProxy holds as soon as WebPageProxy::close() is called.
Comment 1 Chris Dumez 2016-06-23 12:23:22 PDT
rdar://problem/17665473
Comment 2 Chris Dumez 2016-06-23 12:26:53 PDT
Created attachment 281928 [details]
Patch
Comment 3 Tim Horton 2016-06-23 12:52:51 PDT
Comment on attachment 281928 [details]
Patch

It doesn't make sense for Safari to keep the view alive if it has been closed; you can't come back from being closed, as far as I remember. Are you sure that is intentional?
Comment 4 Chris Dumez 2016-06-23 12:56:16 PDT
(In reply to comment #3)
> Comment on attachment 281928 [details]
> Patch
> 
> It doesn't make sense for Safari to keep the view alive if it has been
> closed; you can't come back from being closed, as far as I remember. Are you
> sure that is intentional?

It may not be intentional, I'll investigate separately. I definitely see close() getting called but not the destructor. Do you mind if we still land as is though? It cannot hurt to release the assertion as soon as close() is called I believe.
Comment 5 Chris Dumez 2016-06-23 12:59:09 PDT
Comment on attachment 281928 [details]
Patch

Clearing flags on attachment: 281928

Committed r202393: <http://trac.webkit.org/changeset/202393>
Comment 6 Chris Dumez 2016-06-23 12:59:14 PDT
All reviewed patches have been landed.  Closing bug.