RESOLVED FIXED 107319
Allow construction of unprefixed transition DOM events. 
https://bugs.webkit.org/show_bug.cgi?id=107319
Summary Allow construction of unprefixed transition DOM events.
Alexis Menard (darktears)
Reported 2013-01-18 13:24:22 PST
Allow construction of unprefixed transition DOM events.
Attachments
Patch (47.52 KB, patch)
2013-01-18 13:34 PST, Alexis Menard (darktears) 		no flags
DetailsFormatted DiffDiff
Patch (49.45 KB, patch)
2013-01-21 03:38 PST, Alexis Menard (darktears) 		no flags
DetailsFormatted DiffDiff
Patch (48.45 KB, patch)
2013-01-21 05:01 PST, Alexis Menard (darktears) 		no flags
DetailsFormatted DiffDiff
Patch (47.43 KB, patch)
2013-01-21 12:52 PST, Alexis Menard (darktears) 		no flags
DetailsFormatted DiffDiff
Show Obsolete (3) View All Add attachment proposed patch, testcase, etc.
Alexis Menard (darktears)
Comment 1 2013-01-18 13:34:07 PST
Created attachment 183535 [details] Patch
WebKit Review Bot
Comment 2 2013-01-18 13:56:09 PST
Comment on attachment 183535 [details] Patch Attachment 183535 [details] did not pass chromium-ews (chromium-xvfb): Output: http://queues.webkit.org/results/15941812
Build Bot
Comment 3 2013-01-18 14:30:16 PST
Comment on attachment 183535 [details] Patch Attachment 183535 [details] did not pass mac-wk2-ews (mac-wk2): Output: http://queues.webkit.org/results/15946592 New failing tests: fast/dom/constructed-objects-prototypes.html
Peter Beverloo (cr-android ews)
Comment 4 2013-01-18 15:41:15 PST
Comment on attachment 183535 [details] Patch Attachment 183535 [details] did not pass cr-android-ews (chromium-android): Output: http://queues.webkit.org/results/15939813
Build Bot
Comment 5 2013-01-18 17:45:53 PST
Comment on attachment 183535 [details] Patch Attachment 183535 [details] did not pass mac-ews (mac): Output: http://queues.webkit.org/results/15945750 New failing tests: fast/dom/constructed-objects-prototypes.html
Build Bot
Comment 6 2013-01-18 18:50:24 PST
Comment on attachment 183535 [details] Patch Attachment 183535 [details] did not pass mac-ews (mac): Output: http://queues.webkit.org/results/15942776 New failing tests: fast/dom/constructed-objects-prototypes.html
Alexis Menard (darktears)
Comment 7 2013-01-21 03:38:28 PST
Created attachment 183752 [details] Patch
WebKit Review Bot
Comment 8 2013-01-21 04:46:11 PST
Comment on attachment 183752 [details] Patch Attachment 183752 [details] did not pass chromium-ews (chromium-xvfb): Output: http://queues.webkit.org/results/15970989
Alexis Menard (darktears)
Comment 9 2013-01-21 05:01:58 PST
Created attachment 183761 [details] Patch
WebKit Review Bot
Comment 10 2013-01-21 06:37:34 PST
Comment on attachment 183761 [details] Patch Attachment 183761 [details] did not pass chromium-ews (chromium-xvfb): Output: http://queues.webkit.org/results/16038032 New failing tests: fast/events/event-creation.html
WebKit Review Bot
Comment 11 2013-01-21 07:35:32 PST
Comment on attachment 183761 [details] Patch Attachment 183761 [details] did not pass chromium-ews (chromium-xvfb): Output: http://queues.webkit.org/results/16011333 New failing tests: fast/events/event-creation.html inspector-protocol/debugger-terminate-dedicated-worker-while-paused.html
Alexis Menard (darktears)
Comment 12 2013-01-21 12:52:18 PST
Created attachment 183822 [details] Patch
Dean Jackson
Comment 13 2013-01-22 11:45:47 PST
Comment on attachment 183822 [details] Patch View in context: https://bugs.webkit.org/attachment.cgi?id=183822&action=review > Source/WebCore/ChangeLog:20 > + Make possible to construct unprefixed DOM events for transitions. > + Unfortunately I have to duplicate the C++ implementation class of the > + events (TransitionEvent.h and TransitionEvent.cpp). I can't find a > + better way to re-use the WebKitTransitionEvent class to back the > + TransitionEvent.idl as our code generators don't allow to have a > + different name for the C++ class used in the generated file than the > + interface name specified in the IDL file. Unfortunately > + https://trac.webkit.org/wiki/WebKitIDL#InterfaceName doesn't help as > + it's only a way to unlink the interface name specified in the IDL with > + the one exposed in JavaScript. I don't think we should support such a > + feature in our code generators as WebKitTransitionEvent class and more > + exactly prefixed DOM events for transitions will be removed one day so > + this use case will become obselete. I wonder if we should put a big message in the unprefixed implementation making it clear that any change should be done in both places (as unlikely as this is).
WebKit Review Bot
Comment 14 2013-01-22 12:09:05 PST
Comment on attachment 183822 [details] Patch Clearing flags on attachment: 183822 Committed r140448: <http://trac.webkit.org/changeset/140448>
WebKit Review Bot
Comment 15 2013-01-22 12:09:17 PST
All reviewed patches have been landed. Closing bug.
Alexis Menard (darktears)
Comment 16 2013-01-22 12:28:52 PST
(In reply to comment #13) > (From update of attachment 183822 [details]) > View in context: https://bugs.webkit.org/attachment.cgi?id=183822&action=review > > > Source/WebCore/ChangeLog:20 > > + Make possible to construct unprefixed DOM events for transitions. > > + Unfortunately I have to duplicate the C++ implementation class of the > > + events (TransitionEvent.h and TransitionEvent.cpp). I can't find a > > + better way to re-use the WebKitTransitionEvent class to back the > > + TransitionEvent.idl as our code generators don't allow to have a > > + different name for the C++ class used in the generated file than the > > + interface name specified in the IDL file. Unfortunately > > + https://trac.webkit.org/wiki/WebKitIDL#InterfaceName doesn't help as > > + it's only a way to unlink the interface name specified in the IDL with > > + the one exposed in JavaScript. I don't think we should support such a > > + feature in our code generators as WebKitTransitionEvent class and more > > + exactly prefixed DOM events for transitions will be removed one day so > > + this use case will become obselete. > > I wonder if we should put a big message in the unprefixed implementation making it clear that any change should be done in both places (as unlikely as this is). We still have the "pseudoElementArg of type DOMString" part of the event attributes which we do not implement. Ok it has an issue coming with it so I'm not sure if we will implement it one day.
Lucas Forschler
Comment 17 2019-02-06 09:18:29 PST
Mass move bugs into the DOM component.
Note You need to log in before you can comment on or make changes to this bug.