Bug 159550 - Make custom constructors consistent with generated bindings code
Summary: Make custom constructors consistent with generated bindings code
Status: RESOLVED FIXED
Alias: None
Product: WebKit
Classification: Unclassified
Component: WebCore Misc. (show other bugs)
Version: WebKit Nightly Build
Hardware: Unspecified Unspecified
: P2 Normal
Assignee: Nael Ouedraogo
URL:
Keywords:
Depends on:
Blocks:
 
Reported: 2016-07-08 02:37 PDT by Nael Ouedraogo
Modified: 2016-08-26 01:05 PDT (History)
2 users (show)

See Also:


Attachments
Patch (50.13 KB, patch)
2016-07-11 06:11 PDT, Nael Ouedraogo
no flags Details | Formatted Diff | Diff
WIP (49.71 KB, patch)
2016-07-13 02:39 PDT, Nael Ouedraogo
no flags Details | Formatted Diff | Diff
Patch (49.73 KB, patch)
2016-07-13 03:46 PDT, Nael Ouedraogo
no flags Details | Formatted Diff | Diff
Patch (49.73 KB, patch)
2016-07-13 05:14 PDT, Nael Ouedraogo
no flags Details | Formatted Diff | Diff
Patch (50.35 KB, patch)
2016-07-13 10:39 PDT, Nael Ouedraogo
no flags Details | Formatted Diff | Diff
Archive of layout-test-results from ews116 for mac-yosemite (1.45 MB, application/zip)
2016-07-13 11:49 PDT, Build Bot
no flags Details
Patch (50.35 KB, patch)
2016-07-20 08:51 PDT, Nael Ouedraogo
no flags Details | Formatted Diff | Diff
Patch (53.26 KB, patch)
2016-08-24 09:52 PDT, Nael Ouedraogo
no flags Details | Formatted Diff | Diff

Note You need to log in before you can comment on or make changes to this bug.
Description Nael Ouedraogo 2016-07-08 02:37:32 PDT
Make custom constructors consistent with generated bindings code. In particular, error messages used in case of argument error are different.
Comment 1 Nael Ouedraogo 2016-07-11 06:11:46 PDT
Created attachment 283312 [details]
Patch
Comment 2 youenn fablet 2016-07-12 06:54:40 PDT
Comment on attachment 283312 [details]
Patch

This seems pretty good.
Some comments below.

View in context: https://bugs.webkit.org/attachment.cgi?id=283312&action=review

> Source/WebCore/bindings/js/JSBlobCustom.cpp:71
> +    if (!is<Document>(context) && !is<WorkerGlobalScope>(context))

I think you can keep "if(!context)" since that should be equivalent.

> Source/WebCore/bindings/js/JSDOMBinding.cpp:824
> +JSC::EncodedJSValue throwConstructorExecutionContextUnavailableError(JSC::ExecState& state, const char* interfaceName)

I know it is a bit long but then we should use ScriptExecutionContext and not ExecutionContext.

> Source/WebCore/bindings/js/JSFileCustom.cpp:52
> +        return throwConstructorExecutionContextUnavailableError(exec, "File");

I think the generator is doing something like:
if(!context)
    throw
ASSERT(context.isDocument())

File is not supposed to be exposed to workers, so if context is not a Document, we are probably in serious trouble and we should assert.

> Source/WebCore/bindings/js/JSHTMLElementCustom.cpp:48
> +        return throwConstructorExecutionContextUnavailableError(exec, "HTMLElement");

Ditto here
Comment 3 Nael Ouedraogo 2016-07-12 23:04:30 PDT
> I know it is a bit long but then we should use ScriptExecutionContext and
> not ExecutionContext.
Thanks for the review. Ok, I will fix this a new patch.

