+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
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.delay800 → 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
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
How can I do this? Enter commands into cli, edit some config file or something else?
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
Works like a charm! A much much better user experience than before!
2 Likes
A big thanks also from me. It’s working well.
2 Likes
From me tooo !!!
Thx a lot.
1 Like
These settings work like a charm for me! Thanks!
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
I don’t believe these settings (which work really well) have anything to do with it, but I noticed that an app (which I’m thinking of turning into a WebView) behaves oddly. Try playing 5x5 Hexagonal Pipes Puzzle #709 and note that tiles move in double steps. I thought it ‘might’ be the content_response_timeout (I set it to 300, which doesn’t appear to change anything vis. hexapipes).
Anyone else have the issue of the settings being ‘reset’ on new browser start?
For me, they stay after a reboot.
Hmmmm. I deleted all prefs (.mozilla), restarted, edited the prefs (after stopping the browser) and rebooted. The values keep being overwritten.
On the other hand, killing the .mozilla folder fixed the hexagonal pipes game. Go figure.
Hmmm. Added user.js to /home/defaultuser/.local/share/org.sailfishos/browser/.mozilla and it seems to stick.
For me, it stays after many launches and 1 or 2 GUI restarts via Sailfish Utilities.