Open Bug 1791342 Opened 3 years ago Updated 2 years ago

[Bug]: Browser width/height are not updated when orientation changes

Categories

(Core :: Layout: Scrolling and Overflow, defect, P3)

Unspecified
Android
defect

Tracking

()

People

(Reporter: petru, Unassigned)

References

(Depends on 1 open bug, Blocks 1 open bug)

Details

Attachments

(1 obsolete file)

From github: https://github.com/mozilla-mobile/fenix/issues/27052.

Steps to reproduce

  1. activate 'Scroll to hide toolbar' in the settings ( settings -> customize -> scroll to hide toolbar )
  2. open an html file and scroll to hide the toolbar
  3. set your device in 'portrait' orientation
  4. look the values of height and width in window. visualViewport. The height is greater than the width (ok it's portait)
  5. set your device in 'landscape' orientation
  6. look the values of height and width in window. visualViewport. The height remains greater than the width ( not ok )
  7. scroll to show the toolbar and do the same tests. Height and width are now correct and adapted to the device rotation
  8. see in the device logs the html file used for tests (renamed index.txt...)

Expected behaviour

The width and height have to be adapted with the device orientation.

Actual behaviour

width and height are not changed when the toolbar is hidden with a scroll

Device name

Samsung Galaxy tab A7 lite SM-T225

Android version

Android 11

Firefox release type

Firefox

Firefox version

104.2.0

Device logs

index.txt

Additional information

No response

┆Issue is synchronized with this Jira Task

Change performed by the Move to Bugzilla add-on.

Hmm, the bug might be that we call presShell->GetVisualViewportSizeUpdatedByDynamicToolbar() here
https://searchfox.org/mozilla-central/rev/d8d75a05deaba7e89a6f1d4c1f197d01e2361d43/dom/base/VisualViewport.cpp#78

which can return mMobileViewportManager->GetVisualViewportSizeUpdatedByDynamicToolbar()
https://searchfox.org/mozilla-central/rev/d8d75a05deaba7e89a6f1d4c1f197d01e2361d43/layout/base/PresShell.cpp#11409

And the value that that function returns is only updated when nsPresContext::UpdateDynamicToolbarOffset is called. Presumably we need to update it also when the visual viewport changes too.

nsPresContext::UpdateDynamicToolbarOffset isn't the one, it's supposed to be called when the dynamic toolbar is moving, i.e. being collapsed or being expanded. nsPresContext::SetDynamicToolbarMaxHeight is the one, but it makes me suspect Fenix (or GeckoView) doesn't invoke GeckoView.setDynamicToolbarMaxHeight on the device rotation?

I suppose that the toolbar height can vary on portrait/landscape modes so that the browsers (in this case it's Fenix) need to invoke GeckoView.setDynamicToolbarMaxHeight, no? Petru?

Flags: needinfo?(petru.lingurar)

(In reply to Hiroyuki Ikezoe (:hiro) from comment #4)

I suppose that the toolbar height can vary on portrait/landscape modes so that the browsers (in this case it's Fenix) need to invoke GeckoView.setDynamicToolbarMaxHeight, no? Petru?

We don't technically have different layouts for portrait / landscape - as that would mean we support Android restarting the Activity upon rotation, which we want to avoid.
So the toolbar height is the same in portrait or landscape and once set we don't call again setDynamicToolbarMaxHeight in changing orientation scenarios - we would afterwards call this method again only for fullscreen changes.

Flags: needinfo?(petru.lingurar)

Oh okay, then my wild guess is this is a case of bug 1641166, I guess visualViewport.scale values on portrait/landcape modes are different. I suppose the index.txt is a test case to see this issue, it's an HTML file though, there's no meta viewport tag, so that it's laid out on 980px width just as desktop mode so that it's basically scaled to the minimum-scale size.

Depends on: 1641166

Setting P3:S3 since minimum-scale size is relatively uncommon. Petru, if you see this issue on normal documents having <meta name=viewport content=device-width> or some such. Please attach the case here. Thanks!

Severity: -- → S3
Priority: -- → P3
Attachment #9387189 - Attachment is obsolete: true
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Creator:
Created:
Updated:
Size: