WebKit Bugzilla
New
Browse
Log In
×
Sign in with GitHub
or
Remember my login
Create Account
·
Forgot Password
Forgotten password account recovery
RESOLVED FIXED
198622
Crash using WKHTTPCookieStore when you use WKWebView and UIWebView in the same app
https://bugs.webkit.org/show_bug.cgi?id=198622
Summary
Crash using WKHTTPCookieStore when you use WKWebView and UIWebView in the sam...
Geoffrey Garen
Reported
2019-06-06 13:43:20 PDT
Crash using WKHTTPCookieStore when you use WKWebView and UIWebView in the same app
Attachments
Patch
(2.63 KB, patch)
2019-06-06 13:48 PDT
,
Geoffrey Garen
no flags
Details
Formatted Diff
Diff
View All
Add attachment
proposed patch, testcase, etc.
Geoffrey Garen
Comment 1
2019-06-06 13:48:16 PDT
Created
attachment 371524
[details]
Patch
Tim Horton
Comment 2
2019-06-06 15:50:57 PDT
Comment on
attachment 371524
[details]
Patch Nice!
WebKit Commit Bot
Comment 3
2019-06-06 16:00:12 PDT
Comment on
attachment 371524
[details]
Patch Clearing flags on attachment: 371524 Committed
r246174
: <
https://trac.webkit.org/changeset/246174
>
WebKit Commit Bot
Comment 4
2019-06-06 16:00:13 PDT
All reviewed patches have been landed. Closing bug.
Radar WebKit Bug Importer
Comment 5
2019-06-06 16:01:51 PDT
<
rdar://problem/51503523
>
Darin Adler
Comment 6
2019-06-06 16:52:18 PDT
Comment on
attachment 371524
[details]
Patch View in context:
https://bugs.webkit.org/attachment.cgi?id=371524&action=review
> Source/WebKit/ChangeLog:20 > + (API::HTTPCookieStore::deleteCookie): Avoid using callOnMainThread > + becuase it is prohibited in the UI process.
Basic question: Does callOnMainThread already assert if it is called in the UI process? Expert question: Is there a way to catch such problems at compile time instead of runtime?
Tim Horton
Comment 7
2019-06-06 17:01:00 PDT
(In reply to Darin Adler from
comment #6
)
> Comment on
attachment 371524
[details]
> Patch > > View in context: >
https://bugs.webkit.org/attachment.cgi?id=371524&action=review
> > > Source/WebKit/ChangeLog:20 > > + (API::HTTPCookieStore::deleteCookie): Avoid using callOnMainThread > > + becuase it is prohibited in the UI process. > > Basic question: Does callOnMainThread already assert if it is called in the > UI process?
I don't think it does. We have the same problem with WebCore::Timer and I think the process to getting an assertion has been ... fraught. Mostly because it's OK (and necessary) for *legacy* WebKit to use it in the UI process, and telling the difference is hard. Dave Kilzer was working on this a while back.
> Expert question: Is there a way to catch such problems at compile time > instead of runtime?
Darin Adler
Comment 8
2019-06-06 17:14:09 PDT
Comment on
attachment 371524
[details]
Patch View in context:
https://bugs.webkit.org/attachment.cgi?id=371524&action=review
>>> Source/WebKit/ChangeLog:20 >>> + becuase it is prohibited in the UI process. >> >> Basic question: Does callOnMainThread already assert if it is called in the UI process? >> Expert question: Is there a way to catch such problems at compile time instead of runtime? > > I don't think it does. We have the same problem with WebCore::Timer and I think the process to getting an assertion has been ... fraught. Mostly because it's OK (and necessary) for *legacy* WebKit to use it in the UI process, and telling the difference is hard. Dave Kilzer was working on this a while back.
Well, maybe some kind of compile time (or I guess style checker time?) checking would be easier for at least obvious cases like these, since WebKit and LegacyWebKit are in different source directories.
Darin Adler
Comment 9
2019-06-06 17:16:03 PDT
Comment on
attachment 371524
[details]
Patch View in context:
https://bugs.webkit.org/attachment.cgi?id=371524&action=review
>>>> Source/WebKit/ChangeLog:20 >>>> + becuase it is prohibited in the UI process. >>> >>> Basic question: Does callOnMainThread already assert if it is called in the UI process? >>> Expert question: Is there a way to catch such problems at compile time instead of runtime? >> >> I don't think it does. We have the same problem with WebCore::Timer and I think the process to getting an assertion has been ... fraught. Mostly because it's OK (and necessary) for *legacy* WebKit to use it in the UI process, and telling the difference is hard. Dave Kilzer was working on this a while back. > > Well, maybe some kind of compile time (or I guess style checker time?) checking would be easier for at least obvious cases like these, since WebKit and LegacyWebKit are in different source directories.
Another idea: Add a runtime check that only works in processes that haven’t yet invoked Legacy WebKit at all. Bonus round: Make processes that aren’t apps explicitly using UIWebView not invoke Legacy WebKit at all.
Tim Horton
Comment 10
2019-06-06 17:29:35 PDT
(In reply to Darin Adler from
comment #9
)
> Comment on
attachment 371524
[details]
> Patch > > View in context: >
https://bugs.webkit.org/attachment.cgi?id=371524&action=review
> > >>>> Source/WebKit/ChangeLog:20 > >>>> + becuase it is prohibited in the UI process. > >>> > >>> Basic question: Does callOnMainThread already assert if it is called in the UI process? > >>> Expert question: Is there a way to catch such problems at compile time instead of runtime? > >> > >> I don't think it does. We have the same problem with WebCore::Timer and I think the process to getting an assertion has been ... fraught. Mostly because it's OK (and necessary) for *legacy* WebKit to use it in the UI process, and telling the difference is hard. Dave Kilzer was working on this a while back. > > > > Well, maybe some kind of compile time (or I guess style checker time?) checking would be easier for at least obvious cases like these, since WebKit and LegacyWebKit are in different source directories.
That is true!
> Another idea: Add a runtime check that only works in processes that haven’t > yet invoked Legacy WebKit at all. > Bonus round: Make processes that aren’t apps explicitly using UIWebView not > invoke Legacy WebKit at all.
See
https://bugs.webkit.org/show_bug.cgi?id=185330
for some of the previous fun, but yes, I vaguely think Dave was doing some of these things. Just haven't gotten there yet.
Note
You need to
log in
before you can comment on or make changes to this bug.
Top of Page
Format For Printing
XML
Clone This Bug