Closed Bug 648573 Opened 13 years ago Closed 13 years ago

Implement touch event interfaces

Categories

(Core :: DOM: Events, defect)

defect
Not set
normal

Tracking

()

RESOLVED FIXED
mozilla6

People

(Reporter: smaug, Assigned: smaug)

References

Details

(Keywords: dev-doc-complete)

Attachments

(1 file, 3 obsolete files)

...this way Fennec could dispatch touch events.

Implementing the interfaces shouldn't take too much time,
but sending the events via DOMWindowUtils may need a bit more time.

All this should be pref'ed so that desktop Fx doesn't expose any of this
to web content.
The event targeting is not quite clear yet in the spec, but we can
tweak that in followup bugs.
Actually, would it be enough to implement just the event interfaces now,
and add the DOMWindowUtils part later?
Matt?
...basically, could Fennec call
var e = document.createEvent("TouchEvent");
e.initTouchEvent(...):
someTarget.dispatchEvent(e);
Yes, that would work for us.
Blocks: 544614
Hardware: x86 → All
Version: unspecified → Trunk
Hardware: All → x86
Summary: Implement touch event interfaces and add a method to DOMWindowUtils to dispatch such events → Implement touch event interfaces
Version: Trunk → unspecified
Attached patch without tests (obsolete) — Splinter Review
The patch is still missing support for onFoo event listeners.
New patch with that fixed and tests coming soon.
Attached patch updated (obsolete) — Splinter Review
Comment on attachment 525229 [details] [diff] [review]
updated

Matt, or anyone, feel free to try this.
Hopefully it even compiles.

I posted the patch to tryserver.
Attachment #525229 - Flags: feedback?(mbrubeck)
Jst, the patch has the changes to nsDOMClassInfo and nsScriptNameSpaceManager
to allow us to pref off interfaces. Do those changes look reasonable to you?
It is a bit ugly hack to add the mDisabled flag, but other options
would probably need quite a bit re-factoring.
I'll ask review for this once it has compiled/passed tests on tryserver.
Attachment #525229 - Flags: review?(jst)
Attached patch Unbitrotted (obsolete) — Splinter Review
Needed to unbit rot this for testing.
Blocks: 651984
Attached patch UnbitrottedSplinter Review
Attachment #525136 - Attachment is obsolete: true
Attachment #525229 - Attachment is obsolete: true
Attachment #526751 - Attachment is obsolete: true
Attachment #525229 - Flags: review?(jst)
Attachment #525229 - Flags: feedback?(mbrubeck)
Attachment #527736 - Flags: review?(jst)
Attachment #527736 - Flags: feedback?(mbrubeck)
Comment on attachment 527736 [details] [diff] [review]
Unbitrotted

I don't see any major problems here.  Note that I'm mostly looking only at the IDL interfaces, not the C++ code.  Here are some notes about things that should change in either the code or the spec:

In the Editor's Draft spec, we have removed the timeStamp attribute from the TouchPoint interface.

I think we should either rename createTouch to createTouchPoint, or rename TouchPoint to Touch.  I personally prefer the latter.  For spec discussion, see: http://www.w3.org/2010/webevents/track/issues/11

We should remove the pageX/pageY parameters from createTouch.  These should be set automatically, as they are in initMouseEvent.

