Give gesture events usable clientX/screenX values

RESOLVED FIXED

Status

()

Core
Event Handling
RESOLVED FIXED
9 years ago
9 years ago

People

(Reporter: Mardak, Assigned: smaug)

Tracking

(Blocks: 1 bug, {fixed1.9.1})

Trunk
x86
Mac OS X
fixed1.9.1
Points:
---
Dependency tree / graph

Firefox Tracking Flags

(Not tracked)

Details

Attachments

(2 attachments)

(Reporter)

Description

9 years ago
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.
Assignee: nobody → Olli.Pettay
Created attachment 362227 [details] [diff] [review]
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.
(Reporter)

Comment 2

9 years ago
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.
Attachment #362227 - Flags: superreview?(roc)
Attachment #362227 - Flags: review?(roc)
Attachment #362227 - Flags: superreview?(roc)
Attachment #362227 - Flags: superreview+
Attachment #362227 - Flags: review?(roc)
Attachment #362227 - Flags: review+
Status: NEW → RESOLVED
Last Resolved: 9 years ago
Resolution: --- → FIXED

Updated

9 years ago
Blocks: 479901

Comment 4

9 years ago
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).
Attachment #362227 - Flags: approval1.9.1?

Comment 5

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

Comment 6

9 years ago
Created attachment 371918 [details] [diff] [review]
merged with mozilla-1.9.1

The original didn't apply cleanly to 1.9.1.

Updated

9 years ago
Attachment #362227 - Flags: approval1.9.1?

Updated

9 years ago
Attachment #371918 - Flags: approval1.9.1?
(Reporter)

Comment 7

9 years ago
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

9 years ago
(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

9 years ago
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
Attachment #371918 - Flags: approval1.9.1? → approval1.9.1+

Comment 11

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

Comment 12

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

Comment 13

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

Updated

9 years ago
Keywords: fixed1.9.1
You need to log in before you can comment on or make changes to this bug.