Summary: | [iOS] ViewServices started by StoreKitUIService may get suspended unexpectedly | ||||||
---|---|---|---|---|---|---|---|
Product: | WebKit | Reporter: | Chris Dumez <cdumez> | ||||
Component: | WebKit2 | Assignee: | Chris Dumez <cdumez> | ||||
Status: | RESOLVED FIXED | ||||||
Severity: | Normal | CC: | achristensen, aestes, beidson, commit-queue, ggaren, sam, thorton, webkit-bug-importer, yongjun_zhang | ||||
Priority: | P1 | Keywords: | InRadar | ||||
Version: | WebKit Nightly Build | ||||||
Hardware: | Unspecified | ||||||
OS: | Unspecified | ||||||
Attachments: |
|
Description
Chris Dumez
2017-08-23 20:11:35 PDT
Created attachment 318962 [details]
Patch
Comment on attachment 318962 [details] Patch View in context: https://bugs.webkit.org/attachment.cgi?id=318962&action=review > Source/WebKit/UIProcess/ApplicationStateTracker.mm:153 > + m_isInBackground = false; Can’t they just use the WKWebViewConfiguration SPI to be treated like they’re always in the foreground, like every other instance of this? Comment on attachment 318962 [details]
Patch
If not, please kick back for review, but it seems wrong to special case this when we already have a mechanism to handle it. If this were a generic mechanism to handle doubly-service-hosted web views, that would be a different story.
Specifically, I am referring to _setAlwaysRunsAtForegroundPriority: (In reply to Tim Horton from comment #5) > Specifically, I am referring to _setAlwaysRunsAtForegroundPriority: The host app doesn’t have access to WKWebview since it is using Safari view controller. Comment on attachment 318962 [details] Patch Clearing flags on attachment: 318962 Committed r221138: <http://trac.webkit.org/changeset/221138> All reviewed patches have been landed. Closing bug. |