After some research I've realized that the centerscreen feature triggers this problem.

On Google Chrome windows.create() accepts left and top for popup type windows, and omitted coordinates are filled with "(left of the last normal window + 10, top of the last normal window + 10)". So my patch does same thing on Firefox, except applying centerscreen if both left and top are omitted.

(In reply to Andy McKay from comment #3)

Note that changing left and top works great by using
window.update, so there's a valid workaround for developers until we can fix
this.

But this workaround means the window first appears in the middle of the screen and only then is moved to the wished position, making it a rather ugly hack. Or am I missing something?

Correct .. kind of annoying for users, who come and complain about it to me as add-on author .. but there's nothing I can do so far.

If you want to get a patch landed, please go to the revision in Phabricator, click "Edit Revision" on the top right and add the "CheckinNeeded" tag. Thank you.

Oh thanks! I didn't know the workflow was changed.

Backed out for failures on browser_ext_windows_create_params.js

backout: https://hg.mozilla.org/integration/autoland/rev/7f8b25d9a7668670eebfec6df1a6d63ef7527c35

push: https://treeherder.mozilla.org/#/jobs?repo=autoland&selectedTaskRun=QDtwUloKTT2VQ2y3MxwMHw.0&revision=ad64957cf6554db1fabec6692b46f1e1c2c5f5a0&group_state=expanded

failure log: https://treeherder.mozilla.org/logviewer.html#/jobs?job_id=310138911&repo=autoland&lineNumber=24865

[task 2020-07-17T09:19:15.115Z] 09:19:15 INFO - TEST-PASS | browser/components/extensions/test/browser/browser_ext_windows_create_params.js | test result correct -
[task 2020-07-17T09:19:15.115Z] 09:19:15 INFO - Leaving test bound testWindowCreateParams
[task 2020-07-17T09:19:15.115Z] 09:19:15 INFO - Entering test bound testPopupTypeWithCoordinates
[task 2020-07-17T09:19:15.115Z] 09:19:15 INFO - Extension loaded
[task 2020-07-17T09:19:15.116Z] 09:19:15 INFO - Console message: Warning: attempting to write 42195 bytes to preference extensions.webextensions.uuids. This is bad for general performance and memory usage. Such an amount of data should rather be written to an external file. This preference will not be sent to any content processes.
[task 2020-07-17T09:19:15.116Z] 09:19:15 INFO - Buffered messages finished
[task 2020-07-17T09:19:15.117Z] 09:19:15 INFO - TEST-UNEXPECTED-FAIL | browser/components/extensions/test/browser/browser_ext_windows_create_params.js | expected popup type windows are opened at given coordinates - Got 123,123 / 123,60 / 60,123 / 1450,1013 / 0,27, expected 123,123 / 123,60 / 60,123 / 1450,1050 / 0,27
[task 2020-07-17T09:19:15.117Z] 09:19:15 INFO - Stack trace:
[task 2020-07-17T09:19:15.117Z] 09:19:15 INFO - chrome://mochikit/content/browser-test.js:test_is:1327
[task 2020-07-17T09:19:15.117Z] 09:19:15 INFO - chrome://mochitests/content/browser/browser/components/extensions/test/browser/browser_ext_windows_create_params.js:testPopupTypeWithCoordinates:122

Another failure: https://treeherder.mozilla.org/logviewer.html#/jobs?job_id=310138819&repo=autoland&lineNumber=41937

The test looked to be failed due to difference of screen.width/height and screen.availWidth/availHeight. The purpose of failed assertions is asserting that the window won't be placed out of the visible area. So I've separated assertions for the purpose and just compare whether the actual coordinates are inside of the visible area instead of exact same to the expected coordinates.

I've not tested this change on the tryserver because my Mercurial access is currently disabled from my too long suspend...

There seems to be a new bug confusing virtual and physical pixels (at least my theory so far) when updating size and position with browser.windows.update().

Updating size and position still works correctly (or as it used to) on screens where physical and virtual pixel size are the same. But on high density screens, the behaviour has changed recently. Probably with release of Firefox 106(?).

I probably need to investigate a bit more before I officially file a bug. But looks like related to the scaling factor between logical and physical pixels.
Anyone else noticed new behaviours?

Tested on Win11 with a couple of PCs and screens. I will test a bit more on differently configured PCs the coming days (but probably still only Windows)...

There's a r+ patch which didn't land and no activity in this bug for 2 weeks.
:yuki, could you have a look please?
If you still have some work to do, you can add an action "Plan Changes" in Phabricator.
For more information, please visit auto_nag documentation.

I've updated the patch based on the latest mozilla-central and it also includes some fixes from review comments.

Phabricator says as "This revision is now accepted and ready to land". Should I set "chckin-needed" without more review for updates?

FYI, the bug I talked about in comment 20 is (became) https://bugzilla.mozilla.org/show_bug.cgi?id=1798213
Maybe at first slightly offtopic for this bug. But on the other hand maybe a bit relevant to know if fix for 1798213 is also included when testing a fix for this bug(?)

I've tried setting the checkin-needed to the keyword field but the bugzilla said "Value is Not Active / The keyword value 'checkin-needed' is not active", so I added it to the whiteboard field. I couldn't find out descriptions about the checkin-needed keywoard at https://firefox-source-docs.mozilla.org/contributing/how_to_submit_a_patch.html and other documents on firefox-source-docs.mozilla.org. Is there any document for this case?

Landing has been requested.

The checkin-needed keyword got removed. Please request landing from the patch reviewer for future patch submissions, see https://firefox-source-docs.mozilla.org/contributing/how_to_submit_a_patch.html#pushing-the-change

Backed out for causing mochitest failures on browser_ext_windows_size.js

• Backout link
• Push with failures
• Failure Log
• Failure line: TEST-UNEXPECTED-FAIL | browser/components/extensions/test/browser/browser_ext_windows_size.js | Expected 'left' value - Expected: -50, Actual: 0 -

https://hg.mozilla.org/mozilla-central/rev/69deea558245