WebView produces incorrect screen.height, window.innerHeight values

Bug Reports
,
#6

Test tool: GitHub - poetaster/webview-screensize: a tool to test webview screen, browser sizes and orientation

2 Likes
#7

Thanks for your test tool, and other comments, which have been very helpful. Would you be willing to test out this change please, attempting to address the height value issues on the 10 II?

I tried it with your test tool (also on a 10 II) with positive results, but it could do with more practical testing as there’s scope for a lot of edge cases here.

#8

Ok. That fix makes mah solitaire, among others, scale properly again. Looks like one less issue :slight_smile:

2 Likes
#9

Also works with leaflet.js resizing and scaling on orientation change.

1 Like
#10

That’s good to hear. Thank you for testing it @poetaster. I’ll aim to get this change in for the next release, but that depends on it passing review of course.

#11

I did an evil variant on the Volla 22 and just removed the viewportHeight completely. Same effect :slight_smile: But I’m only mentioning that to ask a ‘related’ question.

On the vollas, regardless, of useragent string, and even with the correct browser window measures, the display always looks ‘desktop’. I’m trying to determine how the qtmozembed component ‘goes’ there. Is it trying to guess the display size by some other means from the compositor? It doesn’t having anything to do with css media selectors, per se. Any ideas where to poke around?

#12

I’m not sure, but one thing that springs to mind is that the pixel density may be set differently. In that case, the site may be thinking the screen is larger (physically) than it is.

You may have already answered this above (I skimmed though again but couldn’t see it), but on the Volla, is the browser working correctly (and e.g. switching between desktop mode and mobile mode works fine)? It’s only the WebView that defaults to desktop mode?

#13

Yes. Only the webview displays this behaviour. Have tried @mal’s suggestions vis. /var/lib/environment/compositor/droid-hal-device.conf but DPI at that environment level doesn’t change things. I’m guessing that the compositor tells qtmozembed what effective DPI is?

EDIT: but if it’s only in WebView, can’t be DPI per se, or?

#14

I did only the briefest of testing using your test app, but editing ~/.cache/org.myorg/webview-screensize/.mozilla/prefs.js and changing the layout.css.devPixelsPerPx value I was able to persuade GitHub to switch between mobile and desktop mode (on a 10 III, a value of 1 gave desktop mode, while a value of 3 gave mobile mode). I’m not saying this is where your problem lies, but maybe it’s an avenue to explore.

Since the browser is working correctly, you could compare the value with that found in ~/.local/share/org.sailfishos/browser/.mozilla/prefs.js.

1 Like
Volla & Volla 22, WebView problem and irony of ironies
#15

Thanks! Every avenue helps!

I also noted on the 10ii that the rendering seem desktop in portrait but mobile in landscape. But it doesn’t have that effect with ‘actual’ web pages (so, ones with media selectors and viewport meta tags). Did you notice that?

#16

Sorry, just for clarification, rendering of what?

#17

I meant the content of the test app. When in portrait mode, the size of fonts, the blue div are scaled differently than when in landscape mode.

#18

Yes, I see the same, and I don’t have an adequate explanation for that I’m afraid, except to say that this is at least the same as the behaviour with the web browser (independent of whether Desktop mode is forced or not).

#19

Interesting. That value is not set in the webview prefs.js at all in the case of Mah solitaire. I wonder if this is a fault in my dependency declarations in the spec?

#20

Adding this to the prefs.js file of any webview app works! Thanks!

1 Like
#21

Excellent! Since you have preference files that don’t include the value, it may be that there are committed but unreleased changes to this in the pipeline. Let me see if I can find the place where this is set, as I suspect this may be useful for figuring out what should be happening on the Volla.

#22

Thanks! Not sure if you covered it in your webview article(s) but are the user prefs settable from within QML?

#23

I’m not sure whether I covered it either :slight_smile: but it can be, yes, see pixelRatio here:

1 Like
#24

It looks like the code to determine the default pixel density can be found at the link below.

It could be that these values don’t work well for the Volla, although I’m not sure why there would be a difference between the browser and the WebView I’m afraid.

Once you’ve experimented with values on the Volla, it would be good to know what you conclude.

#26

Using the WebEngineSettings.pixelRatio = 3 works fine on volla/gs290 and gs5 phones. Looks like a universal. Ok, so I can implement soft fixes for all my apps. Thanks!