browser.windows.create - broken in versions after v100 with hiDPI screens
Categories
(WebExtensions :: Untriaged, defect)
Tracking
(Not tracked)
People
(Reporter: n.tinkler, Unassigned, NeedInfo)
Details
(Keywords: regressionwindow-wanted)
Attachments
(2 files)
User Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10_15_7) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/104.0.0.0 Safari/537.36
Steps to reproduce:
I ran the following code in a persistent background script of a manifest v2 web extension running in Firefox. I am running on a hiDPI screen (two external 4k monitors, macOS Monteray v12.4).
Please see this screen recording of the issue - Versions 100 and below do not appear to have this bug: https://monosnap.com/file/80IEHdqgSVND0ZsXKtXkxVPsNINSQd
const width = props.width ?? Math.round(window.screen.width * 0.8);
const height = props.height ?? Math.round(window.screen.height * 0.8);
// center by default
const top = props.top ?? Math.round(window.screen.height / 2 - height / 2);
const left = props.left ?? Math.round(window.screen.width / 2 - width / 2);
console.log(
`In openWindow width ${width} height ${height} top ${top} left ${left}`
);
const newWindow = await browser.windows.create({
url: props.url,
width,
height,
top,
left,
type: 'popup',
});
Actual results:
The resulting window is not correctly sized. It is very small, and positioned in the upper left of desktop.
This behavior is not present in older versions (as recently as v100)
Expected results:
The resulting window should have been centered on the current screen, and take roughly 80% of the available height and width.
The correct behavior can be seen in this screenshot: https://monosnap.com/file/5UdKaS6hHzPapDQNrgxSWRxlIyFaUt
The incorrect behavior can be seen in this screenshot:
https://monosnap.com/file/BId1l07vo41NIq6RZZfyyuonqKWA8b
Comment 2•2 years ago
|
||
Could you find a regression range?
https://mozilla.github.io/mozregression/
Comment 3•2 years ago
|
||
The Bugbug bot thinks this bug should belong to the 'WebExtensions::Untriaged' component, and is moving the bug to that component. Please correct in case you think the bot is wrong.
Updated•2 years ago
|
Comment 4•2 years ago
|
||
Hello,
I’m from QA and trying to find the regression range and would require a test extension for this.
I’ve already tried modifying an extension to run the provided code in a background script, as you mentioned, but got all sorts of errors.
If you would be so kind as to provide a test extension, that would be great.
Also, you mentioned hiDPI displays. Do you think a MacBook with a 12-inch Retina display would be sufficient to reproduce this bug? This is, unfortunately, the highest resolution/DPI device I have at my disposal.
Comment 5•2 years ago
|
||
This looks very similar to what I have reported (for high density screens on Windows) in bug 1798213: https://bugzilla.mozilla.org/show_bug.cgi?id=1798213
I would be very surprised if "my bug" goes all the way back to Firefox 103 as stated in this bug. I'm guessing my issue started just recently with Firefox 106. But bug descriptions look very similar...
I have attached an "example webextension" to my bug, logging window.screen properties which I found to be guilty of issue on my Windows setups. My webextensions logs window.screen properties as expected when running on Firefox 102 ESR (Waterfox) or on Chrome 107. But with Firefox 106 window.screen - when read from a backgroundscript - returns "physical pixel" dimensions instead of expected "virtual pixel" dimensions.
Updated•2 years ago
|
Description
•