Last Comment Bug 378028 - two-fingered trackpad scrolling: horizontal movement causes vertical scrolling
: two-fingered trackpad scrolling: horizontal movement causes vertical scrolling
Status: VERIFIED FIXED
: verified1.9.1
Product: Core
Classification: Components
Component: XUL (show other bugs)
: Trunk
: PowerPC Mac OS X
-- normal with 2 votes (vote)
: ---
Assigned To: Robert O'Callahan (:roc) (email my personal email if necessary)
:
: Neil Deakin
Mentors:
: 438426 (view as bug list)
Depends on: 454472
Blocks: 350471
  Show dependency treegraph
 
Reported: 2007-04-19 07:17 PDT by Keith Clarke
Modified: 2009-01-23 11:01 PST (History)
14 users (show)
roc: wanted‑next+
roc: wanted1.9.1+
dsicore: blocking1.9-
roc: wanted1.9-
roc: in‑testsuite+
See Also:
Crash Signature:
(edit)
QA Whiteboard:
Iteration: ---
Points: ---
Has Regression Range: ---
Has STR: ---


Attachments
fix (32.14 KB, patch)
2008-04-19 02:31 PDT, Robert O'Callahan (:roc) (email my personal email if necessary)
no flags Details | Diff | Splinter Review
fix v2 (32.17 KB, patch)
2008-04-19 07:27 PDT, Robert O'Callahan (:roc) (email my personal email if necessary)
bugs: review-
Details | Diff | Splinter Review
fix v3 (32.38 KB, patch)
2008-04-20 14:07 PDT, Robert O'Callahan (:roc) (email my personal email if necessary)
bugs: review+
Details | Diff | Splinter Review
fix v4 (32.40 KB, patch)
2008-04-20 14:32 PDT, Robert O'Callahan (:roc) (email my personal email if necessary)
no flags Details | Diff | Splinter Review
fix v5 (57.91 KB, patch)
2008-04-21 07:16 PDT, Robert O'Callahan (:roc) (email my personal email if necessary)
bugs: review+
jonas: superreview+
Details | Diff | Splinter Review
fix v6 (37.64 KB, patch)
2008-07-24 02:56 PDT, Robert O'Callahan (:roc) (email my personal email if necessary)
roc: review+
roc: superreview+
Details | Diff | Splinter Review
v6.1: better error codes (36.94 KB, patch)
2008-07-25 04:43 PDT, Robert O'Callahan (:roc) (email my personal email if necessary)
no flags Details | Diff | Splinter Review
fix test (1.25 KB, patch)
2008-08-12 05:45 PDT, Markus Stange [:mstange] (away until Feb 22)
roc: review+
Details | Diff | Splinter Review

Description User image Keith Clarke 2007-04-19 07:17:06 PDT
User-Agent:       Mozilla/5.0 (Macintosh; U; Intel Mac OS X; en-us) AppleWebKit/419 (KHTML, like Gecko) Safari/419.3
Build Identifier: version 3.0a1 (20070419)

Right-to-left movement on the trackpad in the message list pane causes vertical scrolling, as does top-to-bottom movement. Thus diagonal movement from top-right to bottom-left causes jitter as the scolling position is simultaneously moved up and down. This makes it necessary for the user to be very precise in their movements. The obvious fix is to ignore horizontal movement when there is no horizontal scrollbar (this would be consistent with other applications). This bug is also present in the release build of 2.0.0.0.

Reproducible: Always

Steps to Reproduce:
1.position cursor in message list pane for any long list of messages
2.enable two-fingered scrolling!
3.move fingers diagonally from top right towards bottom left
Actual Results:  
nasty jitter in the message list, unpredictable final scroll position

Expected Results:  
smooth scrolling; enough sweeps in this direction should leave the scroll position at the bottom of the list

