Bug 183075 - Release assertion in WebPage::updatePreferences
Summary: Release assertion in WebPage::updatePreferences
Status: RESOLVED FIXED
Alias: None
Product: WebKit
Classification: Unclassified
Component: WebKit2 (show other bugs)
Version: WebKit Nightly Build
Hardware: Unspecified Unspecified
: P2 Normal
Assignee: Ryosuke Niwa
URL:
Keywords: InRadar
: 183135 (view as bug list)
Depends on:
Blocks:
 
Reported: 2018-02-22 23:25 PST by Ryosuke Niwa
Modified: 2018-02-26 12:44 PST (History)
6 users (show)

See Also:

Attachments
Patch (5.19 KB, patch)
2018-02-22 23:34 PST, Ryosuke Niwa 		no flags Details | Formatted Diff | Diff
Patch (5.26 KB, patch)
2018-02-24 16:24 PST, Ryosuke Niwa 		no flags Details | Formatted Diff | Diff
Patch for landing (4.93 KB, patch)
2018-02-26 11:33 PST, Ryosuke Niwa 		no flags Details | Formatted Diff | Diff
Patch for landing (4.95 KB, patch)
2018-02-26 12:38 PST, Ryosuke Niwa 		rniwa: commit-queue+
Details | Formatted Diff | Diff
Show Obsolete (3) View All Add an attachment (proposed patch, testcase, etc.)

Note You need to log in before you can comment on or make changes to this bug.
Description Ryosuke Niwa 2018-02-22 23:25:26 PST 
After https://trac.webkit.org/changeset/228589, some people are hitting release assertions.
There appears to be a race condition between UI process and WebContent process's preferences being synced vs web view being created.

<rdar://problem/37790257>
Comment 1 Ryosuke Niwa 2018-02-22 23:34:07 PST 
Created attachment 334506 [details]
Patch
Comment 2 Ryosuke Niwa 2018-02-24 16:24:32 PST 
Created attachment 334568 [details]
Patch
Comment 3 youenn fablet 2018-02-26 10:43:37 PST 
Comment on attachment 334568 [details]
Patch

r=me with non sw-enabled build fix.

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

> Source/WebKit/StorageProcess/StorageProcess.cpp:191
> +        return;

The work done here seems harmless so maybe we can do it anyway, especially since we are disabling any IPC to Messages::WebSWServerToContextConnection?
I am not familiar with this routine but maybe there is a chance for a race condition somehow so that we initialize the website data store first and get the entitlement later on.
Comment 4 Chris Dumez 2018-02-26 10:44:40 PST 

*** This bug has been marked as a duplicate of bug 183135 ***
Comment 5 Chris Dumez 2018-02-26 10:49:15 PST 
Comment on attachment 334568 [details]
Patch

lgtm too.
Comment 6 Ryosuke Niwa 2018-02-26 11:33:54 PST 
Reopening to attach new patch.
Comment 7 Ryosuke Niwa 2018-02-26 11:33:55 PST 
Created attachment 334631 [details]
Patch for landing
Comment 8 Ryosuke Niwa 2018-02-26 11:34:10 PST 
Comment on attachment 334631 [details]
Patch for landing

Wait for EWS.
Comment 9 Chris Dumez 2018-02-26 11:34:40 PST 
*** Bug 183135 has been marked as a duplicate of this bug. ***
Comment 10 Ryosuke Niwa 2018-02-26 12:37:27 PST 
Comment on attachment 334568 [details]
Patch

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

>> Source/WebKit/StorageProcess/StorageProcess.cpp:191
>> +        return;
> 
> The work done here seems harmless so maybe we can do it anyway, especially since we are disabling any IPC to Messages::WebSWServerToContextConnection?
> I am not familiar with this routine but maybe there is a chance for a race condition somehow so that we initialize the website data store first and get the entitlement later on.

We need this check to disable service worker in the storage process.
Comment 11 Ryosuke Niwa 2018-02-26 12:38:38 PST 
Created attachment 334634 [details]
Patch for landing
Comment 12 Ryosuke Niwa 2018-02-26 12:44:52 PST 
Committed r229037: <https://trac.webkit.org/changeset/229037>