So the very interesting question is: Where is the 3 seconds defined? And, where is the next delay defined, when SFOS begins to enlarge the selection (more words, whole sentence)? This time is too short for me, this will be my next tweaks.
1 Like
I’m not available at the Aug 4th meeting, would anyone be available to front the discussion of this bug?
“These IRC meetings are for real time participation and live discussions, otherwise you can post the topic on here and get responses that way.”
Re: the above - if no-one is available then perhaps we can post it there anyway…
I’m also thinking that the touch events are handled in some unfortunate order by the internal browser. When trying to qoute in this forum, after I have marked the text and try to press the “Quote” element, the text selection is almost always removed. It seems that the browser handles it as a touch event outside of the selection rather than a press on the “Quote” element.
2 Likes
Same here on x10 III.
1 Like
I also have all the same Browser link click, hold and text selection issues on the Volla with 4.4.0.64 and with the 10ii (4.4.0.68).
Thanks for all of the useful replies and data collection on this.
It looks to me like this may be the same as the following (already tracked) issue:
@PeegeeTips, would you agree?
2 Likes
It may be the same when it comes to poor reaction to a tap (e.g. to open a link). But it is something entirely different when it comes to tap and hold, e.g. to open a menu to copy or share a link. It has been throroughly described in earlier posts. It is extremely difficult to hold the finger dead-still for such a long time (twice longer than e.g. in Firefox), especially on the X10 III very slippy screen surface. Slightest move by a fraction of milimeter and the action gets cancelled. It takes multiple attempts to get press&hold to work. Either the time to hold the finger still should be shorter (like in Firefox/Fennec) or the tolerance for undesired finger movement should be increased.
5 Likes
thanks for the update.
with wetab on this; the linked issue covers half the problem, explained perhaps by the fact that it references the XA2.
i have an XA2 and a 10iii and the ‘slippyness’ of the screen does seem a factor in click-n-hold operations for context menus.
I believe that the root cause is the same for both issues and it’s the symptoms that differ. My interpretation for root cause, after have reading the other thread, is that the scroll threshold is too low. Both comes down to the threshold used to identify when a user wants to start scrolling or just holding still.
In this, current report it means that the browser starts scrolling too early, instead of marking text or activating the context menu and in the linked post it means that the browser tries to scroll the page, instead of activating the link.
3 Likes
Even if so, I still struggle to understand why it requires to hold the finger twice longer than in virtually any other browser, e.g. Firefox. This bug aside, those 2 seconds (or so) are simply cumbersome and annoying. Why waste 2 seconds on it if the same gesture in Firefox taking 1 second works equally well and is so much more pleasant to use.
Besides, if it was shortened from 2 seconds to 1 second, maybe scrolling wouldn’t be starting too early anymore.
2 Likes
I think 2s is a reasonable timeout. If the timeout is shortened you might end up with a lot of unintentional text markings and context menus, when the scroll threshold is fixed.
2 Likes
I’d suggest that you simply install Firefox (eg. Fennec from f-droid) and see yourself how much faster, easier and simply more pleasant to use its tap&hold with twice shorter timeout is.
Firefox has millions of users and I haven’t seen literally anyone complaining about it or reporting any problems such as the ones you mentioned.
1 Like
I have Firefox installed already, and while I actually fall back to that sometimes, e.g. when I want to mark text and become frustrated with the stock browser, I don’t feel that the shorter timeout is snappier. Just that it is short enough, or maybe ff also affects scroll threshold, to actually make it possible to select text. So for me it’s not about snappier action, just usability.
I am on making the timeout shorter side, I often open links in new tabs, and waiting 2 seconds + the animation often makes me feel like the browser froze.
So I wouldn’t mong it getting faster
1 Like
+1 on the shorter timeout for increasing perceived rsponsiveness, and confirming the observation about the very slightest sub-milimeter finger movement cancelling the attempted action.
2 Likes
+1 too. It’s really annoying.
2 Likes
Just to clarify, I’m not against shorter timeout, but I think the scroll threshold is more important regarding perceived responsiveness, due to failed attempts getting context menu or marking text because browser thinking it’s a scroll event with current threshold.
Can we please know, where these 2 seconds are defined? So it would be possible to change it to a preferred value using an editor as devel-su.
1 Like
I don’t really agree with this line of fixing things. This way we may solve the problem for a few people who are sufficiently annoyed to look for a solution, know where to look, and then know how what to do with the information. I think devel-su commands are beyond most casual users.
Really Browser should just use the firefox defaults (some previously notes the timeout was different). And if Jolla wants to use a different value, they should offer a setting for this to revert to the default behaviour. Or maybe even do it the otherway, and have a setting to ‘opt in’ to ‘enhanced accessiblity’.
All that being said, it may be useful to see if there is a setting that controls this behaviour so that we may help identify what a more appropriate value would be. Settings are in about:config, some of the apz settings look promising, like apz.touch_start_tolerance.
3 Likes