Closed Bug 733804 Opened 10 years ago Closed 10 years ago
Window scroll being processed before touch events are sent to document
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 nightly.mozilla.org)? 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.
Thanks! Really surprised if you aren't getting any touch events on 13.0a. Something must be going very wrong. Does maps.google.com or openstreetmaps.org 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: https://dvcs.w3.org/hg/webevents/raw-file/tip/touchevents.html#the-touchcancel-event (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 an update, I tried to get a reduced testcase here: http://bit.ly/wbohds 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"> <ul> <li>put the text here</li> </ul> </div> <div id="scrollbar"><img id="verticialscrollbarimg" src="someimg" style="position: relative" /> </div> <div id="scrolltab"><img id="scrolltab" src="someimg" style="position: relative" /> </div> </div> so in addition to moving the inner.style.top, also move the scrolltab.style.top 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.
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?
email@example.com, 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.
Status: NEW → RESOLVED
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.