[webkit-reviews] review granted: [Bug 40934] Support <script defer> as specified by HTML5 : [Attachment 63029] Fix tab in ChangeLog

bugzilla-daemon at webkit.org bugzilla-daemon at webkit.org
Fri Jul 30 04:44:43 PDT 2010


Eric Seidel <eric at webkit.org> has granted Tony Gentilcore
<tonyg at chromium.org>'s request for review:
Bug 40934: Support <script defer> as specified by HTML5
https://bugs.webkit.org/show_bug.cgi?id=40934

Attachment 63029: Fix tab in ChangeLog
https://bugs.webkit.org/attachment.cgi?id=63029&action=review

------- Additional Comments from Eric Seidel <eric at webkit.org>
LayoutTests/fast/dom/HTMLScriptElement/defer-double-defer-write.html:14
 +	onbeforeload="doubleWrite(4)"
Why does this onbeforeload run at a different time than the one in the next
test?  This one seems to run after the 3, the next test it runs immediately? 
Is it racey?

LayoutTests/fast/dom/HTMLScriptElement/defer-double-write.html:14
 +	onbeforeload="doubleWrite(3)"
Here is the other onbeforeload your'e expecting to run at a different time than
the other one.	I'm not sure how tehse two tests are different.

Oh, I see, the first one uses a "double defer".  But I still wouldn't expect
the onbeforeload time to
change?LayoutTests/fast/dom/HTMLScriptElement/defer-inline-script.html:11
 +  <script defer>
Excellent.  This test coudl probably be simpler with just a little
document.write(). :)  The script-testing stuff is useful, but you don't really
seem to be uing it here. :)

LayoutTests/fast/dom/HTMLScriptElement/defer-onbeforeload.html:8
 +  Checks that deferred scripts fire onbeforeload immediately and that it is
cancellable.
This test seems to have conflicting expectations with teh first one...

LayoutTests/fast/dom/HTMLScriptElement/defer-onbeforeload.html:10
 +  <script src="resources/shouldnotexecute.js" onbeforeload="return false;"
defer></script>
Seems you'd want to log here, no?

LayoutTests/fast/dom/HTMLScriptElement/defer-script-invalid-url.html:10
 +  <script src="http://invalid:999999/" defer></script>
Do we need/want to check timing expectations of onerror?  That might be racey
though.

LayoutTests/fast/dom/HTMLScriptElement/resources/shouldnotexecute.js:1
 +  debug("should not execute");
Might put FAIL in there.

LayoutTests/http/tests/misc/resources/script-debug-body-background.js:1
 +  debug('Body background: ' +
getComputedStyle(document.body)['background-color']);
This should ideally contain the expectation in it.  Since you're using the
full-blown js-test-pre.js harness, you could use shouldBe here or
shouldBeEqualToString

LayoutTests/http/tests/misc/script-defer-write-slow-stylesheet.html:18
 +  <script
src="http://127.0.0.1:8000/misc/resources/script-write-slow-stylesheet.js"
defer="defer"></script>
So this is testing that writing a stylesheet from a defer script will delay
DOMContentLoaded, right?

WebCore/html/HTMLScriptRunner.cpp:251
 +	AtomicString srcValue = scriptElement->getAttribute(srcAttr);
const AtomicString& srcValue should be sufficient (and prevents one uneeded
ref).

WebCore/html/HTMLScriptRunner.cpp:257
 +	pendingScript.element = scriptElement;
Do we need to end up clearing this in the failure case?  I guess not, since we
weren't doing so before?

WebCore/html/HTMLScriptRunner.cpp:276
 +	if (madeRequest && !m_parsingBlockingScript.cachedScript()->isLoaded())

I think I would have made the m_parsingBlockingScript.cachedScript() dependance
explicit here:

if (madeRequest) {
    ASSERT(m_parsingBlockingScript.cachedScript());
    if (!m_parsingBlockingScript.cachedScript()->isLoaded())
	 watchForLoad(m_parsingBlockingScript);
}

Since requestScript can return w/o a cachedScript(), we should ASSERT that the
bool and cachedScript() always agree somewhere.

WebCore/html/HTMLScriptRunner.cpp:283
 +	bool madeRequest = requestScript(pendingScript, scriptElement);
This is a success bool, it seems.

I'm not sure the name "madeRequest" helps me here.  My first thought was "oh,
do I need to call it again?"

Maybe "requestSuccessfull"?  Or just throw it in the if block itself w/o a
local variable would be OK too.

(This is a nit, and not a big deal.)

In general this looks fine.  I think we could go one more round for nits.


More information about the webkit-reviews mailing list