...and that is sad <rdar://problem/10787649>
Created attachment 125063 [details] Patch
My first idea was to cut short as soon as we load the data for the Worker. The problem is we expose the execution to the Inspector so I would bypass that. This patch is the lazy approach. I assume the null page is unlikely and I don't care about the cost of starting the Worker thread.
Comment on attachment 125063 [details] Patch What prevents the same for <script src="about:blank"> and for <a href="javascript:">?
(In reply to comment #3) > (From update of attachment 125063 [details]) > What prevents the same for <script src="about:blank"> and for <a href="javascript:">? The same kind of checks. E.g.: http://trac.webkit.org/browser/trunk/Source/WebCore/dom/ScriptElement.cpp#L270 I did not try <a href="javascript:"> but I assume it is the same.
The check you mention is not in ScriptController, it's higher on call stack. I'm not sure if it's semantically correct to return ScriptValue() when evaluating an empty string. Testing in JS console, eval("") returns undefined. Looking at original bug, it appears that UString::is8Bit() is wrong - string methods don't usually crash on null strings. Is this the only reason why it crashes?
(In reply to comment #5) > The check you mention is not in ScriptController, it's higher on call stack. I'm not sure if it's semantically correct to return ScriptValue() when evaluating an empty string. Testing in JS console, eval("") returns undefined. Note this is the _Worker_ScriptController. The return value is never used anywhere (see: https://bugs.webkit.org/show_bug.cgi?id=77587 ) I will have to update the patch before landing since 77587 is landed. As I said, I considered putting this higher in the stack, but it is harder to make a correct patch due to the inspector. > Looking at original bug, it appears that UString::is8Bit() is wrong - string methods don't usually crash on null strings. Is this the only reason why it crashes? This is the same behavior as String. I think I see your point, you think the interpreter should return undefined on a Null source? In that case I should make sure the JIT does the same and then remove all the null check higher in the stack.
> I think I see your point, you think the interpreter should return undefined on a Null source? In that case I should make sure the JIT does the same and then remove all the null check higher in the stack. Actually the JIT crashes in exactly the same way. It is just crashing on different timing (need 100ms instead of 10 for some reason). This is a regression.
I think the regression comes from r99812. Previously we were just calling characters() which return 0 on null String.
Created attachment 125192 [details] Patch
Committed r106600: <http://trac.webkit.org/changeset/106600>