WebKit Bugzilla
New
Browse
Log In
×
Sign in with GitHub
or
Remember my login
Create Account
·
Forgot Password
Forgotten password account recovery
RESOLVED FIXED
Bug 117183
Automatically generate WorkerContext constructor attributes
https://bugs.webkit.org/show_bug.cgi?id=117183
Summary
Automatically generate WorkerContext constructor attributes
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-
Details
Formatted Diff
Diff
Patch
(30.20 KB, patch)
2013-06-04 03:51 PDT
,
Chris Dumez
haraken
: review+
Details
Formatted Diff
Diff
Patch
(32.91 KB, patch)
2013-06-04 06:57 PDT
,
Chris Dumez
no flags
Details
Formatted Diff
Diff
Show Obsolete
(2)
View All
Add attachment
proposed patch, testcase, etc.
Chris Dumez
Comment 1
2013-06-04 02:28:16 PDT
Created
attachment 203667
[details]
Patch
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
Comment on
attachment 203667
[details]
Patch
Attachment 203667
[details]
did not pass win-ews (win): Output:
http://webkit-queues.appspot.com/results/775053
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
I updated the WebKit IDL wiki accordingly:
https://trac.webkit.org/wiki/WebKitIDL?action=diff&version=120&old_version=119
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