Closed Bug 772422 Opened 12 years ago Closed 12 years ago
Text is selected automatically when panning
Firefox 16.0a1 (2012-07-10) Device: Galaxy Nexus OS: Android 4.0.4 Steps to reproduce: 1. Open Fennec 2. Browse to https://forums.craigslist.org/?forumID=76&areaID=1 3. Pan down and up the left frame Expected result: After step 3, the pan is performed without auto text selection. Actual result: After step 3, the text will be auto-selected. The selection length will be different each time when step 3 is performed.
Summary: Text is selected automatically when panning an iframe → Text is selected automatically when panning a frame
Summary: Text is selected automatically when panning a frame → Text is selected automatically when panning
This is a regression from bug 732052. I think this happens on all pages, but it definitely happens on http://people.mozilla.com/~mleibovic/test/lorem_ipsum.html.
So now, on touchmove events we are storing their capture target here: http://mxr.mozilla.org/mozilla-central/source/layout/base/nsPresShell.cpp#6533 but in this case, we're catching the touch events in fennec's browser.js, and redispatching mouse events (to trigger selection). I think(?) those mouse events are propagating through and being confused by the information stored by the touch event? cc'ing smaug to know if that even makes sense and if he knows a simple solution. Otherwise, I'll start digging through and trying to figure out where things are off the rails. We may have to use a different set of capturing API's for touch.
Wait, this happens even with panning right? So it has nothing to do with our crazy event dispatching. And I have no idea why its causing selection either... Simple hacky fix idea: don't call PushCurrentEventInfo if we're not capturing. i.e. store a boolean here: http://mxr.mozilla.org/mozilla-central/source/layout/base/nsPresShell.cpp#6521 to know if we're capturing content. If we aren't, don't bother pushing or popping the current event info.
(In reply to Wesley Johnston (:wesj) from comment #2) > but in this case, we're catching the touch events in fennec's browser.js, So what code where? Does it end up calling preventDefault() or some such to prevent default handling to happen in C++. (Though, I don't recall if touch events are cancelable.)
(In reply to Olli Pettay [:smaug] from comment #4) > (In reply to Wesley Johnston (:wesj) from comment #2) > > > but in this case, we're catching the touch events in fennec's browser.js, > So what code where? Does it end up calling preventDefault() or some such to > prevent default > handling to happen in C++. (Though, I don't recall if touch events are > cancelable.) This bug happens if you pan the page while text selection is active, so it's happening when you touch somewhere else other than the selection handles. While text selection is active, there are touch listeners on the handles . Is the presence of those listeners what's messing things up?  http://mxr.mozilla.org/mozilla-central/source/mobile/android/chrome/content/browser.js#1821
So the patches in bug 732052 cause touch events to call HandlePress/Drag/Release function in frames. This fixes the problem by having us bail from HandlePress before... something bad happens. Its calling fc->SetMouseDownStat(true) which I suspect causes us to start selecting. We aren't firing any mouse events that I can see in nsPresShell::HandleEvent. I'm not exactly sure why we don't hit this any time your finger is down (with the patches from bug 732052) either. Still digging to understand this a bit, but hoping that ehsan can tell me if I'm way off base.
Assignee: nobody → wjohnston
Attachment #641211 - Flags: review?(ehsan)
Note that slider's will still work after this because they have their own handlePress handler.
Comment on attachment 641211 [details] [diff] [review] Patch Can we get a test for this, please.
Attachment #641211 - Flags: review?(ehsan) → review+
Test that touch events don't affect the current selection. Fails before. Passes with.
Attachment #641250 - Flags: review?(bugs)
Attachment #641250 - Flags: review?(bugs) → review+
Something interesting happens here. Even if the patch was not landed on the latest Nightly, this issue doesn't occur anymore. -- Firefox 16.0a1 (2012-07-11) Device: Galaxy Nexus OS: Android 4.0.4
That is probably because bug 732052 was backed out.
Status: NEW → RESOLVED
Closed: 12 years ago
Resolution: --- → FIXED
Verified on: Nightly Fennec 17.0a1 (2012-08-28) Aurora Fennec 16.0a2 (2012-08-27) Device: HTC Desire Z OS: Android 2.3.3
Status: RESOLVED → VERIFIED
You need to log in before you can comment on or make changes to this bug.