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. https://temp.chrismorgan.info/safe-area-inset.html (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.

Regression window:
https://hg.mozilla.org/integration/autoland/pushloghtml?fromchange=a599c79ed65176fd4e66394d1144f61931def4c9&tochange=27faa3b167a92b7a6bb1bf09badc080d7ff6dd8c

I am looking this

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

[Tracking Requested - why for this release]:

https://treeherder.mozilla.org/#/jobs?repo=try&revision=f8725fc72767887ba8ef909f3793f026f9b61bc0

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.

https://hg.mozilla.org/mozilla-central/rev/1e3252f1e051

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 https://webkit.org/demos/safe-area-insets/3-safe-area-constants.html
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

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

approved for 75.0b8

https://hg.mozilla.org/releases/mozilla-beta/rev/2ad99717bc06

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.