WebKit Bugzilla
New
Browse
Log In
×
Sign in with GitHub
or
Remember my login
Create Account
·
Forgot Password
Forgotten password account recovery
RESOLVED FIXED
211589
Add missing null-check of page in ResourceLoader::loadDataURL
https://bugs.webkit.org/show_bug.cgi?id=211589
Summary
Add missing null-check of page in ResourceLoader::loadDataURL
Darin Adler
Reported
2020-05-07 12:10:26 PDT
Add missing null-check of page in ResourceLoader::loadDataURL
Attachments
Patch
(1.60 KB, patch)
2020-05-07 12:10 PDT
,
Darin Adler
no flags
Details
Formatted Diff
Diff
View All
Add attachment
proposed patch, testcase, etc.
Darin Adler
Comment 1
2020-05-07 12:10:55 PDT
Created
attachment 398774
[details]
Patch
Darin Adler
Comment 2
2020-05-07 12:11:23 PDT
rdar://57213601
Sam Weinig
Comment 3
2020-05-07 12:23:56 PDT
Comment on
attachment 398774
[details]
Patch View in context:
https://bugs.webkit.org/attachment.cgi?id=398774&action=review
> Source/WebCore/loader/ResourceLoader.cpp:274 > + if (auto page = m_frame->page()) { > + if (auto scheduledPairs = page->scheduledRunLoopPairs()) > + scheduleContext.scheduledPairs = *scheduledPairs; > + }
What's the effect to the rest of this function is page is null? When HAVE(RUNLOOP_TIMER) is enabled and you don't set scheduledPairs, does the call to DataURLDecoder::decode continue to work?
Darin Adler
Comment 4
2020-05-07 12:32:08 PDT
Comment on
attachment 398774
[details]
Patch View in context:
https://bugs.webkit.org/attachment.cgi?id=398774&action=review
>> Source/WebCore/loader/ResourceLoader.cpp:274 >> + } > > What's the effect to the rest of this function is page is null? When HAVE(RUNLOOP_TIMER) is enabled and you don't set scheduledPairs, does the call to DataURLDecoder::decode continue to work?
Three thoughts: 1) This mostly happens when scheduling a load during tear-down, and so I think the load never completes and gets torn down. 2) Another way to ask this is to ask what happens to all the scheduled stuff when the frame detaches from the page. 3) Is all of this for legacy WebKit on Cocoa platforms only?
Darin Adler
Comment 5
2020-05-07 12:45:03 PDT
I suspect the real answer is (1) above. This is just one of multiple ways to harmlessly do nothing. Could also return and do nothing harmlessly.
Darin Adler
Comment 6
2020-05-07 12:45:43 PDT
And test results seem to confirm that.
Alex Christensen
Comment 7
2020-05-07 21:51:45 PDT
(In reply to Darin Adler from
comment #4
)
> 3) Is all of this for legacy WebKit on Cocoa platforms only?
Yes. While we're at it, why don't we null check the frame? I see that null checked elsewhere in this file.
Darin Adler
Comment 8
2020-05-08 09:05:20 PDT
(In reply to Alex Christensen from
comment #7
)
> While we're at it, why don't we null check the frame? I see that null > checked elsewhere in this file.
Seems fine to do that. Good to do it more consistently.
Darin Adler
Comment 9
2020-05-09 06:36:16 PDT
(In reply to Darin Adler from
comment #8
)
> Seems fine to do that. Good to do it more consistently.
But can I do that in a separate patch?
EWS
Comment 10
2020-05-09 09:07:53 PDT
Committed
r261438
: <
https://trac.webkit.org/changeset/261438
> All reviewed patches have been landed. Closing bug and clearing flags on
attachment 398774
[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