browser_ext_windows_size.js expects windows.update() to clamp an off-screen position to (0, 0) rather than to the screen's available origin
Categories
(WebExtensions :: Frontend, defect, P3)
Tracking
(firefox156 fixed)
| Tracking | Status | |
|---|---|---|
| firefox156 | --- | fixed |
People
(Reporter: florian, Assigned: florian)
References
(Blocks 1 open bug)
Details
Attachments
(1 file)
sanitizePositionParams() clamps a requested window position to the screen's available rect offset by the widget's screen edge slop. On macOS that rect is [NSScreen visibleFrame], which excludes the menu bar, and GetScreenEdgeSlop() is overridden only on GTK, so requesting top: -50 puts the window at the bottom of the menu bar rather than at y = 0.
The test asserted the clamped position was exactly (0, 0), which holds only where the available rect starts at the screen origin. That expectation was written in bug 1271047 at a time when the test had already been skipped on mac since 2016, so it was never once exercised on a platform with a menu bar.
On try, macosx1015-64-qr opt and debug failed 12/12 with Expected 'top' value - Expected: 0, Actual: 23 and only that assertion, through all five 200 ms retries and the fresh-browser rerun. 23 is the menu bar height on those workers, measured from the failure screenshot, where the menu bar occupies rows y = 0..22 of the 1920x1080 screen. The fix reads screen.availTop/availLeft at runtime instead.
All three mac conditions descend from one os == 'mac' blanket skip added in bug 1253133 in 2016, in the same patch that added windows.update()'s geometry support and this test, whose stated reason ("Fails when windows are randomly opened in fullscreen mode") is unrelated and is contradicted by that push, where all 12 runs got the exact sizes they requested. Bug 1881925 split it per version and dropped the comment, and bugs 1919776 and 1948426 re-spelled it.
|
Assignee | |
Comment 1•29 days ago
|
||
sanitizePositionParams() clamps a requested window position to the
screen's available rect (nsIScreen::GetAvailRectDisplayPix), offset by the
widget's screen edge slop. On macOS that rect is [NSScreen visibleFrame],
which excludes the menu bar, and GetScreenEdgeSlop() is only overridden on
GTK, so requesting top: -50 puts the window at the bottom of the menu bar
rather than at y = 0.
The test asserted the clamped position was exactly (0, 0), which only
holds when the available rect starts at the screen origin. That
expectation was written in bug 1271047 when the clamping was introduced,
at a time when the test had already been skipped on mac since 2016, so it
was never exercised on a platform with a menu bar. Compare against the
screen's available origin instead, read at runtime, so the expectation no
longer encodes where that origin happens to be.
All three mac conditions are removed, not only the mac 10.15 one a try
push can exercise: neither the cause nor the fix is macOS-version
specific, since visibleFrame excludes the menu bar on every version and
the expectation is now read from screen.availTop instead of being written
down. macosx1470 runs no mochitest-browser-chrome job at all, so that
condition matches nothing; macOS 15.30 aarch64 browser-chrome exists only
under --full and is not verified here.
|
||
Updated•28 days ago
|
Backed out for causing bc failures @browser_ext_url_overrides_newtab.js.
|
||
Comment 5•24 days ago
|
||
| bugherder | ||
Description
•