tested with fresh profiles on two machines.
Comment 1 User image Jesse Ruderman 2007-11-28 10:55:18 PST
I see this in trees in Firefox trunk too (history sidebar, bookmarks window).  It makes it difficult to scroll using two fingers: if you don't go straight up or down, the scrolling jumps around.
Comment 2 User image Damon Sicore (:damons) 2007-12-03 11:28:54 PST
-'ing.  Not a regression.
Comment 3 User image Jesse Ruderman 2007-12-03 18:28:42 PST
Damon is right, this happens in Firefox 2.0.0.11 as well.  Pretty annoying, though.
Comment 4 User image Robert O'Callahan (:roc) (email my personal email if necessary) 2008-04-19 02:31:22 PDT
Created attachment 316560 [details] [diff] [review]
fix

This patch borrows from Markus' patch in bug 350471 to create a nsDOMMouseScrollEvent class. Then I expose an "axis" attribute so that JS can know which direction the mouse scroll is coming from.

This is a very low risk approach compatibility-wise and Olli recommended it :-).

However, this patch has one problem. It spews a lot of assertions

###!!! ASSERTION: Class name and proto chain interface name mismatch!: 'nsCRT::strcmp(CutPrefix(name), mData->mName) == 0', file /Users/roc/mozilla-trunk/dom/src/base/nsDOMClassInfo.cpp, line 3680

'name' is nsIDOMNSMouseScrollEvent, 'mData->mName' is MouseScrollEvent. I guess this wouldn't happen if the interface name was nsIDOMMouseScrollEvent, but I thought we reserved such names for standard-ish things. Olli, do you think I should use NS here or not, and if we don't, how do we silence that assertion?
Comment 5 User image Olli Pettay [:smaug] (pto-ish for couple of days) 2008-04-19 06:07:32 PDT
For event types we haven't used nsIDOMNS, see for example nsIDOMPopupBlockedEvent.
Comment 6 User image Robert O'Callahan (:roc) (email my personal email if necessary) 2008-04-19 07:27:26 PDT
Created attachment 316590 [details] [diff] [review]
fix v2

Okay, fix with name change.
Comment 7 User image Olli Pettay [:smaug] (pto-ish for couple of days) 2008-04-19 08:45:23 PDT
Comment on attachment 316590 [details] [diff] [review]
fix v2

>+nsDOMMouseScrollEvent::nsDOMMouseScrollEvent(nsPresContext* aPresContext,
>+                                             nsInputEvent* aEvent)
>+  : nsDOMMouseEvent(aPresContext, aEvent ? aEvent :
>+                 new nsMouseScrollEvent(PR_FALSE, 0, nsnull))
Missing few spaces?

