WebKit Bugzilla
New
Browse
Log In
×
Sign in with GitHub
or
Remember my login
Create Account
·
Forgot Password
Forgotten password account recovery
RESOLVED FIXED
Bug 194823
Always call CompletionHandlers after
r240909
https://bugs.webkit.org/show_bug.cgi?id=194823
Summary
Always call CompletionHandlers after r240909
Alex Christensen
Reported
2019-02-19 11:40:39 PST
Always call CompletionHandlers after
r240909
Attachments
Patch
(1.73 KB, patch)
2019-02-19 11:40 PST
,
Alex Christensen
no flags
Details
Formatted Diff
Diff
Patch
(1.73 KB, patch)
2019-02-19 12:57 PST
,
Alex Christensen
no flags
Details
Formatted Diff
Diff
Show Obsolete
(1)
View All
Add attachment
proposed patch, testcase, etc.
Alex Christensen
Comment 1
2019-02-19 11:40:59 PST
Created
attachment 362404
[details]
Patch
Ryosuke Niwa
Comment 2
2019-02-19 12:23:27 PST
Looks like the patch isn't building??
Alex Christensen
Comment 3
2019-02-19 12:57:20 PST
Created
attachment 362417
[details]
Patch
Ryosuke Niwa
Comment 4
2019-02-19 13:48:12 PST
Comment on
attachment 362417
[details]
Patch View in context:
https://bugs.webkit.org/attachment.cgi?id=362417&action=review
> Source/WebCore/loader/PolicyChecker.cpp:196 > if (!responseIdentifier.isValidFor(requestIdentifier)) > - return; > + return function({ }, nullptr, NavigationPolicyDecision::IgnoreLoad);
I don't think this is quite right. When the response identifier is less than what we have, it means the response was for some other resource we had requested a policy check in the past. Itβs still possible to receive the right policy check response in the future.
Alex Christensen
Comment 5
2019-02-19 14:18:23 PST
We definitely need to do something with the CompletionHandlers. If we don't call them we need to store them somewhere.
Ryosuke Niwa
Comment 6
2019-02-19 19:01:50 PST
(In reply to Alex Christensen from
comment #5
)
> We definitely need to do something with the CompletionHandlers. If we don't > call them we need to store them somewhere.
Oh, that's a good point. Maybe we DO need to fail in this case because we don't store the completion handler anywhere.
Ryosuke Niwa
Comment 7
2019-02-19 19:02:55 PST
But hang on, if we did that, wouldn't it mean that WebKit layer's listener map would still contain a stale completion handler which would never get called anyway?
Alex Christensen
Comment 8
2019-02-20 10:17:38 PST
No
Ryosuke Niwa
Comment 9
2019-02-20 13:35:38 PST
(In reply to Alex Christensen from
comment #8
)
> No
Why not? If we've reached this point, it means that we've got listenerID confused, and invoked the wrong listener with a policy check response. That would mean that the other listener for which this policy check response was really meant for would be left in the map. How does the other listener ever get a policy check response?
Alex Christensen
Comment 10
2019-02-20 14:05:04 PST
listenerID corresponds to WebFrame's m_policyFunction, and if they don't line up then WebFrame::invalidatePolicyListener calls the CompletionHandler owned by the WebFrame in that case. The CompletionHandlers being fixed by this patch are not owned by anything. They need to be called or owned.
Ryosuke Niwa
Comment 11
2019-02-20 14:07:29 PST
(In reply to Alex Christensen from
comment #10
)
> listenerID corresponds to WebFrame's m_policyFunction, and if they don't > line up then WebFrame::invalidatePolicyListener calls the CompletionHandler > owned by the WebFrame in that case.
Oh, that's a good point.
WebKit Commit Bot
Comment 12
2019-02-20 14:52:24 PST
Comment on
attachment 362417
[details]
Patch Clearing flags on attachment: 362417 Committed
r241842
: <
https://trac.webkit.org/changeset/241842
>
WebKit Commit Bot
Comment 13
2019-02-20 14:52:25 PST
All reviewed patches have been landed. Closing bug.
Radar WebKit Bug Importer
Comment 14
2019-02-20 14:59:53 PST
<
rdar://problem/48253351
>
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