RESOLVED FIXED 187565
Add a FrameLoaderClient willInjectUserScriptForFrame callback
https://bugs.webkit.org/show_bug.cgi?id=187565
Summary Add a FrameLoaderClient willInjectUserScriptForFrame callback
youenn fablet
Reported 2018-07-11 14:52:38 PDT
Add a FrameLoaderClient willInjectUserScriptForFrame callback
Attachments
WIP (16.53 KB, patch)
2018-07-11 15:02 PDT, youenn fablet
no flags
Patch (31.49 KB, patch)
2018-07-11 16:30 PDT, youenn fablet
no flags
Rebasing (31.35 KB, patch)
2018-07-12 13:12 PDT, youenn fablet
no flags
youenn fablet
Comment 1 2018-07-11 15:02:20 PDT
youenn fablet
Comment 2 2018-07-11 16:30:36 PDT
EWS Watchlist
Comment 3 2018-07-11 16:33:52 PDT
Attachment 344786 [details] did not pass style-queue: ERROR: Source/WebCore/loader/FrameLoaderClient.h:335: Inline functions should not be in classes annotated with WEBCORE_EXPORT. Remove the macro from the class and apply it to each appropriate method, or move the inline function definition out-of-line. [build/webcore_export] [4] Total errors found: 1 in 25 files If any of these errors are false positives, please file a bug against check-webkit-style.
Radar WebKit Bug Importer
Comment 4 2018-07-11 16:40:48 PDT
Sam Weinig
Comment 5 2018-07-11 18:02:56 PDT
What's the use case for this new API callback?
youenn fablet
Comment 6 2018-07-11 18:14:48 PDT
(In reply to Sam Weinig from comment #5) > What's the use case for this new API callback? Apps on top of WebKit can currently rely on globalObjectIsAvailableForFrame to properly initialize worlds. globalObjectIsAvailableForFrame is called at the time of receiving the first page byte. This works well if the world is created before that, it fails otherwise and may lead to executing scripts in worlds that are not properly set up. This new callback allows to properly set up worlds just before executing a user script.
Brian Weinstein
Comment 7 2018-07-12 10:17:49 PDT
It looks like this doesn’t apply cleanly after https://trac.webkit.org/changeset/233752/webkit.
youenn fablet
Comment 8 2018-07-12 10:23:58 PDT
(In reply to Brian Weinstein from comment #7) > It looks like this doesn’t apply cleanly after > https://trac.webkit.org/changeset/233752/webkit. Yep, the call to this->loader().client().willInjectUserScript(world); probably needs to be rebased.
Brian Weinstein
Comment 9 2018-07-12 10:25:29 PDT
(In reply to youenn fablet from comment #8) > (In reply to Brian Weinstein from comment #7) > > It looks like this doesn’t apply cleanly after > > https://trac.webkit.org/changeset/233752/webkit. > > Yep, the call to this->loader().client().willInjectUserScript(world); > probably needs to be rebased. It should go in Frame::injectUserScriptImmediately, correct? Just for my testing, I have: void Frame::injectUserScriptImmediately(DOMWrapperWorld& world, const UserScript& script) { auto* document = this->document(); if (!document) return; if (script.injectedFrames() == InjectInTopFrameOnly && !isMainFrame()) return; if (!UserContentURLPattern::matchesPatterns(document->url(), script.whitelist(), script.blacklist())) return; if (m_page) m_page->setAsRunningUserScripts(); this->loader().client().willInjectUserScript(world); m_script->evaluateInWorld(ScriptSourceCode(script.source(), script.url()), world); }
youenn fablet
Comment 10 2018-07-12 11:02:24 PDT
Yes, I ll reupload a new version shortly after linch
Alex Christensen
Comment 11 2018-07-12 11:23:45 PDT
(In reply to Sam Weinig from comment #5) > What's the use case for this new API callback? We are currently using globalObjectIsAvailableForFrame to set up things if we have a user script, but if we don't have a user script then use _addUserScriptImmediately (introduced in r233752) then things won't be set up when a user script is injected. Moving the setup to this new callback fixes the problem without compatibility issues.
youenn fablet
Comment 12 2018-07-12 13:12:47 PDT
Created attachment 344874 [details] Rebasing
EWS Watchlist
Comment 13 2018-07-12 13:15:09 PDT
Attachment 344874 [details] did not pass style-queue: ERROR: Source/WebCore/loader/FrameLoaderClient.h:335: Inline functions should not be in classes annotated with WEBCORE_EXPORT. Remove the macro from the class and apply it to each appropriate method, or move the inline function definition out-of-line. [build/webcore_export] [4] Total errors found: 1 in 25 files If any of these errors are false positives, please file a bug against check-webkit-style.
WebKit Commit Bot
Comment 14 2018-07-12 14:34:43 PDT
Comment on attachment 344874 [details] Rebasing Clearing flags on attachment: 344874 Committed r233782: <https://trac.webkit.org/changeset/233782>
WebKit Commit Bot
Comment 15 2018-07-12 14:34:45 PDT
All reviewed patches have been landed. Closing bug.
youenn fablet
Comment 17 2018-07-13 08:45:03 PDT
Thanks truitt, I’ll look at it today
Chris Dumez
Comment 18 2018-07-13 09:19:38 PDT
Note You need to log in before you can comment on or make changes to this bug.