10 iii and ii touchscreen events? Difficult to click URL's, v-hard to click-n-hold/double-tap for new-tab/copy-text operations

Bug Reports
#22

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
#23

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
#24

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
#25

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
#26

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.

#27

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
#28

+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
#29

+1 too. It’s really annoying.

2 Likes
#30

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.

#31

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
#32

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
#33

Please give these settings a try and report back what values you prefer.

  • apz.touch_start_tolerance: 0.0762785f → 0.5
  • apz.content_response_timeout: 600 → 150
  • ui.click_hold_context_menus.delay 800 → 200

For me the touch-start seems about right, although it has the trade-off of introducing a small dead-zone before page movement begins.

I’m just now starting to play with the other two, so no conclusion yet. They seem to interact in some way, you need to change both for full effect. E.g. setting just the click/hold delay to zero results in there still being a quite long delay. But with both reduced the open-link menu now shows much sooner, making browsing feel more responsive.

15 Likes
Sailfish Community News, 8th September, New Harbour APIs
Phone App: tap to change to "dial buttons" or "persons" is missing sometimes
Sailfish Community News, 8th September, New Harbour APIs
#34

Wow! The values suggested by you really do wonders and finally make using this browser a pleasant experience. No more struggling with every single link. Thanks!

1 Like
#35

How can I do this? Enter commands into cli, edit some config file or something else?

#36

Open the native web browser, type about:config in the address field, accept the warning, find corresponding values on the displayed list and change them. Then enjoy usable web browser, at last!

P.S. So I was right from the very beginning, it was all about proper timeout and bigger tolerance for undesired finger movement.

5 Likes
#37

Works like a charm! A much much better user experience than before!

Thank you so much @d.geelen , @wetab73 !

2 Likes
#38

A big thanks also from me. It’s working well.

2 Likes
#39

From me tooo !!!
Thx a lot.

1 Like
#40

These settings work like a charm for me! Thanks!

#41

Thanks!
It solves the previous weird behaviour.
However, I choose to change the last parameter valur from 200 to 400 in order to avoid spurious contextual menus popping when scrolling slowly or back and forth lists like on youtube recommandations.

2 Likes