808862 - When moving app icons, second long press requires too much time

Status: RESOLVED FIXED

(Firefox OS Graveyard :: Gaia::Homescreen, defect)

Description

[John Karahalis [:openjck]]

Steps to repeat:

1. Hit the "Home" button
2. Long-press on an app icon
3. Let go
4. Long press on a different app icon

Actual result:

The user needs to wait a relatively long time -- about 2 seconds -- before he can move the second app icon.

Expected result:

The user should not need to wait long before he can move the second app icon. The wait time that Android uses (about .5 seconds) would be ideal.

Comment 1

[Josh Carpenter [:jcarpenter]]

Related to bug 813079. We should fix this for release. Current Edit mode unresponsiveness is a significant usability problem.

Comment 2

[Josh Carpenter [:jcarpenter]]

We should fix this for release. Current Edit mode unresponsiveness is a significant usability problem. Noming for blocking along with per related bug 813079. Failing that, should make a priority for UX Branch.

Comment 3

[Josh Carpenter [:jcarpenter]]

Cristian, similar to bug#813079, is this just a matter of tweaking a few timing variables?

Gordon, can you look at fixing in the UX branch?

Comment 4

[Josh Carpenter [:jcarpenter]]

Removing the "uxbranch" label after talking to Gordon. Need info from Cristian on level of effort required to fix.

Comment 5

[Cristian Rodriguez (:crdlc)]

Hi,

    Here we use a platform event called contextmenu in order to enter in edit mode or drag&drop. I take a look to this during these days. Sorry because I was on Holidays previous week.

Thanks

Comment 6

[Cristian Rodriguez (:crdlc)]

My feedback here is clear:

     We use the 'contextmenu' event for entering in drag/drop, edit mode or pick a wallpaper. If you decide that the timeout implemented for this event is long we should set a custom timeout programmatically instead of using 'contextmenu' event. We can implement that but it would add more complexity in the panning code (< performance). What do you thing about it Vivien?

Thanks a lot

Comment 7

[Josh Carpenter [:jcarpenter]]

(In reply to crdlc from comment #6)
> My feedback here is clear:
> 
>      We use the 'contextmenu' event for entering in drag/drop, edit mode or
> pick a wallpaper. If you decide that the timeout implemented for this event
> is long we should set a custom timeout programmatically instead of using
> 'contextmenu' event. We can implement that but it would add more complexity
> in the panning code (< performance). What do you thing about it Vivien?
> 
> Thanks a lot

Hmm... extra complexity would be bad, but yes, drag/drop selection should be much faster than it currently is. Approx 1/3rd whatever the default contextmenu event is. Times for Edit mode and Pick Wallpaper can remain unchanged.

Comment 8

[Vivien Nicolas (:vingtetun) (:21) - (NOT reading bugmails, needinfo? please)]

(In reply to crdlc from comment #6)
> My feedback here is clear:
> 
>      We use the 'contextmenu' event for entering in drag/drop, edit mode or
> pick a wallpaper. If you decide that the timeout implemented for this event
> is long we should set a custom timeout programmatically instead of using
> 'contextmenu' event. We can implement that but it would add more complexity
> in the panning code (< performance). What do you thing about it Vivien?
> 
> Thanks a lot

The contextmenu event is supposed to fire 1s  (http://mxr.mozilla.org/mozilla-central/source/b2g/app/b2g.js#508) after the start I wonder why it looks like 2s.

If this time is also generally too long we can tweak it.

Comment 9

[Josh Carpenter [:jcarpenter]]

(In reply to Vivien Nicolas (:vingtetun) from comment #8)
> (In reply to crdlc from comment #6)
> > My feedback here is clear:
> > 
> >      We use the 'contextmenu' event for entering in drag/drop, edit mode or
> > pick a wallpaper. If you decide that the timeout implemented for this event
> > is long we should set a custom timeout programmatically instead of using
> > 'contextmenu' event. We can implement that but it would add more complexity
> > in the panning code (< performance). What do you thing about it Vivien?
> > 
> > Thanks a lot
> 
> The contextmenu event is supposed to fire 1s 
> (http://mxr.mozilla.org/mozilla-central/source/b2g/app/b2g.js#508) after the
> start I wonder why it looks like 2s.
> 
> If this time is also generally too long we can tweak it.

FWIW, the two seconds is probably subjective. On my 12/26 builds it seems more like 1sec.

The problem is that we only want to speed up the icon drag/drog selection. Times for Edit mode and Pick Wallpaper are fine as-is. And per Cristian, using a custom timing for icon drag/drop selection gets tricky. I think that's what we need your input on here, per comment #6.

Thank you sir!

Comment 10

[Vivien Nicolas (:vingtetun) (:21) - (NOT reading bugmails, needinfo? please)]

(In reply to crdlc from comment #6)
> My feedback here is clear:
> 
>      We use the 'contextmenu' event for entering in drag/drop, edit mode or
> pick a wallpaper. If you decide that the timeout implemented for this event
> is long we should set a custom timeout programmatically instead of using
> 'contextmenu' event. We can implement that but it would add more complexity
> in the panning code (< performance). What do you thing about it Vivien?
> 
> Thanks a lot

I'm a bit worried about introducing a new custom way of listening for contextmenu here. I would like to not change that if possible.

Comment 11

[Chris Jones [:cjones] inactive; ni?/f?/r? if you need me]

Currently the context-menu timeout is 1 second.  We can easily drop the timeout.  It will apply to *all* contextmenu (long-tap) interactions, though.  That seems like a good thing to me.

If that's also what UX wants, it's a 1-line change to a pref.

Comment 12

[Josh Carpenter [:jcarpenter]]

Okay, if it's one size fits all, then let's drop it from 1 to .75. Thanks guys.

Comment 13

[Chris Jones [:cjones] inactive; ni?/f?/r? if you need me]

Attachment: Lower context-menu hold delay to 750ms

Comment 14

[Chris Jones [:cjones] inactive; ni?/f?/r? if you need me]

Comment on attachment 697292 [details] [diff] [review]
Lower context-menu hold delay to 750ms

b2g-only, \epsilon risk to b2g, patch to improve UX-P1 issue on prime real estate.

Comment 15

[Chris Jones [:cjones] inactive; ni?/f?/r? if you need me]

https://hg.mozilla.org/integration/mozilla-inbound/rev/6abeaaa94f24

Comment 16

[Ed Morley [:emorley]]

https://hg.mozilla.org/mozilla-central/rev/6abeaaa94f24

Comment 17

[Alex Keybl [:akeybl]]

Comment on attachment 697292 [details] [diff] [review]
Lower context-menu hold delay to 750ms

Simple low-hanging fix. Let's get this on branches.

Comment 18

[Chris Jones [:cjones] inactive; ni?/f?/r? if you need me]

https://hg.mozilla.org/releases/mozilla-aurora/rev/c74e05a0b45c
https://hg.mozilla.org/releases/mozilla-b2g18/rev/a98395bb676c

Comment 19

[Cristian Rodriguez (:crdlc)]

Hi all, 

    I was working on my holidays in this issue and I had a patch to make the second long press and consecutives faster. It is not a complex algorithm if somebody want to take a look.... I know that the bug is closed but a lot of people said to me that they expect the long press faster in edit mode.

https://github.com/crdlc/gaia/commit/76602c6b8fae8d60f0a2cabbfed62dc623e72393