> > Source/WebCore/bindings/js/JSFileCustom.cpp:52
> > +        return throwConstructorExecutionContextUnavailableError(exec, "File");
> 
> I think the generator is doing something like:
> if(!context)
>     throw
> ASSERT(context.isDocument())
> 
> File is not supposed to be exposed to workers, so if context is not a
> Document, we are probably in serious trouble and we should assert.
It seems that a ReferenceError should be thrown when File is evaluated in a global scope of a worker as per specification (c.f. example section of http://heycam.github.io/webidl/#Exposed). This behavior seems only described in this example section so maybe there is no strong requirement to throw. Wdyt?
Comment 4 youenn fablet 2016-07-12 23:23:19 PDT
> > File is not supposed to be exposed to workers, so if context is not a
> > Document, we are probably in serious trouble and we should assert.
> It seems that a ReferenceError should be thrown when File is evaluated in a
> global scope of a worker as per specification (c.f. example section of
> http://heycam.github.io/webidl/#Exposed). This behavior seems only described
> in this example section so maybe there is no strong requirement to throw.
> Wdyt?

Right, but this should probably be handled above.
If we are executing constructJSFile, we know that "File" is defined in this scope and therefore we must be in a window scope.
Comment 5 Nael Ouedraogo 2016-07-13 02:39:42 PDT
Created attachment 283498 [details]
WIP
Comment 6 Nael Ouedraogo 2016-07-13 02:49:23 PDT
> Right, but this should probably be handled above.
> If we are executing constructJSFile, we know that "File" is defined in this
> scope and therefore we must be in a window scope.

OK I understand. Thanks. I uploaded a new patch with new assertions when context is not a Document and renamed throwConstructorExecutionContextUnavailableError.
Comment 7 youenn fablet 2016-07-13 02:56:37 PDT
Comment on attachment 283498 [details]
WIP

View in context: https://bugs.webkit.org/attachment.cgi?id=283498&action=review

> Source/WebCore/bindings/js/JSAudioContextCustom.cpp:53
> +    if (!is<Document>(scriptExecutionContext))

Here also, you might want to keep if (!scriptExecutionContext) and add an ASSERT
Comment 8 Nael Ouedraogo 2016-07-13 03:46:06 PDT
Created attachment 283506 [details]
Patch
Comment 9 Nael Ouedraogo 2016-07-13 05:14:18 PDT
Created attachment 283518 [details]
Patch
Comment 10 Nael Ouedraogo 2016-07-13 10:39:04 PDT
Created attachment 283542 [details]
Patch
Comment 11 Build Bot 2016-07-13 11:49:38 PDT
Comment on attachment 283542 [details]
Patch

Attachment 283542 [details] did not pass mac-debug-ews (mac):
Output: http://webkit-queues.webkit.org/results/1675344

New failing tests:
storage/indexeddb/modern/blob-simple-workers.html
http/tests/websocket/tests/hybi/workers/send-blob.html
fast/files/workers/worker-read-blob-async.html
imported/w3c/web-platform-tests/fetch/api/basic/scheme-blob-worker.html
fast/files/workers/worker-read-blob-sync.html
Comment 12 Build Bot 2016-07-13 11:49:40 PDT
Created attachment 283554 [details]
Archive of layout-test-results from ews116 for mac-yosemite

The attached test failures were seen while running run-webkit-tests on the mac-debug-ews.
Bot: ews116  Port: mac-yosemite  Platform: Mac OS X 10.10.5
Comment 13 Nael Ouedraogo 2016-07-20 08:51:47 PDT
Created attachment 284107 [details]
Patch
Comment 14 Nael Ouedraogo 2016-08-24 09:52:59 PDT
Created attachment 286857 [details]
Patch
Comment 15 youenn fablet 2016-08-25 08:40:22 PDT
r=me
Comment 16 WebKit Commit Bot 2016-08-26 01:05:48 PDT
Comment on attachment 286857 [details]
Patch

Clearing flags on attachment: 286857

Committed r205008: <http://trac.webkit.org/changeset/205008>
Comment 17 WebKit Commit Bot 2016-08-26 01:05:52 PDT
All reviewed patches have been landed.  Closing bug.