Bug 76124 - Consider removing WheelEvent's initWebKitWheelEvent
Summary: Consider removing WheelEvent's initWebKitWheelEvent
Status: RESOLVED DUPLICATE of bug 267813
Alias: None
Product: WebKit
Classification: Unclassified
Component: UI Events (show other bugs)
Version: 528+ (Nightly build)
Hardware: Unspecified Unspecified
: P2 Normal
Assignee: Nobody
URL:
Keywords:
Depends on: 76121
Blocks: 76198 76214
  Show dependency treegraph
 
Reported: 2012-01-11 16:48 PST by Eric Seidel (no email)
Modified: 2024-02-03 14:02 PST (History)
9 users (show)

See Also:


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description Eric Seidel (no email) 2012-01-11 16:48:23 PST
WheelEvent.initWebKitWheelEvent differs from DOM Events WheelEvent.initWheelEvent

http://www.w3.org/TR/DOM-Level-3-Events/#webidl-events-WheelEvent

We should come to the future!

This causes http://samples.msdn.microsoft.com/ietestcenter/domevents/WheelEvent.initWheelEvent.html to fail (now that bug 76121 is resolved).

Expected:

  void                               initWheelEvent(in DOMString typeArg, 
                                                    in boolean canBubbleArg, 
                                                    in boolean cancelableArg, 
                                                    in AbstractView viewArg, 
                                                    in long detailArg, 
                                                    in long screenXArg, 
                                                    in long screenYArg, 
                                                    in long clientXArg, 
                                                    in long clientYArg, 
                                                    in unsigned short buttonArg, 
                                                    in EventTarget relatedTargetArg, 
                                                    in DOMString modifiersListArg, 
                                                    in float deltaXArg, 
                                                    in float deltaYArg, 
                                                    in float deltaZArg, 
                                                    in unsigned long deltaMode);

Ours:

        void initWebKitWheelEvent(in [Optional=CallWithDefaultValue] long wheelDeltaX,
                                  in [Optional=CallWithDefaultValue] long wheelDeltaY, 
                                  in [Optional=CallWithDefaultValue] DOMWindow view, 
                                  in [Optional=CallWithDefaultValue] long screenX,
                                  in [Optional=CallWithDefaultValue] long screenY,
                                  in [Optional=CallWithDefaultValue] long clientX,
                                  in [Optional=CallWithDefaultValue] long clientY,
                                  in [Optional=CallWithDefaultValue] boolean ctrlKey,
                                  in [Optional=CallWithDefaultValue] boolean altKey,
                                  in [Optional=CallWithDefaultValue] boolean shiftKey,
                                  in [Optional=CallWithDefaultValue] boolean metaKey);
Comment 1 Alexey Proskuryakov 2012-01-12 11:52:10 PST
The usual reason for having the WebKit prefix is that we can keep deployed content working when spec changes incompatibly like this. Is there an overwhelming reason why WebKitWheelEvent should be modified instead of just adding WheelEvent when it's finally set in stone?
Comment 2 Eric Seidel (no email) 2012-01-12 12:17:14 PST
We're not required to modify initWebkitWheelEvent.  One can certainly keep it if desired.

It looks like http://www.w3.org/TR/DOM-Level-3-Events/#webidl-events-WheelEvent is last call.  So it seems to make sense to add the spec's version of initWheelEvent at this time, as this bug proposes.
Comment 3 Adam Barth 2012-01-12 12:18:36 PST
DOM3 events is somewhat controversial, but I don't think this aspect of it is controversial.  We should double-check the implementation in other browsers to make sure whatever we do is interoperable.
Comment 4 Ojan Vafai 2012-01-12 12:29:09 PST
(In reply to comment #3)
> DOM3 events is somewhat controversial, but I don't think this aspect of it is controversial.  We should double-check the implementation in other browsers to make sure whatever we do is interoperable.

We're removing init* methods from all specs and using constructors. So, I think this specific aspect is controversial. We should only implement this if we are required to for web compat, otherwise we should try to get the spec updated.
Comment 5 Adam Barth 2012-01-12 12:37:05 PST
The spec's version of WheelEvent is very different from our version:

http://dev.w3.org/2006/webapi/DOM-Level-3-Events/html/DOM3-Events.html#webidl-events-WheelEvent
http://trac.webkit.org/browser/trunk/Source/WebCore/dom/WheelEvent.idl

Whether we implement initWheelEvent or not, we should probably make our implementation match the spec more closely.
Comment 6 Kentaro Hara 2012-01-12 16:15:57 PST
I've proposed the spec of WheelEvent:
http://html5labs.interoperabilitybridges.com/dom4events/#constructors-wheelevent

I've been pinging the spec authors several times over months, but the spec is not yet defined...

> We're removing init* methods from all specs and using constructors. 

Yes. Also, implementing the WheelEvent constructor requires the MouseEvent constructor, and the MouseEvent constructor requires the UIEvent constructor. I'd like to implement them but all of these depend on the above spec...
Comment 7 Dominic Cooney 2012-01-12 17:13:10 PST
(In reply to comment #4)
> We're removing init* methods from all specs and using constructors. So, I think this specific aspect is controversial. We should only implement this if we are required to for web compat, otherwise we should try to get the spec updated.

I mentioned here <https://bugs.webkit.org/show_bug.cgi?id=68791#c14> that casual searching with Code Search indicated that initWheelEvent is used a lot. However we’re in an interesting place, since it obviously isn’t used in WebKit!

So if the question is one of browser parity compat, I think it makes sense to implement initWheelEvent. (I’m assuming other browsers implement the spec, though.) If the question is about not breaking existing web content, not implementing initWheelEvent makes sense.

In either case we should implement the DOM4 Events-style WheelEvent constructor.
Comment 8 Ojan Vafai 2012-01-13 19:12:09 PST
(In reply to comment #7)
> (In reply to comment #4)
> I mentioned here <https://bugs.webkit.org/show_bug.cgi?id=68791#c14> that casual searching with Code Search indicated that initWheelEvent is used a lot. However we’re in an interesting place, since it obviously isn’t used in WebKit!
> 
> So if the question is one of browser parity compat, I think it makes sense to implement initWheelEvent. (I’m assuming other browsers implement the spec, though.) If the question is about not breaking existing web content, not implementing initWheelEvent makes sense.

Ugh. That's a tough one. I'd be OK with us doing the following:
a) Figuring out what other browsers implement (not including modern IE).
b) Push back on the spec to have the minimally necessary API for initWheelEvent based off the compat needs of (a).
c) Implement that in WebKit.

> In either case we should implement the DOM4 Events-style WheelEvent constructor.

Yes. And since we don't have backwards compat concerns here, it would be better if we just used a single dictionary as the WheelEvent constructor argument instead of the long list initWheelEvent takes.

In either case, some spec needs to handle the WheelEvent constructor and figure out what is minimally necessary for initWheelEvent.
Comment 9 Ahmad Saleem 2022-12-30 19:49:40 PST
Blink removed the non-standard prefixed (WheelEvent.initWebKitWheelEvent) in following commit: https://chromium.googlesource.com/chromium/blink/+/4b74067338683dfc943c1fc4a67d37c741c4fe56

Do we need to track the differences? or we can rename this for removal of non-standard?
Comment 10 Ahmad Saleem 2024-02-03 14:02:10 PST

*** This bug has been marked as a duplicate of bug 267813 ***