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

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.

Working much better, thanks.

I don’t think anyone disagreed with you about that. :slight_smile:

Tnx, these values work much better.
Should be the defaults for sure.

I’ve tried setting ui.click_hold_context_menus.delay to 400 as you said, but eventhough it does increase the time before responding to a link, I don’t find it really makes a difference for accidental activation when scrolling for me. Do you have a good site to test this? I tried specifically on Hacker news and the list of sailfish meeting minutes.

I was travelling by train recently, and found that I could lower apz.touch_start_tolerance to 0.25 or even 0.125 and still be able to quite easily open links. Specifically on hacker news, where with the default settings this was almost impossible. The lower start tolerance makes the ‘delay’ between moving your finger and the page starting to scroll smaller. With 0.125 it’s starting to be hard to tell there is a delay with casual use, but it does start to be a little more difficult to open links. Not by much, but this may be close to the lower limit for me (with the delays as I initially posted).

Finally, it’s great to hear so many of you confirm these values indeed improve the browser experience. It shows that it is not just one or two people who find the browser hard to use, but a common issue for which we now appear to have found a simple solution. Could we please hear from Jolla if it is taking action based on the feedback in this thread? I.e. can/will an update for these defaults be included in the next update?

It was mainly on Youtube suggestions that I had spurious activation. With my settings it’s much less frequent but still occured a few times. It’s probably due to the way I scroll…
I’ll try you suggestions for the start tolerance setting which indeed was sometimes annoying.

I start to believe that this is related to the fingerprint screen lock on my Xperia 10. Initially someone said this would be a hardware issue. But it looks like SailfishOS has a problem with the touchscreen responsiveness. On my Xperia10 plus it sometimes takes several seconds before the phone reacts on touch events. Locking and unlocking the screen often helps. Maybe a background job like tracker gets to high a priority and freezes the phone?

I think I found a regression. For some reason sometimes clicking stops working for browser content and I need to… double click instead of single click. Super weird, but browser restart helps every time.

Sounds similar to what @poetaster experienced with the hexagonal pipes game, but he was able to ‘fix’ it by removing the firefox settings folder (see above). Do we have any confirmation of this happening on stock settings? For me at least I’ve not noticed anything weird except for the pipes game.

As for apz.touch_start_tolerance, I’ve set it back to 0.25 as I found with 0.125 I had to sometimes try two or three times.

I’ve just posted in this other topic about @rainemak’s recently merged PR. This may well be of interest to readers of this topic too:

@d.geelen: you specifically asked on the newsletter topic about whether you should set the values you changed back after the next update. @rainemak will be able to give you a more complete answer, but my understanding is that his change may well also fix this issue, and if not it will at least affect the values you’ve changed. So yes, it would make sense to reset the values back to their defaults after the change is released.

If you could then post back with your experiences, that would also be really helpful.

4 Likes

@flypig 's answer is very much correct. If you leave apz.touch_start_tolerance to 0.25 actual touch start will resist more.

Here’s the source line and only place where the apz.touch_start_tolerance is used.

There was a bug in the DPI value that was set down to the ASyncPanZoomContoller. So, the math regarding the touch start tolerance on Xperia 10 III goes as follows :

Before with 0.25

96 * 0.25 = 24 (screen coordinates)

After with 0.0762785 <= calculated value

457 * 0.0762785 = 35 (screen coordinates)

Above 457 is rounded value. So, the new value after the fix is 11px higher when comparing 0.25 apz.touch_start_tolerance. You can simulate the fix by adding 0.364583333 to the apz.touch_start_tolerance. It could well be that for some users even higher return value from GetTouchStartTolerance would work better.

5 Likes

i have some difficulty edge-swiping (particularly up from the bottom) on the 10 III and 10 II, compared to X, Xc, and XZ2c.

it is only really a problem when my phone is in a waterproof case or plastic bag, where its always a LITTLE tricky, but on the 10 III, i sometimes have to swipe like 8 times to get it when its hanging in my shower. on xz2c, it was almost always one shot.

Following @rainemak’s explanation above I’ve tagged this as “fixed” to help our internal bug tracking. If anyone experiences the same issue after the next release containing the fix, please post back so I can amend things.

4 Likes

thank you very much all.

Something similar behavior also happens at the Volla phone running 4.4.0.64. Single tap is often ignored, the window where the button is seems to not have input focus. This is since the update to 4.4.0.64. 4.4.0.68 doesn’t work on the Volla phone.
In daily operation, it’s helpful to try two or three times and/or try to guess the right time for tapping (not too long and not too short) until it works, then it will work. But something seems to be buggy on the 64 bit port.
32 bit Xperia 10 works like a charm.