Closed
Bug 648573
Opened 13 years ago
Closed 13 years ago
Implement touch event interfaces
Categories
(Core :: DOM: Events, defect)
Core
DOM: Events
Tracking
()
RESOLVED
FIXED
mozilla6
People
(Reporter: smaug, Assigned: smaug)
References
Details
(Keywords: dev-doc-complete)
Attachments
(1 file, 3 obsolete files)
65.48 KB,
patch
|
jst
:
review+
mbrubeck
:
feedback+
|
Details | Diff | Splinter Review |
...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.
Assignee | ||
Comment 1•13 years ago
|
||
The event targeting is not quite clear yet in the spec, but we can tweak that in followup bugs.
Assignee | ||
Comment 2•13 years ago
|
||
Actually, would it be enough to implement just the event interfaces now, and add the DOMWindowUtils part later? Matt?
Assignee | ||
Comment 3•13 years ago
|
||
...basically, could Fennec call var e = document.createEvent("TouchEvent"); e.initTouchEvent(...): someTarget.dispatchEvent(e);
Comment 4•13 years ago
|
||
Yes, that would work for us.
Assignee | ||
Updated•13 years ago
|
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
Assignee | ||
Comment 5•13 years ago
|
||
Assignee | ||
Comment 6•13 years ago
|
||
The patch is still missing support for onFoo event listeners. New patch with that fixed and tests coming soon.
Assignee | ||
Comment 7•13 years ago
|
||
Assignee | ||
Comment 8•13 years ago
|
||
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)
Assignee | ||
Comment 9•13 years ago
|
||
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.
Assignee | ||
Updated•13 years ago
|
Attachment #525229 -
Flags: review?(jst)
Comment 10•13 years ago
|
||
Needed to unbit rot this for testing.
Assignee | ||
Comment 11•13 years ago
|
||
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 12•13 years ago
|
||
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+
Assignee | ||
Comment 13•13 years ago
|
||
(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 :(
Comment 14•13 years ago
|
||
(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 15•13 years ago
|
||
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+
Assignee | ||
Comment 16•13 years ago
|
||
Ah, yes, nsCOMPtr<nsISupports> supports = dont_Addref(values[i]);
Assignee | ||
Comment 17•13 years ago
|
||
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.
Comment 18•13 years ago
|
||
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
Comment 19•13 years ago
|
||
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?
Assignee | ||
Comment 20•13 years ago
|
||
In practice no, but that is a good habit to do. Fixing...
Updated•13 years ago
|
Keywords: dev-doc-needed
Comment 22•13 years ago
|
||
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
Comment 23•13 years ago
|
||
I have added an example and how-to guide to: https://developer.mozilla.org/en/DOM/Touch_events Documentation is complete.
Keywords: dev-doc-needed → dev-doc-complete
Comment 24•13 years ago
|
||
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!
Comment 25•13 years ago
|
||
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.
Description
•