Bug 117183

Summary: Automatically generate WorkerContext constructor attributes
Product: WebKit Reporter: Chris Dumez <cdumez>
Component: BindingsAssignee: Chris Dumez <cdumez>
Status: RESOLVED FIXED    
Severity: Normal CC: arv, benjamin, commit-queue, darin, dpranke, esprehn+autocc, ggaren, glenn, gyuyoung.kim, haraken, laszlo.gombos, rakuco, rniwa, zan
Priority: P2    
Version: 528+ (Nightly build)   
Hardware: Unspecified   
OS: Unspecified   
Bug Depends on:    
Bug Blocks: 115853    
Attachments:
Description Flags
Patch
buildbot: commit-queue-
Patch
haraken: review+
Patch none

Chris Dumez
Reported 2013-06-04 01:03:41 PDT
The bindings generator are currently able to generate constructor attributes on the Window object but not yet on the WorkerContext. This should be addressed.
Attachments
Patch (30.23 KB, patch)
2013-06-04 02:28 PDT, Chris Dumez
buildbot: commit-queue-
Patch (30.20 KB, patch)
2013-06-04 03:51 PDT, Chris Dumez
haraken: review+
Patch (32.91 KB, patch)
2013-06-04 06:57 PDT, Chris Dumez
no flags
Chris Dumez
Comment 1 2013-06-04 02:28:16 PDT
Kentaro Hara
Comment 2 2013-06-04 02:33:06 PDT
(I know I shouldn't say this after you implemented the patch but) another idea might be: - Keep [NoInterfaceObject] as is, since it's a speced IDL attribute. - Add [InterfaceObjectOnWorker], which indicates that the interface should be exposed on WorkerContext.
Build Bot
Comment 3 2013-06-04 03:08:58 PDT
Chris Dumez
Comment 4 2013-06-04 03:35:38 PDT
(In reply to comment #2) > (I know I shouldn't say this after you implemented the patch but) another idea might be: > > - Keep [NoInterfaceObject] as is, since it's a speced IDL attribute. > - Add [InterfaceObjectOnWorker], which indicates that the interface should be exposed on WorkerContext. I don't fully understand your comment. I kept [NoInterfaceObject] as is already. I merely introduced a new global extended attribute called [GlobalContext]. The approach you propose is fairly similar despite the extended attribute name being different. The issue is how do you indicate that a constructor should be generated the WindowOnly, or on the WorkerContext only? Note, for example, that according to specification FileReaderSync does not have [NoInterfaceObject]: http://dev.w3.org/2006/webapi/FileAPI/#FileReaderSync However, the spec clearly states: "In environments where the global object is represented by a WorkerGlobalScope object, the FileReaderSync constructor must be available." -> http://dev.w3.org/2006/webapi/FileAPI/#filereadersyncConstrctr The Web IDL spec (http://dev.w3.org/2006/webapi/WebIDL/#es-interfaces) says: " For every interface that: - is a callback interface that has constants declared on it, or - is a non-callback interface that is not declared with the [NoInterfaceObject] extended attribute, a corresponding property must exist on the ECMAScript global object. The name of the property is the identifier of the interface, and its value is an object called the interface object. " The global object may be a Window or a WorkerContext depending on the environment. Currently, this is only defined in prose in the specs. This is the reason why I proposed to introduce [GlobalContext] extended attribute to indicate on which global context the constructor should be exposed.
Kentaro Hara
Comment 5 2013-06-04 03:41:58 PDT
ah, sorry! I was misunderstanding the patch. You approach completely looks reasonable.
Chris Dumez
Comment 6 2013-06-04 03:51:34 PDT
Created attachment 203674 [details] Patch Should fix win-ews.
Kentaro Hara
Comment 7 2013-06-04 03:53:15 PDT
Comment on attachment 203674 [details] Patch Looks reasonable.
Chris Dumez
Comment 8 2013-06-04 04:10:27 PDT
FYI, I am porting this to Blink as well (but in Python).
Kentaro Hara
Comment 9 2013-06-04 04:24:56 PDT
(In reply to comment #8) > FYI, I am porting this to Blink as well (but in Python). Two engineers are working on the rewrite, but it will take time to switch to Python. Please feel free to make changes to the current Perl scripts.
Chris Dumez
Comment 10 2013-06-04 04:26:30 PDT
(In reply to comment #9) > (In reply to comment #8) > > FYI, I am porting this to Blink as well (but in Python). > > Two engineers are working on the rewrite, but it will take time to switch to Python. Please feel free to make changes to the current Perl scripts. The preprocess-idls script was already rewritten in Python in Blink. This is the only script I edited.
Chris Dumez
Comment 11 2013-06-04 06:51:53 PDT
Comment on attachment 203674 [details] Patch Seems I broke the bindings tests.
Chris Dumez
Comment 12 2013-06-04 06:57:41 PDT
Created attachment 203691 [details] Patch Fixed bindings tests by passing new --workerContextConstructorsFile argument to preprocess-idls.pl script. Kentaro, would you mind taking another look please?
Kentaro Hara
Comment 13 2013-06-04 06:59:13 PDT
Comment on attachment 203691 [details] Patch LGTM
WebKit Commit Bot
Comment 14 2013-06-04 07:17:50 PDT
Comment on attachment 203691 [details] Patch Clearing flags on attachment: 203691 Committed r151169: <http://trac.webkit.org/changeset/151169>
WebKit Commit Bot
Comment 15 2013-06-04 07:17:55 PDT
All reviewed patches have been landed. Closing bug.
Chris Dumez
Comment 16 2013-06-04 08:23:44 PDT
Note You need to log in before you can comment on or make changes to this bug.