WebKit Bugzilla
New
Browse
Search+
Log In
×
Sign in with GitHub
or
Remember my login
Create Account
·
Forgot Password
Forgotten password account recovery
RESOLVED FIXED
227607
WebPageProxy::setAppHighlightsVisibility might send message from a background thread, ASSERTing
https://bugs.webkit.org/show_bug.cgi?id=227607
Summary
WebPageProxy::setAppHighlightsVisibility might send message from a background...
Brady Eidson
Reported
2021-07-01 20:10:52 PDT
WebPageProxy::setAppHighlightsVisibility might send message from a background thread, ASSERTing <
rdar://80056481
>
Attachments
Patch
(1.64 KB, patch)
2021-07-01 20:13 PDT
,
Brady Eidson
thorton
: review+
Details
Formatted Diff
Diff
Patch reviewed on Slack
(2.13 KB, patch)
2021-07-02 09:26 PDT
,
Brady Eidson
no flags
Details
Formatted Diff
Diff
View All
Add attachment
proposed patch, testcase, etc.
Brady Eidson
Comment 1
2021-07-01 20:13:58 PDT
Created
attachment 432765
[details]
Patch
Chris Dumez
Comment 2
2021-07-01 21:19:50 PDT
Can’t we just send the radar to the client? I worry about us opening the door to clients calling ours APIs on non main threads.
Brady Eidson
Comment 3
2021-07-01 21:25:28 PDT
(In reply to Chris Dumez from
comment #2
)
> Can’t we just send the radar to the client? I worry about us opening the > door to clients calling ours APIs on non main threads.
The client is *US*
Brady Eidson
Comment 4
2021-07-01 21:27:58 PDT
(In reply to Brady Eidson from
comment #3
)
> (In reply to Chris Dumez from
comment #2
) > > Can’t we just send the radar to the client? I worry about us opening the > > door to clients calling ours APIs on non main threads. > > The client is *US*
(It's not really us, but it's our own block we're passing to another system framework and it's expected that block gets called on a non-main thread)
Brady Eidson
Comment 5
2021-07-01 21:28:17 PDT
(In reply to Brady Eidson from
comment #4
)
> (In reply to Brady Eidson from
comment #3
) > > (In reply to Chris Dumez from
comment #2
) > > > Can’t we just send the radar to the client? I worry about us opening the > > > door to clients calling ours APIs on non main threads. > > > > The client is *US* > > (It's not really us, but it's our own block we're passing to another system > framework and it's expected that block gets called on a non-main thread)
So, if you prefer, I could fix this inside that block instead.
Chris Dumez
Comment 6
2021-07-01 21:47:09 PDT
(In reply to Brady Eidson from
comment #5
)
> (In reply to Brady Eidson from
comment #4
) > > (In reply to Brady Eidson from
comment #3
) > > > (In reply to Chris Dumez from
comment #2
) > > > > Can’t we just send the radar to the client? I worry about us opening the > > > > door to clients calling ours APIs on non main threads. > > > > > > The client is *US* > > > > (It's not really us, but it's our own block we're passing to another system > > framework and it's expected that block gets called on a non-main thread) > > So, if you prefer, I could fix this inside that block instead.
Oh, I see. Then yes, I think it would look nicer to fix it at the call site rather than doing a trampoline in WebPageProxy.
Chris Dumez
Comment 7
2021-07-01 22:06:21 PDT
Comment on
attachment 432765
[details]
Patch View in context:
https://bugs.webkit.org/attachment.cgi?id=432765&action=review
> Source/WebKit/UIProcess/Cocoa/WebPageProxyCocoa.mm:591 > + callOnMainRunLoop([protectedThis = makeRef(*this), appHighlightsVisibility] {
As I mentioned earlier, I think this should be fixed at the call site. Also, I looked at the call site in WebPageProxy::setUpHighlightsObserver() and I am not convinced this is safe. What ensures that setAppHighlightsVisibility() is not getting called on the background thread while the WebPageProxy is in the middle of destruction on the main thread? Your call to makeRef(*this) here would try to ref the page even though its destructor is running. Is there something I missed that makes sure this cannot happen?
Tim Horton
Comment 8
2021-07-01 22:45:04 PDT
(In reply to Chris Dumez from
comment #7
)
> Comment on
attachment 432765
[details]
> Patch > > View in context: >
https://bugs.webkit.org/attachment.cgi?id=432765&action=review
> > > Source/WebKit/UIProcess/Cocoa/WebPageProxyCocoa.mm:591 > > + callOnMainRunLoop([protectedThis = makeRef(*this), appHighlightsVisibility] { > > As I mentioned earlier, I think this should be fixed at the call site.
I said the same to Brady elsewhere and he promised to make that change (and then I r+’d anyway :| )
Brady Eidson
Comment 9
2021-07-02 09:13:30 PDT
(In reply to Chris Dumez from
comment #7
)
> Comment on
attachment 432765
[details]
> Patch > > View in context: >
https://bugs.webkit.org/attachment.cgi?id=432765&action=review
> > > Source/WebKit/UIProcess/Cocoa/WebPageProxyCocoa.mm:591 > > + callOnMainRunLoop([protectedThis = makeRef(*this), appHighlightsVisibility] { > > As I mentioned earlier, I think this should be fixed at the call site. > > Also, I looked at the call site in WebPageProxy::setUpHighlightsObserver() > and I am not convinced this is safe. What ensures that > setAppHighlightsVisibility() is not getting called on the background thread > while the WebPageProxy is in the middle of destruction on the main thread? > Your call to makeRef(*this) here would try to ref the page even though its > destructor is running. Is there something I missed that makes sure this > cannot happen?
Right. Turns out this code is already thread unsafe. Fixing now with some weakptr and Function<>-foo
Brady Eidson
Comment 10
2021-07-02 09:26:14 PDT
Created
attachment 432803
[details]
Patch reviewed on Slack
EWS
Comment 11
2021-07-02 10:57:19 PDT
Committed
r279509
(
239361@main
): <
https://commits.webkit.org/239361@main
> All reviewed patches have been landed. Closing bug and clearing flags on
attachment 432803
[details]
.
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