1639086 - Browser html demos are not rendered full width / height

Status: RESOLVED INVALID

(GeckoView :: General, defect)

Description

[__oldboek]

User Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.15; rv:78.0) Gecko/20100101 Firefox/78.0

Steps to reproduce:

visit either http://browserhtml.github.io/browserhtml/components/about/newtab/demos/spheres.html or http://browserhtml.github.io/browserhtml/components/about/newtab/demos/transparent_rects.html

Actual results:

demos rendered in corner
https://user-images.githubusercontent.com/922368/57655761-4a868f00-75df-11e9-9b50-61239e894ffa.png
https://user-images.githubusercontent.com/922368/57655765-4f4b4300-75df-11e9-9d96-4c6ec28dfa79.png

Expected results:

the pages should take the whole screen like chrommium
https://user-images.githubusercontent.com/922368/57655736-36db2880-75df-11e9-84dc-f9d6abef4948.png
https://user-images.githubusercontent.com/922368/57655728-317dde00-75df-11e9-8252-72ec10950c72.png

Comment 1

[__oldboek]

bug on gh: https://github.com/mozilla-mobile/fenix/issues/2459

Comment 2

[Emily Toop (:fluffyemily)]

Kris, we think this might be a layout issue. Can you take a look and let us know where best to send it? Thanks

Comment 3

[Jamie Nicol [:jnicol]]

This issue occurs regardless of whether webrender is enabled, and in fact affects Fennec as far back as I can run it without it crashing immediately.

The page uses window.innerWidth/window.innerHeight to get the window size then adjusts the sphere's coordinates around that. It only reads these values once at startup then caches them for future use.

Adding some printfs to nsGlobalWindowOuter::GetInnerSize() I can see that it returns CSSIntSize(400, 312) at this point. This is smaller than expected. Ignore the height being so small relative to the width, that's because of the virtual keyboard. But I'd expect the width to be larger than that, I believe we usually use a fixed 980 for the viewport width on mobile.

In fact, if I change the test case to repeatedly read window.innerWidth/Height rather than using the cached windowWidth, meaning nsGlobalWindowOuter::GetInnerSize() is called repeatedly, then:
a) I can see the smaller (400, 312) value is returned dozens of times (probably for less than half a second, however), then it starts returning (980, 764) instead.
b) the testcase works as expected once we start returning (980, 764) for the inner size.

In between the last time (400, 312) is returned, and the first time (980, 764) is returned, I see this in the log:

05-22 14:44:58.545  3473  3490 D GeckoViewContent[C]: handleEvent: DOMTitleChanged
05-22 14:44:58.546  3442  3442 I GeckoViewActivity: Content title changed to spheres
05-22 14:44:58.578  3473  3490 E Web Content: [JavaScript Error: "The character encoding of the HTML document was not declared. The document will render with garbled text in some browser configurations if the document contains characters from outside the US-ASCII range. The character encoding of the page must be declared in the document or in the transfer protocol." {file: "http://192.168.0.60:8000/spheres.html" line: 0}]
05-22 14:44:58.582  3473  3490 D GeckoViewContent[C]: handleEvent: MozFirstContentfulPaint

I'm not at all familiar with this code, but can keep digging. Botond, Hiro, do either you have any ideas why we might be returning this smaller window size up until the first contentful paint?

Comment 4

[Hiroyuki Ikezoe (:hiro)]

This is probably due to bug 1598487, we don't yet return the same size as Chrome does for window.inner{Width,Height} in cases of minimum-scale is applied.

I will debug the test case later.

Comment 5

[Hiroyuki Ikezoe (:hiro)]

Okay, this is not related to bug 1598487. bug 1598487 will make this issue worse. So what happens there is, when the var windowWidth = window.innerWidth (and innerHeight) is called, there is no big elements which bloat the document at all. That means

(In reply to Jamie Nicol [:jnicol] from comment #3)

Adding some printfs to nsGlobalWindowOuter::GetInnerSize() I can see that it returns CSSIntSize(400, 312) at this point.

The value is correct at that point. Then some elements which will bloat up the document size are going to be added after the initial window.inner{Width,Height} were obtained. Then the document size gets bigger than the initial size.

I am unsure what's going on in Chrome but I can see a weird behavior in Chrome's RDM mode when I stopped the initial requestAnimationFrame call (which stops animations), the behavior I can see is that the black-based liner gradient background size varies on every reloading. That implies, even on Chrome, the script is pretty unstable.

I'd say, the site should specify <meta name="viewport" content="width=device-width,initial-scale=1"> to avoid auto initial scale calculations.

Comment 6

[Hiroyuki Ikezoe (:hiro)]

I was trying to do a PR to the browserhtml, but unfortunately the repo has been archived (which means I can't make PRs at all).