Thanks! This is actually helpful I have some odd discrepancies in my builds.
Looks like you are using .68? I have 1.53.23-1.33.1.jolla with .72 on GS290 / Volla.
heh. It’s evil and NOT an answer (but I have work to do).
If you care: I downgraded to .64
- ssu re 4.4.0.64; ssu ur; zypper ref; zypper dup
- ssu re 4.4.0.72; ssu ur; zypper ref; zypper up
Notice that the last command does NOT do a dist upgrade. Then everything works on the GS290/Volla.
DON’T do this on your phone Unless you have a spare daily.
- ssu re 4.4.0.72; ssu ur; zypper ref; zypper up
Does this always work to update a Community-Port to newest SailfishOS-Version?
I have this Sailfish on Linux-Bootstick, found here in the Forum, but it Version is 4.0.xx.
@piggz had released 4.4.0.72 for community. It included fixes for video recording. I’m still not quite sure what’s going on (maybe qtscenegraph-adaptation, maybe not), but something changed for the worse between 4.4.0.64 and .72 and I can only experiment
For reference, I’m putting any details I find here: WebView produces incorrect screen.height, window.innerHeight values - #5 by poetaster
since it’s directly related.
happend to me that i got that
Checking for file conflicts: …[error]
Detected 1 file conflict:
File /etc/dbus-1/system.d/org.sailfishos.fingerprint1.conf
from install of
sailfish-fpd-1.5.0-1.4.1.jolla.aarch64 (jolla)
conflicts with file from install of
sailfish-fpd-community-1.1.2-1.1.2.jolla.aarch64 (adaptation-community)
File conflicts happen when two packages attempt to install files with the same name but different contents. If you continue, conflicting files will be replaced losing the previous content.
ssu re 4.4.0.72; ssu ur; zypper ref; zypper up
Is this really ‘zypper up’ or is this a typo and should be ‘zypper dup’?
Hi,
when i do downgrade, at least the sign the two up/down arrows do appear. however calls (outbound) are still not possible
J
Yeah, should be dup for dist upgrade. I’ve made the error a couple of times just doing an habitual ‘up’ … that’ll get you most of the way but leaves some config and possibly packages in a mess state.
Ok, as recorded: WebView produces incorrect screen.height, window.innerHeight values - #14 by flypig
@flypig found a solution which works. The question is why would the issue appear at all?!
For anyone who comes to this because of scaling issues, the simplest solution is to specify it in the view:
WebView {
Component.onCompleted: {
WebEngineSettings.setPreference("security.fileuri.strict_origin_policy", false, WebEngineSettings.BoolPref)
WebEngineSettings.pixelRatio = 3
}
as pointed out by @flypig.
Be aware that this value is device-specific though, so while a value of 3 may work on one type of device, it may not be appropriate for another.
Can you recall which apps you saw this in? In any case, @flypig had another suggestion which also solves the issue. It turns out that using a backup of files from .local/share where the app in question has a PREFS_WRITTEN file, this can lead to the the prefs.js file of the webview being incorrectly initialized.
In the case of harbour-tidings (where I just recently added a new WebView to replace the old QtWebkit) I only had to remove that prefs file and the .cache entries to get a proper prefs.js generated. The other data (the important bits) in .local/share remained unaffected. Some apps, however, removing the .cache entries will lose previous settings. Explicitly:
# rm .local/share/de.poetaster/harbour-tidings/__PREFS_WRITTEN__
# rm -rf .cache/de.poetaster/harbour-tidings/.mozilla
Got Tidings creating proper WebViews on the volla and GS5.
It was in Hafenschau
On an xperia x compact the mail client shows the same behavior ( at least on one phone)
where can i change the webview settings? in about:config?
For me it looks like qml
but clicking on the link suggests ~/.cache/org.myorg/webview-screensize/.mozilla/prefs.js
Removing the prefs-written file and the .Mozilla directory (obviously in the right app folders under .local and .cache) also fixes the problem for Kactus as well. It now displays news pages in mobile rather than desktop format and it scrolls properly.
the prefs.js file resides in ~/.cache/ in the apps .mozilla directory. Be aware you can’t count on those changes being permanent.