windows.create and windows.update ignore window position coordinates for type panel and popup

NEW
Unassigned

Status

P3
normal
a year ago
4 months ago

People

(Reporter: u462496, Unassigned)

Tracking

(Blocks: 1 bug)

Firefox Tracking Flags

(Not tracked)

Details

(Reporter)

Description

a year ago
windows.create and windows.update ignore window position coordinates if window is created with type: "panel" or "popup".  This is documented as normal behavior.

This allows no way to move the window programmatically.  window.moveTo() from the panel's script will not work either.

This means there is no way to persist last window position when the window is closed and re-opened.  Re-opening the window always opens in the center of the screen.

This would be very annoying to users.
(In reply to Kevin Jones from comment #0)
> This is documented as normal behavior.

This is the case because type=panel windows used to be chat-like windows in Chrome, which means they don't support changing the position: https://i.ytimg.com/vi/9Qzn9OXvc9s/maxresdefault.jpg

Since Chrome 54, type=panel windows are simply windows with no url bar, which aligns with the current behaviour in Firefox.
IMO, it makes sense to start allowing changing coordinates now that both browsers don't support sticky panels.

Updated

a year ago
Priority: -- → P3

Updated

a year ago
Blocks: 1226547

Comment 3

a year ago
An Adblock Plus user noticed that this window always appears centered on the primary monitor, even if the active browser window is on another monitor. That's very suboptimal.

Comment 4

a year ago
(In reply to Tim Nguyen :ntim from comment #2)
> This is the code that currently forbids this in Firefox:
> https://dxr.mozilla.org/mozilla-central/source/browser/components/extensions/
> ext-windows.js#198-203

This is different, it forbids the use of the "state" property in conjunction with top/left/width/height. "state" can be something like "minimized", "maximized", "fullscreen", etc. For these states, a width/height/position does obviously not make any sense.
I have witnessed that a window with "type":"popup" can change top/left/width/height when I use the browser.windows.update API. This is on Linux, X11, KWin.


(In reply to Wladimir Palant (for Adblock Plus info Cc bugzilla@adblockplus.org) from comment #3)
> An Adblock Plus user noticed that this window always appears centered on the
> primary monitor, even if the active browser window is on another monitor.
> That's very suboptimal.

Are you sure that this is a bug with Firefox?
I reviewed ABP's source code (v3.0.1) and cannot find any use of "create", "update" (of the browser.windows API), or "moveTo" that explicitly positions the window.
I create windows with an explicit position, and when I manually center a window, I apparently have to add screen.left/screen.top to get a proper position in a multi-display setup - https://github.com/Rob--W/open-in-browser/issues/6

Comment 5

a year ago
(In reply to Rob Wu [:robwu] from comment #4)
> Are you sure that this is a bug with Firefox?
> I reviewed ABP's source code (v3.0.1) and cannot find any use of "create",
> "update" (of the browser.windows API), or "moveTo" that explicitly positions
> the window.

Yes, definitely a Firefox bug, the same code in Chrome positions the window correctly in Chrome. The line in question is https://hg.adblockplus.org/adblockpluschrome/file/fe75016a7373/lib/filterComposer.js#l218 - the window opens in the top-left screen corner in Chrome and centered in Firefox. We'd like to address the issue with multi-display setup but that's not possible if Firefox overrides our position. Note that this is only about windows with type: "popup", regular browser windows can be positioned just fine.

Comment 6

a year ago
(In reply to Wladimir Palant (for Adblock Plus info Cc bugzilla@adblockplus.org) from comment #5)
> We'd like to address the issue with
> multi-display setup but that's not possible if Firefox overrides our
> position. Note that this is only about windows with type: "popup", regular
> browser windows can be positioned just fine.

A work-around is to use chrome.windows.update(windowId, {top: ... , left: ...}) in the callback of chrome.windows.create (and if that does not work, add a delay before calling chrome.windows.update).

When either top or left is set, the implementation delegates to window.resizeTo:
https://searchfox.org/mozilla-central/rev/bab833ebeef6b2202e71f81d225b968283521fd6/browser/components/extensions/ext-browser.js#745-752


I tried the following snippet from a privileged page (e.g. about:debugging) and observed that the window won't move (but it does resize; whether resizeTo is called does not matter):
sleep = ms=>new Promise(r=>setTimeout(r,ms));

w = window.open('chrome://browser/content/browser.xul', '', 'chrome,dialog,centerscreen,titlebar,close');
w.resizeTo(100,100);
w.moveTo(0,0);

The following snippet seems to work though (i.e. the window is resized and moved):

w = window.open('chrome://browser/content/browser.xul', '', 'chrome,dialog,centerscreen,titlebar,close');
w.addEventListener("pageshow", () => {
  setTimeout( () => {
    w.resizeTo(100,100);
    w.moveTo(0,0);
  });
});

Comment 7

9 months ago
Please this bug needs to be fixed.

Updated

6 months ago
Product: Toolkit → WebExtensions
You need to log in before you can comment on or make changes to this bug.