1622926 - android shows zoomed in about:support page

Status: RESOLVED FIXED

(GeckoView :: General, defect, P3)

Description

[Kris Taeleman (:ktaeleman)]

Attachment: About:support with OpenGL

STR:

• Enable webrender
• Open about:support
  Notice how the page is zoomed in

Expected:

• Page fits to screen like in OpenGL mode.

See screenshots.

I think this is a regression as I can't remember it being this way before.

Comment 1

[Kris Taeleman (:ktaeleman)]

Attachment: About:support with Webrender

Comment 2

[Kris Taeleman (:ktaeleman)]

@botond: Any idea what would be going on here?

Comment 3

[Botond Ballo [:botond]]

The special thing about about:support in comparison to regular webpages is that it's loaded in the parent process rather than the content process.

So, perhaps there's something particular to the combination of WebRender + parent process related to zooming that needs hooking up.

(In reply to Kris Taeleman (:ktaeleman) from comment #0)

I think this is a regression as I can't remember it being this way before.

A regression window might be useful.

Comment 4

[Botond Ballo [:botond]]

(In reply to Botond Ballo [:botond] from comment #3)

A regression window might be useful.

I got this regression window by running mozregression on GVE:

https://hg.mozilla.org/integration/autoland/pushloghtml?fromchange=4c3bf1eb86b9cd3051362510b3675c7d619fc4a7&tochange=245c4d1fe36f4e8812d9ffefb5cfdc9196a8c349

Comment 5

[Botond Ballo [:botond]]

I can repro this with OpenGL compositing, too.

For example, if I run mozregression -n gve --pref gfx.webrender.force-disabled:true --launch 2020-03-16 and then navigate to about:support, it's zoomed in (and the contents of the page, if you scroll down to Graphics > Compositing, confirm that the pref had the intended effect of disabling WebRender).

Comment 6

[[ex-Mozilla] Agi Sferro | :agi]

It's probably from

Agi Sferro — Bug 1554302 - Restore history when switching process during navigation. r=snorp

I can take a look tomorrow (keeping the ni so I remember)

Comment 7

[Botond Ballo [:botond]]

(In reply to :Agi | ⏰ PST | he/him from comment #6)

It's probably from

Agi Sferro — Bug 1554302 - Restore history when switching process during navigation. r=snorp

Confirmed, backing this patch out locally fixes the issue for me.

Comment 8

[Botond Ballo [:botond]]

What's hapenning at the platform level is, with bug 1554302 applied, we are getting a call to nsIDOMWindowUtils.setRestoreResolution(), with the resolution being 3.0, which we do not get without the patch. This overrides the platform's internal calculation of what the resolution should be (which would otherwise be something like ~0.7, depending on the screen size) and results in the zoomed-in rendering.

Comment 9

[Botond Ballo [:botond]]

(In reply to Botond Ballo [:botond] from comment #8)

we are getting a call to nsIDOMWindowUtils.setRestoreResolution(), with the resolution being 3.0

The call site of that in turn is in GeckoViewContentChild.js.

Comment 10

[[ex-Mozilla] Agi Sferro | :agi]

Yeah we restore zoom state from the previous page which is not correct.

I can reproduce on OpenGL too.

Comment 11

[[ex-Mozilla] Agi Sferro | :agi]

Attachment: Bug 1622926 - Don't restore scrolldata and form data when switching processes.

That data is not the right one anyway, since it comes from the previous page
rather than the current one.

Note: this is also broken on desktop too. It will be fixed once we move to main
process history (hopefully?).

Comment 12

[Pulsebot]

Pushed by [e-mail]:
https://hg.mozilla.org/integration/autoland/rev/827ffc5edb15
Don't restore scrolldata and form data when switching processes. r=droeh

Comment 13

[Andreea Pavel [:apavel]]

https://hg.mozilla.org/mozilla-central/rev/827ffc5edb15