Closed Bug 1033516 Opened 5 years ago Closed 4 years ago
Releasing a second finger during dragging stops dragging
If while dragging you touch a second finger (perhaps because you think you may be able to scroll the view with the second finger, like you can on Android), the icon you're dragging will be released when you release the second finger instead of the first.
I wouldn't block on that. The behavior is the same as 1.4.
QA Whiteboard: [VH-FL-blocking-][VH-FC-blocking-]
Thanks for your time
Attachment #8479803 - Flags: review?(kgrandon)
Comment on attachment 8479803 [details] Github pull request Works great, thanks! Changing the polarity of the event listeners seems a bit weird to me, but not sure if there's a better way of doing it.
Attachment #8479803 - Flags: review?(kgrandon) → review+
Changed, waiting for a green world. Thanks Kevin! (In reply to Kevin Grandon :kgrandon from comment #3) > Comment on attachment 8479803 [details] > Github pull request > > Works great, thanks! Changing the polarity of the event listeners seems a > bit weird to me, but not sure if there's a better way of doing it.
Kevin, Zac, I have a problem with this patch :(, all marionette tests about dragging are failing. The drag&drop is implemented by actions like press().move().release() . Basically it is not working like FFOS does. 'touchstart' -> var id = e.changedTouches.identifier MARIONETTE: 'touchend' -> e.changedTouches.identifiedTouch(id) === false FFOS 'touchend' -> e.changedTouches.identifiedTouch(id) === true Is the dragdrop behavior simulated wrongly with the action implemented? Is there any bug in marionette? is there any problem with my approach? Any suggestion is more than welcome Thanks a lot guys  https://github.com/mozilla-b2g/gaia/blob/master/apps/verticalhome/test/marionette/collection_pinned_edit_mode_test.js#L68
Hey crdlc, it sounds very much like the area you're interested in is in Marionette rather than the tests. I'm not familiar with the code but I know where it lives: http://dxr.mozilla.org/mozilla-central/source/testing/marionette/marionette-listener.js#968 I'm going to pass my ni? over to mdas who (IIRC) wrote this code and can advise you. Oddly it's only the js tests that are failing on your pull. The press/move/release seems to be ok in Gip.
Sorry, copy&paste :) Forget previous comment 8 Marionette: 'touchstart': e.changedTouches -> 1004 'touchend': e.changedTouches -> 1008 FFOS 'touchstart': e.changedTouches -> 0 'touchend': e.changedTouches -> 0
Right, mdas would probably be able to help here best. Let's see if there is a quick marionette test framework fix that we can do here.
(In reply to Cristian Rodriguez (:crdlc) from comment #9) > Sorry, copy&paste :) Forget previous comment 8 > > Marionette: > > 'touchstart': e.changedTouches -> 1004 > 'touchend': e.changedTouches -> 1008 > > FFOS > > 'touchstart': e.changedTouches -> 0 > 'touchend': e.changedTouches -> 0 Yes, something is wrong in marionette if this is the case. If there is one active finger, then touchstart and touchend should reference the same touch identifier in changedTouches. If there are two, then their identifiers should differ by 1... How did you get these values? I'd like to take a closer look. I'll be away on PTO for a week, but I'll look at this when I get back.
I got those values with console.log(e.changedTouches.identifier) in https://github.com/crdlc/gaia/blob/bug-1033516/shared/elements/gaia_grid/js/grid_dragdrop.js#L427 https://github.com/crdlc/gaia/blob/bug-1033516/shared/elements/gaia_grid/js/grid_dragdrop.js#L491 and running this test: https://github.com/crdlc/gaia/blob/bug-1033516/apps/verticalhome/test/marionette/collection_pinned_edit_mode_test.js
As an update, I'm working on fixing https://bugzilla.mozilla.org/show_bug.cgi?id=1065501 for now, will look at this after
Malini, any update? Thanks
Sorry for the delay, Cristian, I just started investigating this today. More will come next week!
So I've been unsuccessful with running the test on both v2.0 and master, on flame using your repo's 'bug-1033516' branch. It fails while calling enterCreateScreen (https://github.com/crdlc/gaia/blob/bug-1033516/apps/verticalhome/test/marionette/collection_pinned_edit_mode_test.js#L43). How have you been running it? Can you reproduce it using today's gaia v2.0 code, or only on your clone/branch? I tried using actions to play around with the icons on the homescreen, but I see correct changedTouches identifiers when I do any touchmove/touchend actions. That being said, I did notice a more fundamental problem with multiactions. If you modified the test to take in more than one finger using MultiActions (https://github.com/mozilla-b2g/marionette-js-client/blob/master/lib/marionette/multi-actions.js) then I got unpredictable behaviour, but I still get the correct touch identifiers. I filed a bug for that problem here Bug 1074564
(In reply to Malini Das [:mdas] from comment #16) > I tried using actions to play around with the icons on the homescreen, but I > see correct changedTouches identifiers when I do any touchmove/touchend > actions. To clarify, if I do things like actions.press(calendarIcon).wait(3).move_by_offset(10,0).wait(0.1).move_by_offset(10,0).release().perform() I see: touchmove: 1003 touchmove: 1003 touchend: 1003 in my logs. This is on both v2.0 and master.
I nearly filed a dupe of this -- I see versions of this bug all over the place in Gaia. Basically, if you're performing an action with one finger (and keeping that finger touched to the screen), and you briefly tap/brush the screen with another finger, the action is canceled and all subsequent touch events from your first finger seem to be ignored. E.g.: - On the lockscreen, if I partially slide the slider w/ one finger and tap the screen with a second finger, the slider is dropped. - On homescreen / browser / zoomed-in-photo-in-Gallery: if I'm panning up and down w/ one finger & briefly tap the screen with a second finger, my pan is interrupted and my first finger movements are ignored from that point on.
(actually, since this original bug here seems to be about a specific instance w/ icons being dropped on homescreen, I did end up filing a new bug for the more general problem that I described in comment 18: bug 1181703.)
Mass update: Resolve wontfix all issues with legacy homescreens. As of 2.6 we have a new homescreen and having these issues open is confusing. All issues will block bug 1231115 so we can use that to re-visit any of these if needed.
Status: ASSIGNED → RESOLVED
Closed: 4 years ago
Resolution: --- → WONTFIX
You need to log in before you can comment on or make changes to this bug.