Closed Bug 1621241 Opened 4 years ago Closed 4 years ago

Safe area insets (right and bottom) become wrong on resize


(Core :: CSS Parsing and Computation, defect, P1)

76 Branch



Tracking Status
firefox-esr68 --- unaffected
firefox73 --- unaffected
firefox74 --- unaffected
firefox75 --- verified
firefox76 --- verified


(Reporter: me, Assigned: m_kato)




(Keywords: regression)


(1 file)

User Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:76.0) Gecko/20100101 Firefox/76.0

Steps to reproduce:

  1. Use a platform where safe area insets should always be zero (e.g. Windows).
  2. Play around with anything that uses safe area insets, e.g. (shows the numbers and highlights the safe area insets on the viewport).
  3. Resize the viewport after loading the document.

Actual results:

Although on page load the safe area insets are zero, on resize, the bottom and right safe area insets become non-zero, seeming to duplicating the space allocations of UI elements from the opposite side.

I’m seeing env(safe-area-inset-bottom) becoming 28.5px when the window is maximised, or 25px when the window is not maximised. (These numbers look about right to correspond to the title bar in some way, though not directly as with the sidebar about to be discussed. I also have #TabsToolbar hidden via userChrome.css, but I don’t believe that’s relevant.)

I have a sidebar (Tree Style Tab) open normally, and when it’s open the browser seems to want to limit the safe area to the screen width minus twice the sidebar width. That is, with a 1500px-wide screen, a maximised window (outerWidth ~1500px) and a 200px sidebar (hence innerWidth 1300px), safe-area-inset-right will be 200px, and the safe area 1100px wide; unmaximising the window to 1400px wide (innerWidth 1200px), safe-area-inset-right will be 100px (again safe area 1100px wide). Shrink it further and by 1300px wide (innerWidth 1100px) safe-area-inset-right will have reached zero, where it will stay. (I confess that I’m now trying to imagine a situation in which negative safe area insets would be reasonable!)

My device has a scaling factor of 2×, but I do not believe that this is relevant—I switched it to 1× briefly to be reasonably sure (though without restarting everything).

Expected results:

The safe area insets should have stayed at zero.

This is a fairly recent regression, probably from the last week, fairly certainly from the last two.

Has Regression Range: --- → yes
OS: Unspecified → All
Hardware: Unspecified → Desktop
Flags: needinfo?(m_kato)

I am looking this

Assignee: nobody → m_kato
Flags: needinfo?(m_kato)

Makoto, thank you for taking this. Could you please set the priority flag?

Ever confirmed: true
Flags: needinfo?(m_kato)

[Tracking Requested - why for this release]:

Flags: needinfo?(m_kato)
Priority: -- → P1

This is a mistake implementation of cutout support.

When OS/device doesn't support cutout (safe-area-insets-*), widget returns 0 for safe area insets values.
So if it is 0, we shouldn't set safe-area-insets.

Also, I will add test for this by bug 1622713. Actually, no Android emulator that supports notch.

Pushed by
Don't apply safe-area-insets-* if device doesn't have cutout area. r=smaug
Closed: 4 years ago
Resolution: --- → FIXED
Target Milestone: --- → mozilla76

Comment on attachment 9134053 [details]
Bug 1621241 - Don't apply safe-area-insets-* if device doesn't have cutout area.

Beta/Release Uplift Approval Request

  • User impact if declined: When using env(safe-area-insets-bottom) in CSS, safe-area-insets-bottom may return non-zero value on Firefox desktop even if no notch device.
  • Is this code covered by automated tests?: No
  • Has the fix been verified in Nightly?: Yes
  • Needs manual test from QE?: Yes
  • If yes, steps to reproduce: - Step
  1. Browse
  2. Set window size to maximum
  • Result
    footer height is unchanged
  • List of other uplifts needed: None
  • Risk to taking this patch: Low
  • Why is the change risky/not risky? (and alternatives if risky): It is unnecessary to calculate safe-area-insets-* values if no notch device. So it is ignore this on all desktop browser.
  • String changes made/needed: none
Attachment #9134053 - Flags: approval-mozilla-beta?
Flags: qe-verify+
QA Whiteboard: [qa-triaged]

Comment on attachment 9134053 [details]
Bug 1621241 - Don't apply safe-area-insets-* if device doesn't have cutout area.

approved for 75.0b8

Attachment #9134053 - Flags: approval-mozilla-beta? → approval-mozilla-beta+

Hello! I have managed to reproduce the issue Windows 10 using Fx Nightly 76.0a1 (2020-03-09). I can confirm that the issue is fixed in the build provided in comment 11 and on Fx Nightly 76.0a1 (2020-03-24) on all OS's.

QA Whiteboard: [qa-triaged]
Flags: qe-verify+
You need to log in before you can comment on or make changes to this bug.