Instead of reimplementing "which node to scroll" for bug 461500, I'm trying to do something along the lines of.. aEvent.target.ownerDocument.defaultView. QI(Ci.nsIInterfaceRequestor).gI(Ci.nsIDOMWindowUtils). sendMouseScrollEvent("DOMMouseScroll", aEvent.clientX, aEvent.clientY, 0, 0, 100000 * aBottom ? 1 : -1, 0); where it'll send a scroll event with a big delta causing it to scroll the thing from under the cursor to the bottom/top. Right now clientX/screenX are null and layerX/pageX are 0.

Mardak, willing to test this? I don't have access to a Mac before Sunday evening. Passes those modified tests though.

Seems to work for me -- I can get the clientX, etc. values and now we don't need to set a fake .button attribute to 0 for the UIevent. On a somewhat unrelated note, at first I was testing it in a command/function doing.. dump([aEvent.clientX, aEvent.screenX, aEvent.pageX, aEvent.layerX, aEvent.target].join("\n")+"\n"); It would work the first time on a hovered element, but multiple swipes caused an exception: [Exception... "Component returned failure code: 0x80004005 (NS_ERROR_FAILURE) [nsIDOMLocation.host]" nsresult: "0x80004005 (NS_ERROR_FAILURE)" location: "JS frame :: chrome://browser/content/browser.js :: BrowserScroll :: line 8726" data: no] But if I broke these up into separate dump statements, it would always work fine. I'm assuming it's some bug with aEvent.target being [].join'ed and te nsIDOMLocation.host is being used eventually for.. [object XPCNativeWrapper [object HTMLHtmlElement @ 0x1cae6d50 (native @ 0x1d68a2f0)]]

Comment on attachment 362227 [details] [diff] [review] a-train-trip-patch This makes gesture events to extend mouse events. InitSimpleGestureEvent looks pretty terrible, but that is the way initXXX methods are usually created. The code removal in nsDOMEvent::DuplicatePrivateData is possible because isInputEvent is set to PR_TRUE, so the following is later executed: if (isInputEvent) { nsInputEvent* oldInputEvent = static_cast<nsInputEvent*>(mEvent); nsInputEvent* newInputEvent = static_cast<nsInputEvent*>(newEvent); newInputEvent->isShift = oldInputEvent->isShift; newInputEvent->isControl = oldInputEvent->isControl; newInputEvent->isAlt = oldInputEvent->isAlt; newInputEvent->isMeta = oldInputEvent->isMeta; } The patch includes also a minor fix to drag events' cycle collection.

Comment on attachment 362227 [details] [diff] [review] a-train-trip-patch Looks like this needs to land on 1.9.1 before wm_gesture support can ( Bug 479901).

Just for reference, this was pushed Tue Feb 17 2009 to m-c: http://hg.mozilla.org/mozilla-central/rev/4c6d799751ff

The original didn't apply cleanly to 1.9.1.

It probably didn't apply cleanly because it came after bug 471883. Any idea if the windows 7 gesture support needs events dispatched to the mouse instead of document?

(In reply to comment #7) > It probably didn't apply cleanly because it came after bug 471883. > Bug 471883's patch and this one don't seem to conflict. The wm_gesture stuff needed gesture events that extend mouse event, that's what really hosed things up. > Any idea if the windows 7 gesture support needs events dispatched to the mouse > instead of document? Document I believe, whatever m-c is currently doing. According to the comments in Bug 471883 it looks like that got updated with the patch in this bug.

Just finished up some testing. With this 1.9.1 patch and the 1.9.1 gesture patch in bug 479901 everything is working as expected on tablet pc.

Comment on attachment 371918 [details] [diff] [review] merged with mozilla-1.9.1 a191=beltzner, jimm tells me that this already has tests

pushed: http://hg.mozilla.org/releases/mozilla-1.9.1/rev/5f46fcb9e7ce

this was backed out temporarily due to test bustage. I'll reland once I get the merged patch through try.

landed: http://hg.mozilla.org/releases/mozilla-1.9.1/rev/65a895eba4c0