WebKit Bugzilla
New
Browse
Log In
×
Sign in with GitHub
or
Remember my login
Create Account
·
Forgot Password
Forgotten password account recovery
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
Details
Formatted Diff
Diff
Patch
(14.53 KB, patch)
2016-09-07 21:27 PDT
,
Yusuke Suzuki
no flags
Details
Formatted Diff
Diff
Patch
(14.52 KB, patch)
2016-09-07 21:29 PDT
,
Yusuke Suzuki
no flags
Details
Formatted Diff
Diff
Patch
(13.95 KB, patch)
2016-09-07 22:38 PDT
,
Yusuke Suzuki
rniwa
: review+
Details
Formatted Diff
Diff
Show Obsolete
(3)
View All
Add attachment
proposed patch, testcase, etc.
Yusuke Suzuki
Comment 1
2016-09-07 21:24:22 PDT
Created
attachment 288241
[details]
Patch
Yusuke Suzuki
Comment 2
2016-09-07 21:27:42 PDT
Created
attachment 288242
[details]
Patch
Yusuke Suzuki
Comment 3
2016-09-07 21:29:51 PDT
Created
attachment 288244
[details]
Patch
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
Created
attachment 288251
[details]
Patch
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
Committed
r205652
: <
http://trac.webkit.org/changeset/205652
>
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
Committed
r205695
: <
http://trac.webkit.org/changeset/205695
>
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