RESOLVED FIXED 161726
ScriptRunner should be driven by PendingScript rather than ScriptElement
https://bugs.webkit.org/show_bug.cgi?id=161726
Summary ScriptRunner should be driven by PendingScript rather than ScriptElement
Yusuke Suzuki
Reported 2016-09-07 17:51:43 PDT
ScriptElement::notifyFinished is only used when the script tag has defer / async. It is tricky. We should use PendingScript's setClient,clearClient and drive ScriptRunner by itself (as the same to HTMLScriptRunner).
Attachments
Patch (14.37 KB, patch)
2016-09-07 21:24 PDT, Yusuke Suzuki
no flags
Patch (14.53 KB, patch)
2016-09-07 21:27 PDT, Yusuke Suzuki
no flags
Patch (14.52 KB, patch)
2016-09-07 21:29 PDT, Yusuke Suzuki
no flags
Patch (13.95 KB, patch)
2016-09-07 22:38 PDT, Yusuke Suzuki
rniwa: review+
Yusuke Suzuki
Comment 1 2016-09-07 21:24:22 PDT
Yusuke Suzuki
Comment 2 2016-09-07 21:27:42 PDT
Yusuke Suzuki
Comment 3 2016-09-07 21:29:51 PDT
Yusuke Suzuki
Comment 4 2016-09-07 21:40:07 PDT
ah, i'll apply the slight change. before calling clearClient, check whether it is watches.
Ryosuke Niwa
Comment 5 2016-09-07 22:35:30 PDT
(In reply to comment #4) > ah, i'll apply the slight change. > before calling clearClient, check whether it is watches. Do you want to upload a new patch before I review it?
Yusuke Suzuki
Comment 6 2016-09-07 22:38:14 PDT
Yusuke Suzuki
Comment 7 2016-09-07 22:44:06 PDT
(In reply to comment #5) > (In reply to comment #4) > > ah, i'll apply the slight change. > > before calling clearClient, check whether it is watches. > > Do you want to upload a new patch before I review it? I've just uploaded the patch :D! Now, ready for your review, thanks!
Ryosuke Niwa
Comment 8 2016-09-08 00:00:38 PDT
Comment on attachment 288251 [details] Patch View in context: https://bugs.webkit.org/attachment.cgi?id=288251&action=review r=me assuming you revert the change for IgnoreDestructiveWriteCountIncrementer in executeScriptForScriptRunner or explain why that's correct. > Source/WebCore/dom/ScriptElement.cpp:-370 > - IgnoreDestructiveWriteCountIncrementer ignoreDestructiveWriteCountIncrementer(&m_element.document()); I don't think this is correct because we're dispatching load event in this function. We need the counter to be non-zero while dispatching that event.
Yusuke Suzuki
Comment 9 2016-09-08 00:15:37 PDT
Comment on attachment 288251 [details] Patch View in context: https://bugs.webkit.org/attachment.cgi?id=288251&action=review Thanks! I'll add the test to ensure the change. >> Source/WebCore/dom/ScriptElement.cpp:-370 >> - IgnoreDestructiveWriteCountIncrementer ignoreDestructiveWriteCountIncrementer(&m_element.document()); > > I don't think this is correct because we're dispatching load event in this function. > We need the counter to be non-zero while dispatching that event. Nice catch!!! According to the spec[1], when firing the load event / the error event, this count should be already decremented. So, the old behavior was incorrect. We should have the test to ensure that, thanks! [1]: https://html.spec.whatwg.org/multipage/scripting.html#script-processing-model
Yusuke Suzuki
Comment 10 2016-09-08 00:34:28 PDT
Comment on attachment 288251 [details] Patch View in context: https://bugs.webkit.org/attachment.cgi?id=288251&action=review >>> Source/WebCore/dom/ScriptElement.cpp:-370 >>> - IgnoreDestructiveWriteCountIncrementer ignoreDestructiveWriteCountIncrementer(&m_element.document()); >> >> I don't think this is correct because we're dispatching load event in this function. >> We need the counter to be non-zero while dispatching that event. > > Nice catch!!! > According to the spec[1], when firing the load event / the error event, this count should be already decremented. > So, the old behavior was incorrect. We should have the test to ensure that, thanks! > > [1]: https://html.spec.whatwg.org/multipage/scripting.html#script-processing-model Correct link is this. https://html.spec.whatwg.org/multipage/scripting.html#execute-the-script-block
Yusuke Suzuki
Comment 11 2016-09-08 10:51:45 PDT
WebKit Commit Bot
Comment 12 2016-09-08 11:46:32 PDT
Re-opened since this is blocked by bug 161748
Yusuke Suzuki
Comment 13 2016-09-08 22:17:42 PDT
ASan crash was due to the bug in HashTable, not related to this patch. Now, the fix is landed in r205694. Let's re-land it as is.
Yusuke Suzuki
Comment 14 2016-09-08 22:22:20 PDT
Note You need to log in before you can comment on or make changes to this bug.