We will soon add a relatedTarget attribute to the TouchEvent interface and initTouchEvent function: http://www.w3.org/2010/webevents/track/issues/10
Attachment #527736 - Flags: feedback?(mbrubeck) → feedback+
(In reply to comment #12) 
> In the Editor's Draft spec, we have removed the timeStamp attribute from the
> TouchPoint interface.
Will remove


> 
> I think we should either rename createTouch to createTouchPoint, or rename
> TouchPoint to Touch.  I personally prefer the latter.  For spec discussion,
> see: http://www.w3.org/2010/webevents/track/issues/11
Yeah, I think we just need to rename the interface


> 
> We should remove the pageX/pageY parameters from createTouch.  These should be
> set automatically, as they are in initMouseEvent.
Well, webkit's createTouch doesn't have clientX/Y but only pageX/Y and screenX/Y.
WebKit's implementation does not make any sense, but we may just have to do what they do.
What does Apple do?
I think I need to add automatic conversion from pageX/Y if clientX/Y are not passed as
parameters.

 
> We will soon add a relatedTarget attribute to the TouchEvent interface and
> initTouchEvent function: http://www.w3.org/2010/webevents/track/issues/10
I'm not 100% sure we want touchenter/leave because other touch events have different
event targeting (always the same target).
Again, IMHO, the special event targeting in touchup/down/move is just silly, but
that is what Apple and webkit do :(
(In reply to comment #13)

> > We should remove the pageX/pageY parameters from createTouch.  These should be
> > set automatically, as they are in initMouseEvent.

> Well, webkit's createTouch doesn't have clientX/Y but only pageX/Y and
> screenX/Y.
> WebKit's implementation does not make any sense, but we may just have to do
> what they do.
> What does Apple do?

I think it's okay to break compatibility with createTouch (and the other create/init functions).  As far as I can tell, these are really used only in tests, not in public content (except "if (document.createTouch) ..." for feature detection).

> > We will soon add a relatedTarget attribute to the TouchEvent interface and
> > initTouchEvent function: http://www.w3.org/2010/webevents/track/issues/10
> I'm not 100% sure we want touchenter/leave because other touch events have
> different event targeting (always the same target).

I agree that the enter/leave events are a bit weird, but they solve a use case that is not easy to solve otherwise.  I'm not sure the targeting difference is a strong enough reason to leave them out.
Comment on attachment 527736 [details] [diff] [review]
Unbitrotted

Review of attachment 527736 [details] [diff] [review]:

Looks good to me, r=jst

::: content/base/src/nsDocument.cpp
@@ +8433,5 @@
+      if (valueType == nsIDataType::VTYPE_INTERFACE ||
+          valueType == nsIDataType::VTYPE_INTERFACE_IS) {
+        nsISupports** values = static_cast<nsISupports**>(rawArray);
+        for (PRUint32 i = 0; i < valueCount; ++i) {
+          nsISupports* supports = values[i];

Maybe use an nsCOMPtr<nsISupports> here?
Attachment #527736 - Flags: review?(jst) → review+
Ah, yes,
nsCOMPtr<nsISupports> supports = dont_Addref(values[i]);
Matt, Wesley, I'm planning to push this without changes to interfaces
(except the removal of timestamp).
We can change the interfaces once they are defined/changed in the spec.
Touch event interfaces are disabled by default anyway.
http://hg.mozilla.org/mozilla-central/rev/2bf4a6a4b551
Status: NEW → RESOLVED
Closed: 13 years ago
Hardware: x86 → All
Resolution: --- → FIXED
Target Milestone: --- → mozilla6
Version: unspecified → Trunk
Depends on: 652814
Smaug, at <http://hg.mozilla.org/mozilla-central/rev/2bf4a6a4b551#l9.184>, don't you need to initialize aRetVal if you dan't have a point with the given identifier?
In practice no, but that is a good habit to do.
Fixing...
Added reference documentation. We need an example and other how-to information on the main en/DOM/Touch_events page still. Anyone have something they can contribute for that?

https://developer.mozilla.org/en/DOM/Touch_events

https://developer.mozilla.org/en/DOM/TouchEvent
https://developer.mozilla.org/en/DOM/TouchEvent.touches
https://developer.mozilla.org/en/DOM/TouchEvent.changedTouches
https://developer.mozilla.org/en/DOM/TouchEvent.targetTouches

https://developer.mozilla.org/en/DOM/DocumentTouch
https://developer.mozilla.org/en/DOM/DocumentTouch.createTouch
https://developer.mozilla.org/en/DOM/DocumentTouch.createTouchList

https://developer.mozilla.org/en/DOM/TouchList
https://developer.mozilla.org/en/DOM/TouchList.length
https://developer.mozilla.org/en/DOM/TouchList.identifiedTouch
https://developer.mozilla.org/en/DOM/TouchList.item

https://developer.mozilla.org/en/DOM/Touch
https://developer.mozilla.org/en/DOM/Touch.identifier
https://developer.mozilla.org/en/DOM/Touch.screenX
https://developer.mozilla.org/en/DOM/Touch.screenY
https://developer.mozilla.org/en/DOM/Touch.clientX
https://developer.mozilla.org/en/DOM/Touch.clientY
https://developer.mozilla.org/en/DOM/Touch.pageX
https://developer.mozilla.org/en/DOM/Touch.pageY
https://developer.mozilla.org/en/DOM/Touch.radiusX
https://developer.mozilla.org/en/DOM/Touch.radiusY
https://developer.mozilla.org/en/DOM/Touch.rotationAngle
https://developer.mozilla.org/en/DOM/Touch.force
I have added an example and how-to guide to:

https://developer.mozilla.org/en/DOM/Touch_events

Documentation is complete.
Thank you for your help. We have decided to postpone the Dev Derby competition focused around Touch because our mobile browser doesn't yet fully support it. We will feature this technology as soon as it becomes available. Thank you for your help and all this information you have gathered for us will be useful when we do decide to run this competition. 

Thank you!
Needed the docs anyway. I didn't realize Dev Derby was planning something around it. Heh.
You need to log in before you can comment on or make changes to this bug.