>+nsDOMMouseScrollEvent::InitMouseScrollEvent(const nsAString & aType, PRBool aCanBubble, ...>+  if (mEvent->eventStructType == NS_MOUSE_SCROLL_EVENT) {
>+    static_cast<nsMouseScrollEvent*>(mEvent)->scrollFlags =
>+        (aAxis == HORIZONTAL_AXIS) ? nsMouseScrollEvent::kIsHorizontal : 0;

Here you set mEvent->scrollFlags, but GetAxis uses mScrollFlags.
Actually, there shouldn't be any need for mScrollFlags, since there is always
mEvent->scrollFlags

> XPIDLSRCS =					\
> 	nsIDOMNSEvent.idl			\
> 	nsIDOMDataContainerEvent.idl	\
> 	nsIDOMKeyEvent.idl			\
>+  nsIDOMMouseScrollEvent.idl \
Align this properly

>     <handlers>
>-      <handler event="DOMMouseScroll" action="this.scrollByIndex(event.detail); event.stopPropagation();"/>
>+      <handler event="DOMMouseScroll"><![CDATA[
>+        if (event.axis != event.HORIZONTAL_AXIS)
>+          return;
Should that be ==, not != ?
Comment 8 User image Robert O'Callahan (:roc) (email my personal email if necessary) 2008-04-20 14:02:53 PDT
Is it possible for mEvent to not be an NS_MOUSE_SCROLL_EVENT?

I hope you've got some big plan to simplify all this :-)
Comment 9 User image Olli Pettay [:smaug] (pto-ish for couple of days) 2008-04-20 14:07:10 PDT
mEvent should be always NS_MOUSE_SCROLL_EVENT.
mEvent->message could be either NS_MOUSE_SCROLL or NS_USER_DEFINED_EVENT.

And yes, the current plan is to remove nsEvent usage from DOM :)
Comment 10 User image Robert O'Callahan (:roc) (email my personal email if necessary) 2008-04-20 14:07:54 PDT
Created attachment 316722 [details] [diff] [review]
fix v3

With those changes
Comment 11 User image Olli Pettay [:smaug] (pto-ish for couple of days) 2008-04-20 14:18:07 PDT
Comment on attachment 316722 [details] [diff] [review]
fix v3

Looks ok to me. And you have tested those XBL bindings, right ;)
Comment 12 User image Robert O'Callahan (:roc) (email my personal email if necessary) 2008-04-20 14:32:38 PDT
Created attachment 316725 [details] [diff] [review]
fix v4

I really ought to test this before submitting
Comment 13 User image Robert O'Callahan (:roc) (email my personal email if necessary) 2008-04-20 14:33:34 PDT
I tested the XBL bindings to but failed to compile the C++, sorry.
Comment 14 User image Olli Pettay [:smaug] (pto-ish for couple of days) 2008-04-20 23:25:46 PDT
Comment on attachment 316725 [details] [diff] [review]
fix v4

>+NS_IMETHODIMP
>+nsDOMMouseScrollEvent::InitMouseScrollEvent(const nsAString & aType, PRBool aCanBubble, PRBool aCancelable,
>+                                nsIDOMAbstractView *aView, PRInt32 aDetail, PRInt32 aScreenX, 
>+                                PRInt32 aScreenY, PRInt32 aClientX, PRInt32 aClientY, 
>+                                PRBool aCtrlKey, PRBool aAltKey, PRBool aShiftKey, 
>+                                PRBool aMetaKey, PRUint16 aButton, nsIDOMEventTarget *aRelatedTarget,
>+                                PRInt32 aAxis)
>+{
>+  nsresult rv = nsDOMMouseEvent::InitMouseEvent(aType, aCanBubble, aCancelable, aView, aDetail,
>+                                                aScreenX, aScreenY, aClientX, aClientY, aCtrlKey,
>+                                                aAltKey, aShiftKey, aMetaKey, aButton, aRelatedTarget);
>+  NS_ENSURE_SUCCESS(rv, rv);
>+  
>+  if (mEvent->eventStructType == NS_MOUSE_SCROLL_EVENT) {
>+    static_cast<nsMouseScrollEvent*>(mEvent)->scrollFlags =
>+        (aAxis == HORIZONTAL_AXIS) ? nsMouseScrollEvent::kIsHorizontal : 0;
>+  }
Sorry, idiot me. Since scrollFlags is used also for other things than horizontal/vertical, 
it might after all be better to have separate mAxis, which is initiated in the constructor and in the
InitMouseScrollEvent. That way .axis returns always the right value, the value
which is either passed via nsMouseScrollEvent or InitMouseScrollEvent.
A bit ugly part is that also scrollFlags should be set in InitMouseScrollEvent if
aAxis is either HORIZONTAL_AXIS or VERTICAL_AXIS.

The current ? : expression in the patch is wrong anyway, it sets only horizontal flag, never the vertical one.

>+NS_IMETHODIMP
>+nsDOMMouseScrollEvent::GetAxis(PRInt32* aResult)
>+{
>+  NS_ENSURE_ARG_POINTER(aResult);
>+
>+  if (mEvent->eventStructType == NS_MOUSE_SCROLL_EVENT) {
>+    PRUint32 flags = static_cast<nsMouseScrollEvent*>(mEvent)->scrollFlags;
>+    *aResult = (flags & nsMouseScrollEvent::kIsHorizontal)
>+         ? PRInt32(HORIZONTAL_AXIS) : PRInt32(VERTICAL_AXIS);
>+  } else {
>+    *aResult = 0;
>+  }
>+  return NS_OK;
>+}

So this would become 
NS_ENSURE_ARG_POINTER(aResult);
*aResult = mAxis
return NS_OK;
Comment 15 User image Robert O'Callahan (:roc) (email my personal email if necessary) 2008-04-21 07:16:55 PDT
Created attachment 316807 [details] [diff] [review]
fix v5

I don't want to add mAxis ... I'd rather the information just be stored once so we don't have to worry about consistency. So here I'm just fixing the incorrect ?:.

Well, the other big thing I'm doing is adding mochitests for mousescroll events for trees, listboxes, and arrowscrollboxes. This turned out to be extremely painful but it's done. The tests also test XUL scrollboxes (via the richlistbox tests), which use C++ scrollframe/ESM logic but it's still good to have that tested.

Testing the arrowscrollboxes showed one issue with horizontal arrowscrollboxes (e.g. an overflowing tab strip). We should allow horizontal mouse scrolling to scroll such a tab strip. But we should *also* allow vertical mouse scrolling to scroll it horizontally, since a lot of people have vertical mouse scrolling but not horizontal mouse scrolling. On the other hand vertical arrowscrollboxes should not be horizontally scrollable. So there's a funny asymmetry there in the code and in the tests.
Comment 16 User image Markus Stange [:mstange] (away until Feb 22) 2008-04-21 07:58:41 PDT
Comment on attachment 316807 [details] [diff] [review]
fix v5

>+++ mozilla-trunk/toolkit/content/widgets/tree.xml

>       <handler event="DOMMouseScroll" phase="capturing">
>         <![CDATA[
>           if (this._editingColumn)
>             return;
>+          if (event.axis == event.HORIZONTAL_AXIS)
>+            return;

Wouldn't it be better to make use of that event using scrollToHorizontalPosition (of nsITreeBoxObject) instead of just throwing it away?

Attachment 128196 [details] (of bug 212789) can be used to play with horizontal tree scrolling.
Comment 17 User image Olli Pettay [:smaug] (pto-ish for couple of days) 2008-04-22 02:46:38 PDT
Comment on attachment 316807 [details] [diff] [review]
fix v5

>+  /** Synthesize a mouse scroll event for a window. The event types supported
>+   *  are: 
>+   *    mousescroll
Shouldn't this be DOMMouseScroll.
Or perhaps you could remove the first parameter, aType, since that can be only
"mousescroll". Either way.
Comment 18 User image Robert O'Callahan (:roc) (email my personal email if necessary) 2008-04-22 03:00:22 PDT
We should keep the type since Markus wants to add DOMMousePixelScroll soon.

These names aren't really in the same namespace as the DOM event names as far as I can tell. But I'll make it DOMMouseScroll, sure.

(In reply to comment #16)
> Wouldn't it be better to make use of that event using
> scrollToHorizontalPosition (of nsITreeBoxObject) instead of just throwing it
> away?

Yeah. But I'm trying to not add any new features here right now :-). Adding that would be an easy extension later.
Comment 19 User image Jonas Sicking (:sicking) No longer reading bugmail consistently 2008-04-23 22:51:06 PDT
Is this something we're hoping to put in 1.9? What is the relation between this event and the one w3c is in the process of speccing?
Comment 20 User image Robert O'Callahan (:roc) (email my personal email if necessary) 2008-04-24 01:19:05 PDT
I was hoping to get it into 1.9. Olli thought it was a low-risk way to fix this bug. Maybe it's too late. If so, we should still take it on trunk when the tree reopens.

This event is a legacy event that we already support. It's used by extensions and by Web content so we're not going to drop support anytime soon. When the W3C mouse-scroll event is done, we should support it as well, deprecate this one and maybe eventually remove it. But that's a few releases away I guess.
Comment 21 User image Robert O'Callahan (:roc) (email my personal email if necessary) 2008-04-28 20:41:19 PDT
I can't justify doing this for 1.9 at this point. Punting.
Comment 22 User image Mildred Ki'Lya 2008-06-07 15:45:04 PDT
Would it be possible to change the Hardware: Macintosh and OS: Mac OS X to something more neutral. This is also an issue for GNU/Linux users that have configured two-finger trackpads with synaptics (as I did).
Comment 23 User image Markus Stange [:mstange] (away until Feb 22) 2008-06-11 14:43:11 PDT
*** Bug 438426 has been marked as a duplicate of this bug. ***
Comment 24 User image Avi Halachmi (:avih) 2008-06-11 15:07:36 PDT
Adding a question. As the author of the SmoothWheel extension and submitter of bug 438426 (recently announced as a duplicate of this bug), Is there a way for an extension to access this info? Can smoothwheel distinguish horizontal from vertical events?
Comment 25 User image Avi Halachmi (:avih) 2008-06-11 15:12:48 PDT
P.S. for comment #24.

It's obvious firefox can tell the difference because without smoothwheel installed, on OSX the scroll gestures work well, both vertical and horizontal. Smoothwheel only works on vertical scroll for now, and should ignore H scroll events, fut for now, I don't know how to do that.
Comment 26 User image Markus Stange [:mstange] (away until Feb 22) 2008-06-12 01:05:56 PDT
(In reply to comment #24)
> Is there a way for
> an extension to access this info? Can smoothwheel distinguish horizontal from
> vertical events?

It can't. DOMMouseScroll events don't carry axis information yet; that's what the patch fixes. The patch gives DOMMouseScroll events an "axis" attribute so that you can check event.axis == event.HORIZONTAL_AXIS.

(In reply to comment #25)
> It's obvious firefox can tell the difference

Yes, because Firefox processes the original nsEvent [1] that contains a scrollFlags attribute; however, when the nsEvent is transformed into a DOMEvent, the scrollFlags information is lost and thus can't be accessed by JavaScript code.
There is one line in Firefox JavaScript code that pretends it can access the scrollFlags of a DOMMouseScroll event [2], but that's rubbish.

[1] http://bonsai.mozilla.org/cvsblame.cgi?file=/mozilla/content/events/src/nsEventStateManager.cpp&rev=1.742&mark=2497-2499#2480
[2] http://bonsai.mozilla.org/cvsblame.cgi?file=/mozilla/browser/base/content/browser-textZoom.js&rev=1.9&mark=151#138
Comment 27 User image Avi Halachmi (:avih) 2008-06-12 04:20:03 PDT
Thank you very much for the info.

Also, I'm trying to understand the practical implications of not including a solution for "1.9". Does that mean that it won't get into Firefox 3.0? Does it mean it's postponed to 4.0? or maybe that it can be fixed in a minor 3.0.x Firefox release?

Comment 28 User image Robert O'Callahan (:roc) (email my personal email if necessary) 2008-06-12 05:44:23 PDT
We can land this as soon as Jonas reviews the patch. It would then be in the minor release of Firefox (3.1?) that we plan to have.
Comment 29 User image Jonas Sicking (:sicking) No longer reading bugmail consistently 2008-07-19 17:17:47 PDT
Is this following the new scroll and/or mouse events as defined by DOM L3 Events?
Comment 30 User image Markus Stange [:mstange] (away until Feb 22) 2008-07-20 01:12:51 PDT
It's not - right now we're just extending the Mozilla-specific DOMMouseScroll event (see also comment 20). The Webapps wheel event [1] isn't quite ready for implementation - especially the unit stuff is still quite unclear, and Olli's mail about it [2] didn't receive any useful answers yet.

In bug 350471 comment 42, Olli suggested going the DOMMouseScroll route if the spec isn't ready.

[1] http://www.w3.org/2008/webapps/wiki/Mousewheel
[2] http://lists.w3.org/Archives/Public/public-webapps/2008AprJun/0231.html
Comment 31 User image Olli Pettay [:smaug] (pto-ish for couple of days) 2008-07-20 02:46:35 PDT
Bug 350471 is separate for this, sort of. DOM 3 has already defined how to
handle X/Y/Z. What it is still missing is proper support for pixel scrolling (bug 350471).

But anyway, we could still use DOMMouseScroll (we can't remove support for that because of backward compatibility).

And note, DOM 3 Events isn't even in Last Call.

(In reply to comment #30)
> In bug 350471 comment 42, Olli suggested going the DOMMouseScroll route if the
> spec isn't ready.
I suggested going DOMMousePixelScroll route for pixel scrolling ;)
Comment 32 User image Markus Stange [:mstange] (away until Feb 22) 2008-07-20 03:03:41 PDT
(In reply to comment #31)
> DOM 3 has already defined how to
> handle X/Y/Z.

Yeah, ok. It currently says that X/Y/Z should be handled using the attributes
  readonly attribute long            wheelDeltaX;
  readonly attribute long            wheelDeltaY;
  readonly attribute long            wheelDeltaZ;
... but if it's later decided to go with your suggestion 6 [1] and make these attributes *arrays* of longs, even this doesn't apply anymore.

[1] http://lists.w3.org/Archives/Public/public-webapps/2008AprJun/0233.html
Comment 33 User image Olli Pettay [:smaug] (pto-ish for couple of days) 2008-07-20 04:40:46 PDT
(In reply to comment #32) 
> ... but if it's later decided to go with your suggestion 6 [1] and make these
> attributes *arrays* of longs, even this doesn't apply anymore.
true.

...hoping to find some good solution for pixel/line/page scroll events...
Comment 34 User image Robert O'Callahan (:roc) (email my personal email if necessary) 2008-07-20 20:22:11 PDT
I don't think we should wait for the Webapps group to finalize their spec before we fix this for XUL apps and extensions. It's already a problem in Firefox.
Comment 35 User image Jonas Sicking (:sicking) No longer reading bugmail consistently 2008-07-24 00:56:30 PDT
Comment on attachment 316807 [details] [diff] [review]
fix v5

Ugh, sorry for the long review time :(
Comment 36 User image Robert O'Callahan (:roc) (email my personal email if necessary) 2008-07-24 02:56:37 PDT
Created attachment 331070 [details] [diff] [review]
fix v6

Updated to trunk, comments addressed, ready to check in.
Comment 37 User image Avi Halachmi (:avih) 2008-07-24 18:51:30 PDT
2 questions if you don't mind.

1. Just to see if I understand, is this the way to test orientation now?: if (event.axis == event.HORIZONTAL_AXIS)

2. Can this be accessed from normal html pages? or only from extensions?
Comment 38 User image Robert O'Callahan (:roc) (email my personal email if necessary) 2008-07-24 19:21:02 PDT
It can be accessed from Web pages and extensions.

This isn't the greatest API because it can't handle diagonal motion in a single event, but it's more compatible with what we've already got. Hopefully the W3C event will obsolete this one before too long.
Comment 39 User image Robert O'Callahan (:roc) (email my personal email if necessary) 2008-07-24 21:08:35 PDT
Pushed c0717c5ec0d2.
Comment 40 User image Robert O'Callahan (:roc) (email my personal email if necessary) 2008-07-25 01:49:17 PDT
I backed this out because of test failures:

*** 61506 ERROR TEST-UNEXPECTED-FAIL | /tests/toolkit/content/tests/widgets/test_tree.xul | Error thrown during test: uncaught exception: [Exception... "Component returned failure code: 0x80004005 (NS_ERROR_FAILURE) [nsIDOMWindowUtils.sendMouseScrollEvent]"  nsresult: "0x80004005 (NS_ERROR_FAILURE)"  location: "JS frame :: http://localhost:8888/tests/SimpleTest/EventUtils.js :: synthesizeMouseScroll :: line 273"  data: no] - got 0, expected 1
*** 62352 ERROR TEST-UNEXPECTED-FAIL | /tests/toolkit/content/tests/widgets/test_tree_hier.xul | Error thrown during test: uncaught exception: [Exception... "Component returned failure code: 0x80004005 (NS_ERROR_FAILURE) [nsIDOMWindowUtils.sendMouseScrollEvent]"  nsresult: "0x80004005 (NS_ERROR_FAILURE)"  location: "JS frame :: http://localhost:8888/tests/SimpleTest/EventUtils.js :: synthesizeMouseScroll :: line 273"  data: no] - got 0, expected 1
*** 63084 ERROR TEST-UNEXPECTED-FAIL | /tests/toolkit/content/tests/widgets/test_tree_hier_cell.xul | Error thrown during test: uncaught exception: [Exception... "Component returned failure code: 0x80004005 (NS_ERROR_FAILURE) [nsIDOMWindowUtils.sendMouseScrollEvent]"  nsresult: "0x80004005 (NS_ERROR_FAILURE)"  location: "JS frame :: http://localhost:8888/tests/SimpleTest/EventUtils.js :: synthesizeMouseScroll :: line 273"  data: no] - got 0, expected 1
*** 63593 ERROR TEST-UNEXPECTED-FAIL | /tests/toolkit/content/tests/widgets/test_tree_single.xul | Error thrown during test: uncaught exception: [Exception... "Component returned failure code: 0x80004005 (NS_ERROR_FAILURE) [nsIDOMWindowUtils.sendMouseScrollEvent]"  nsresult: "0x80004005 (NS_ERROR_FAILURE)"  location: "JS frame :: http://localhost:8888/tests/SimpleTest/EventUtils.js :: synthesizeMouseScroll :: line 273"  data: no] - got 0, expected 1

These happened on all Tinderbox platforms. But sadly they don't happen on my machine.
Comment 41 User image Robert O'Callahan (:roc) (email my personal email if necessary) 2008-07-25 04:30:37 PDT
My Linux build doesn't show the errors either.
Comment 42 User image Robert O'Callahan (:roc) (email my personal email if necessary) 2008-07-25 04:43:18 PDT
Created attachment 331293 [details] [diff] [review]
v6.1: better error codes

This might help localize the issue.
Comment 43 User image Robert O'Callahan (:roc) (email my personal email if necessary) 2008-08-11 21:30:36 PDT
Markus, can you try running those tests to see if you can reproduce the failures with this patch?
Comment 44 User image Markus Stange [:mstange] (away until Feb 22) 2008-08-12 05:21:51 PDT
Yes! I can reproduce the failures :-)
I'll look into this now.
Comment 45 User image Markus Stange [:mstange] (away until Feb 22) 2008-08-12 05:45:13 PDT
Created attachment 333401 [details] [diff] [review]
fix test

That should do it. I wonder why the test wasn't failing for you...
Comment 46 User image Robert O'Callahan (:roc) (email my personal email if necessary) 2008-08-12 20:09:27 PDT
Comment on attachment 333401 [details] [diff] [review]
fix test

Thanks Markus!
Comment 47 User image Robert O'Callahan (:roc) (email my personal email if necessary) 2008-08-12 20:09:50 PDT
Pushed a02e6af74ab8.
Comment 48 User image Avi Halachmi (:avih) 2008-08-23 00:57:14 PDT
1. Is this still the way to use it?
if (event.axis == event.HORIZONTAL_AXIS) ...

2. When will the public get a Firefox version that supports this enhancement? 3.0.x? 3.1?

thx
Comment 49 User image Markus Stange [:mstange] (away until Feb 22) 2008-08-23 02:08:58 PDT
(In reply to comment #48)
> 1. Is this still the way to use it?
> if (event.axis == event.HORIZONTAL_AXIS) ...

Yes it is. You can try it in a recent nightly: http://ftp.mozilla.org/pub/mozilla.org/firefox/nightly/latest-trunk/

> 2. When will the public get a Firefox version that supports this enhancement?
> 3.0.x? 3.1?

3.1.
Comment 50 User image Avi Halachmi (:avih) 2008-10-03 09:11:46 PDT
Just thought I'd add this here. For the sake of backward compatibility (at least within extensions but probably on other places too), instead of testing the axis as in comment #48, it's preferred to use this form:

if (event.HORIZONTAL_AXIS!=undefined && event.axis==e.HORIZONTAL_AXIS){ <horizontal axis handling code> }

or else, the test in comment #48 will always yield true (both tested values are undefined and in this case, will always execute horizontal handler) when, in fact, the test should be skipped because the attribute is not supported.
Comment 51 User image Tony Chung [:tchung] 2009-01-23 11:01:07 PST
Verified fix on Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.5; en-US; rv:1.9.1b3pre) Gecko/20090123 Shiretoko/3.1b3pre
and Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.5; en-US; rv:1.9.2a1pre) Gecko/20090123 Minefield/3.2a1pre

Note You need to log in before you can comment on or make changes to this bug.