Closed Bug 733804 Opened 10 years ago Closed 10 years ago

Window scroll being processed before touch events are sent to document


(Firefox for Android Graveyard :: General, defect)

Not set


(Not tracked)



(Reporter: cbryant, Assigned: wesj)


User Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:10.0.2) Gecko/20100101 Firefox/10.0.2
Build ID: 20120215223356

Steps to reproduce:

I have a div element that I manually scroll via capturing touch events. Contents exceed window height with overflow set to hidden. Displayed page is zoomed to exceed size of window I manually adjust scrollTop based on touchstart, touchmove, touchend events. This works fine in other browsers I tested running on Android ICS and Xoom tablet. This is on FF 10.0.2

Actual results:

Document is often, but not always, scrolled in view event when touch event default processing is terminated. It appears that at times the touch events are processed by the window without going to the element being touched in the document first. Not sure if duplicate events are generated that are not sent to document as I tried capturing all events sent to document without seeing these.

Expected results:

Touch events should always be sent to document elements before being bubbled to window.
Two things. Can you toss up a test page? And also, can you test in Firefox 13 (Nightly, see

Fennec scrolls asynchronously, so its possible its taking to long for us to hear back from the page to preventDefault. We have some heuristics in place to make that work, but they may be failing. Also, in XUL Fennec we have a special area at the top and edges of the screen where we don't allow preventDefault to work. To test if that is the problem, you can change the prefs dom.w3c_touch_events.safetyX and safetyY.

We've removed that in nightly, and we're using a drastically different model for panning and touchevents there.
I just retested in the FF 11.0 (FireFox Beta from android market). It has the same problem. Scrolling of the div works but page moves too.

Tested the Nightly apk (FF 13.0a 2012-03-06) and am not seeing the touch events at all.

We are running a browser based game with many of the built in browser items, such as scrollbars and such overridden in javascript. You can access our test server via (Username: Simoon, pword: abc123). Touch updates are being developed on the cbryant test server. In particular, the chat area on the right of the main game screen is what I've been testing, there are many other scrollable areas, but this is the one that is easiest to test. 

Currently, I allow the touchstart event to bubble, then if I handle the subsequent touchmove event (meaning the scrollable area isn't at the limit of scroll) I create and dispatch a touchcancel to the parent of the scrollable area to cancel the previous touchstart action then prevent all subsequent touch events from bubbling until I see another touchstart. This allows me to scroll my reqion but allow the document to be scrolled in the window if the start of a new touch action is performed at the limit of the scrollable area. This is a work around to touch screen browsers not adequately allowing scrolling of scrollable subelements in a document page.
Thanks! Really surprised if you aren't getting any touch events on 13.0a. Something must be going very wrong. Does or allow panning?

I'll take this and try to test it out soon. The touchcancel approach is also new to me. I haven't heard of anyone using it, and its not (currently) spec'd to do what you describe:

(Apple's own specs are pretty vague on these topics if I remember right). We DO currently support calling preventDefault on touchstart or the first touchmove for a point as a method of preventing us from panning our chrome.

As a possible workaround if you need one, we actually support scrolling overflow elements in Fennec. You shouldn't actually need to do any special work to handle the scrolling.... unless its a canvas element and you're faking the scroll or something fancy like that.
Assignee: nobody → wjohnston
mfinkle just reminded me that touch events were broken by bug 664707 this week. The fix landed on 3-07 (one day after the build you tested). If you have time, mind testing with 13.0a1 from after 3-07 to see if they are fixed?
Just retested on 13.0a1.. Same operation as FF 10 and 11.  The window appears to scroll before the event is sent to the document element. Calling evt.preventDefault() for all touch events at the very top of my event handler does not stop the window scrolling either.

Not really related, but the 2 second delay in redrawing the element after any change to the is very annoying and not apparent in other browsers. The window scroll happens immediately even before the touchend with the scroll of my element occuring after this delay and not until the touchend.

Stucture of my element is a <div><div><ul><li />...</ul></div><div><img /></div><div><img /></div></div> in its most simplistic. All the elements inside the outermost div are constructed in javascript via createElement and appendChild. The outermost div has a fixed size with overflow hidden. The first div inside this is used to scroll the ul element by adjusting the, this inner dive is the full height for all of its content elements. The second and third divs are to hold the images used for the scroll bar and slider.

I suspect the long delay is because you are trying to redraw the entire inner div element instead of just what is visible in the outer div view area.

Unfortunately, I can't rely on built in overflow element scrolls because too many browsers don't support it.
Just an update, I tried to get a reduced testcase here:

but this works fine for me on Fennec 13. So I either accidentally removed the problem code (possible), or maybe this takes less processing time and leads to fewer issues? Any help from the reporter or QA to get a reduced test case would be helpful.
I suggest trying the following as a min test case:

<div id="outer">
  <div id="inner">
      <li>put the text here</li>
   <div id="scrollbar"><img id="verticialscrollbarimg" src="someimg" style="position: relative" />
   <div id="scrolltab"><img id="scrolltab" src="someimg" style="position: relative" />

so in addition to moving the, also move the as I am moving the scroll tab to represent the relative position of the inner div. I don't expect it really matters where the scrollbar and scrolltab are displayed, but I shift them to be to right of the inner div position within the outer div element view.
Not sure why processing time of the event handler should matter at all as I had my code calling preventDefault() as the first action before doing any other processing.

I'll try a retest without moving or displaying the scrollbars to see if there is an interaction with moving and displaying an image in conjunction with the div top change.
Ever confirmed: true
OS: Windows 7 → Android
Hardware: x86_64 → ARM
I retested without displaying or moving the scrollbar and slider (.style.visibility = "hidden"). The main window still moves when it should not.

I also retested with just having the touch handler do preventDefault and return, so no moving any elements just canceling the event. In this case the window still moved.

Seems like it must be an issue with the structure of the element nesting that is causing the touch events to not be canceled correctly.
Anyone try the test case in comment #7? Wes?, could you perhaps attach a testcase with the "Add an attachment " link, if that is possible? 
Or perhaps that isn't possible, from a quick look at the comments in this bug?
At this point, I am very suspicious this is being caused by bug 741247. i.e. these panels are on the right side of the page. One trick to test if that's the case it to pinchzoom in, and then try scrolling (obviously, we're going to have to fix this bug though).
I've retested this on FF beta 12.0 and it appears to now be working correctly. 

I can scroll our lists using touch events with the overall window not moving until I hit the end of the list scrolling and begin sending events to the window.
On XUL builds (like 12) I would guess you were seeing bug 743325. On native bug 741247 may be hitting you here. Since this seems to work for you now, and we have a separate bug to track the native stuff, I'm going to close this WFM. Reopen if you disagree.
Closed: 10 years ago
Resolution: --- → WORKSFORME
Product: Firefox for Android → Firefox for Android Graveyard
You need to log in before you can comment on or make changes to this bug.