477863 - Give gesture events usable clientX/screenX values

Status: RESOLVED FIXED

(Core :: DOM: UI Events & Focus Handling, defect)

Description

[Ed Lee :Mardak]

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.

Comment 1

[Olli Pettay [:smaug][[e-mail]]]

Attachment: a-train-trip-patch

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

Comment 2

[Ed Lee :Mardak]

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 3

[Olli Pettay [:smaug][[e-mail]]]

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 4

[Jim Mathies [:jimm]]

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).

Comment 5

[Jim Mathies [:jimm]]

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

Comment 6

[Jim Mathies [:jimm]]

Attachment: merged with mozilla-1.9.1

The original didn't apply cleanly to 1.9.1.

Comment 7

[Ed Lee :Mardak]

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?

Comment 8

[Jim Mathies [:jimm]]

(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.

Comment 9

[Jim Mathies [:jimm]]

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 10

[Mike Beltzner [:beltzner, not reading bugmail]]

Comment on attachment 371918 [details] [diff] [review]
merged with mozilla-1.9.1

a191=beltzner, jimm tells me that this already has tests

Comment 11

[Jim Mathies [:jimm]]

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

Comment 12

[Jim Mathies [:jimm]]

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

Comment 13

[Jim Mathies [:jimm]]

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