WebView vertical scrolling is broken

[karry]

REPRODUCIBILITY: 100%
OS VERSION: 4.5.0.21
HARDWARE: Xperia 10 II
UI LANGUAGE: Czech
REGRESSION: yes, it was working fine in previous releases.

DESCRIPTION:

When opening some app screen that contains qml webview component and scrolling its content vertically, content stay on the same position, but top of the component become hidden.

PRECONDITIONS:

Some app with webview component, like jolla-email or harbour-sfos-forum-viewer…

STEPS TO REPRODUCE:

1. open some email which content is larger than device screen
2. scroll page vertically

EXPECTED RESULT:

Content is scrolled.

ACTUAL RESULT:

Content stays on the same position, just the top of the content become hidden.

It is is hard to describe, so I recorded the video of jolla-email app:

ownCloud - A safe home for all your data

MODIFICATIONS:

I am not aware of any related modifications.

ADDITIONAL INFORMATION:

Web browser works fine.

[davidrasch]

This issue was already discussed several times in the forum and if i remember correctly, there was also a fix involving the deletion of some app data. I’ll try to find the thread.

[davidrasch]

It was here : Scrolling and zooming in an email progressively hides its content from above

[karry]

Thanks, it really helps. For future references:

mv ~/.local/share/com.jolla/email ~/.local/share/com.jolla/email.backup
mv ~/.cache/com.jolla/email  ~/.cache/com.jolla/email.backup
killall booster-browser

When i dig deeper, I found out that deleting /home/defaultuser/.local/share/com.jolla/email/__PREFS_WRITTEN__ file is enough to fix the problem.

When I revert .cache/com.jolla/email/.mozilla/prefs.js from the backup, it is broken again!

These lines are added in new version (correct one):

+user_pref("app.update.lastUpdateTime.user-agent-updates-timer", 0);
+user_pref("apz.fling_stopped_threshold", "0.13f");
+user_pref("apz.touch_start_tolerance", "0.0762785f");
+user_pref("embedlite.inputItemSize", "50");
+user_pref("embedlite.zoomMargin", "20");
+user_pref("general.useragent.updates.enabled", true);
+user_pref("layers.tile-height", 1080);
+user_pref("layers.tile-width", 1080);
+user_pref("layout.css.devPixelsPerPx", "3");
+user_pref("ui.click_hold_context_menus.delay", 800);
+user_pref("ui.textSelectBackground", "#878787");

And the problematic line that was missing in my previous prefs.js is user_pref("layout.css.devPixelsPerPx", "3");. WTF?!

[poetaster]

@karry

user_pref("layout.css.devPixelsPerPx", "3"); . WTF?!

Ah, yes. This had to do, I believe, with incorrect values being propagated …

WebView produces incorrect screen.height, window.innerHeight values

For reference? [components-webview] Respect component height. Fixes JB#57689 · sailfishos/sailfish-components-webview@df9ae3c · GitHub I now have three different results. On .64 volla, harbour-moremahjong works as you’d expect. On .72 volla, the display in portrait mode is obviously desktop (far too small). Select a game and play and it zooms in but is cut off (see title). On .72 on the 10ii, the display in portrait mode is correct. Select a game and play and it’s just like the volla. This see…

and tangentially

Volla & Volla 22, WebView problem and irony of ironies

This weekend I needed to install a fresh GS290 / Volla and while at it also did a GS5 install. Obviously two different devices with different base images from @piggz. EDIT (tldr): In short, it looks like you need to be careful when restoring backups that newer prefs for the WebView can be written. Look for ~.local/share/org.name/appname/PREFS_WRITTEN files. If those are there, it’s possible that ~.cache/share/org.name/appname/.mozzila/prefs.js file is not correctly written. All went well and I…

I built a test app and the prefs hack was one part of it but also a component fix from jolla.

[jwalden]

I might be missing something here, but to me it seems that this is duplicate to this Scrolling and zooming in an email progressively hides its content from above, which has been solved?

[davidrasch]

That is correct, that thread also has been linked above and been marked as solution.

[ilpianista]

Thanks!

In my case:

$ rm ~/.local/share/com.jolla/email/__PREFS_WRITTEN__
$ systemctl --user restart booster-browser@jolla-email.service 

did it!

[karry]

Yes it is solved - in sense that fix is known. It is still strange to me what cause that issue. I just reflash phone with new OS and restored home directory including .cache and .local directories…

[poetaster]

There is a bit more info here [components-webview] Respect component height. Fixes JB#57689 · sailfishos/sailfish-components-webview@df9ae3c · GitHub

But just which setting in the mozzila prefs that relates to that eludes me at the moment. I’ve had to reset the prefs even when restoring .local across identical devices. Also effects whether you get mobile or desktop views in some apps (the hackernews client from neversun, for instance).