I launched the browser with the proposed command line.
I was very surprised to notice that the problem totally disappeared!!!
So I relaunched the browser from the app launcher to compare and no problem anymore too!
As if something in the browser config has been reset by this command.
In addition I noticed that copy/paste cursors were unusable before and now it has also been solved by this manipulation.
Hope it helps to understand the problem origin.
At least, it’s a workaround!
That wasn’t the expected outcome, but I’m glad it’s working for you now, and thanks for the information. It all helps.
I’m just bumping this thread in case anyone was able to collect any logs in relation the issue. Unfortunately I’ve not been able to reproduce the issue on any of my devices.
I’ve been getting this issue for ages - especially on cookie settings pop-ups. I was going to start the logging commands above, but initially ran the browser from the command line, and it seems much more responsive to button presses than before. I’ll keep an eye on it, and initiate the logging if/when I get any issues with any sites - it might come back after restart?
But I did wonder if the command line start is relevant?
Here’s what I noticed so far:
I ran sailfish-browser from the command line and the issue disappeared. When I closed the browser, the terminal showed the following errors at the end:
corrupted double-linked list
Aborted (core dumped)
I started the browser from the UI and got the issue again.
So I started from the command line again and the issue disappeared again (no corruption error and no abort).
Finally, I started from the UI and the issue wasn’t there.
That makes me wonder if the corrupted double-link list error somehow corrupted something somewhere.
If that would help to send the core dump, where can I find it and to who should I send it?
So, you mean it’d be useless to collect logs if the browser is launched from de cli?
Just happened to me again.
I was wandering:
Can the browser believe we are scrolling instead of clicking?
Is there a threeshold we could adjust in order to exagerate the ‘they are clicking’ interpretation?
After some practice, I’m convinced the browser is thinking that we’re scrolling. I get used to use only very light taps when clicking on a link. This is a workaround though.
I’m about to join the debug club here, and your observation makes sense in my experience. I’ll try to reproduce it and see how it goes.
I have the same problem in my XA2 4.4 SFOS.
The following PR from @rainemak was recently merged (it may hopefully make it into the next release, if not the release after that):
That’s not a fix for the bug tracking this one, so I’ve not yet marked this bug as fixed, but it’s quite possible that @rainemak’s investigation and fix may resolve this one too.
Once this change is released, it would be really helpful if anyone who experienced this could test again and post back to confirm whether it’s fixed or not.
I want to report an observation I made right now:
If running video player in the background (for music listening) while surfing the net using stock browser, responsibility of browser is much much better!
Can it be that the running video player prevents the phone from going into some power saving mode and so keep CPU at full speed, therefore browser speed & responsibility much much better this way? (also touchkeyboard response)
Thanks for the report @Seven.of.nine. That’s not something I’ve experienced. Was your battery below 10% or anything specific like that? If you’re able to reproduce it reliably it would be appreciated if you could create a new bug report about it.
No, battery was not low. Battery 50 - 100 % or running on USB power while i experience that, and it’s a permanent phenomen.
While running LLs vPlayer or DeadBeef Silica in the background and listen to music and surf the net with standard SF browser in foreground, the browser is much faster and much more reactive to user interaction as it is when running alone.
@Seven.of.nine would you mind creating a new bug to explain what you experienced? It would be helpful to separate it from this bug to avoid confusion on my part.
The fix for @Steve_Everett’s original bug at the top of the thread has now been merged in, so should be addressed in the next major release. As such I’ve changed the tag from “tracked” to “fixed”.
Once the release is out, and people have had a chance to check and confirm it’s fixed, I’ll then close this thread (or, if it’s not fixed, we can continue the discussion).
Isn’t this already released with 4.4.0.72? Or is there something else to be released?
### qtmozembed-qt5
- Updated : 1.53.22-1.32.2.jolla -- 1.53.23-1.33.1.jolla
- [qtmozembed] Use physicalDotsPerInch for EmbedLiteView dpi.
Thanks @direc85, you’re absolutely correct, I was confusing this with something else. So, if @Seven.of.nine is okay to create a new topic, then I would then close this one, unless someone objects.
@Seven.of.nine, if you prefer not to write up something more formal, I could just move your existing two comments into a new topic.
Just right now I tried one hour but I failed to retrigger this behavior. With or without running LLs Vplayer in background, Browser worked fine. Volla / 4.4.0.72 . Sorry…
There’s no need to be sorry 
it’s good that you flag up any issues that you experience.
I’m closing this now, as the issue should be fixed and there haven’t been any reports to the contrary. If anyone would like it opened again, send me a direct message and I can do so.