On X11 `mozInnerScreenX/Y` are ignored for the first test that runs in a
new popup. For Wayland positions during resize tests are ignored, and
`browser_popup_linux_move.js` is just a todo checking whether we can
move a window at all.
Also allows to run the tests with `resizeTo` and `moveTo` when size and
position property setters are disabled.
Differential Revision: https://phabricator.services.mozilla.com/D169963
Implementations of nsIEmbeddingSiteWindow and nsIBaseWindow largely
overlap, and where they don't, the nsIEmbeddingSiteWindow implementation
of the otherwise shared interface is primarily stubbed out with the
exception of Get/SetDimensions().
This patch moves a reimplementation of Get/SetDimensions() from
nsIEmbeddingSiteWindow to nsIBaseWindow. The other methods of
nsIEmbeddingSiteWindow remain covered by nsIBaseWindow.
Get/SetDimensions() can be implemented as part of nsIWebBrowserChrome
where nsIBaseWindow is not necessary. This removes the need for
nsIEmbeddingSiteWindow.
Blur() has also been moved to nsIWebBrowserChrome, as only
nsContentTreeOwner has an actual implementation which we in theory also
want to call from BrowserChild/Parent, but the spec suggests to
"selectively or uniformly ignore calls".
GetVisibility() had an implementation in BrowserChild that pretended to
always be visible. Instead of providing an interface for that,
nsDocShell now handles the not implemented case for tree owners.
nsIEmbeddingSiteWindow::GetSiteWindow() used to call through to
nsIBaseWindow::GetParentNativeWindow().
The Get/SetDimensions() implementation has been replaced with a strongly
typed setter, which is now also used directly from nsGlobalWindowOuter
to avoid problems that come with autodetecting unchanged dimensions,
when the current dimensions are outdated (e.g. immediately reverting a
change can be ignored).
Differential Revision: https://phabricator.services.mozilla.com/D160260
Implementations of nsIEmbeddingSiteWindow and nsIBaseWindow largely
overlap, and where they don't, the nsIEmbeddingSiteWindow implementation
of the otherwise shared interface is primarily stubbed out with the
exception of Get/SetDimensions().
This patch moves a reimplementation of Get/SetDimensions() from
nsIEmbeddingSiteWindow to nsIBaseWindow. The other methods of
nsIEmbeddingSiteWindow remain covered by nsIBaseWindow.
Get/SetDimensions() can be implemented as part of nsIWebBrowserChrome
where nsIBaseWindow is not necessary. This removes the need for
nsIEmbeddingSiteWindow.
Blur() has also been moved to nsIWebBrowserChrome, as only
nsContentTreeOwner has an actual implementation which we in theory also
want to call from BrowserChild/Parent, but the spec suggests to
"selectively or uniformly ignore calls".
GetVisibility() had an implementation in BrowserChild that pretended to
always be visible. Instead of providing an interface for that,
nsDocShell now handles the not implemented case for tree owners.
nsIEmbeddingSiteWindow::GetSiteWindow() used to call through to
nsIBaseWindow::GetParentNativeWindow().
The Get/SetDimensions() implementation has been replaced with a strongly
typed setter, which is now also used directly from nsGlobalWindowOuter
to avoid problems that come with autodetecting unchanged dimensions,
when the current dimensions are outdated (e.g. immediately reverting a
change can be ignored).
Differential Revision: https://phabricator.services.mozilla.com/D160260
Implementations of nsIEmbeddingSiteWindow and nsIBaseWindow largely
overlap, and where they don't, the nsIEmbeddingSiteWindow implementation
of the otherwise shared interface is primarily stubbed out with the
exception of Get/SetDimensions().
This patch moves a reimplementation of Get/SetDimensions() from
nsIEmbeddingSiteWindow to nsIBaseWindow. The other methods of
nsIEmbeddingSiteWindow remain covered by nsIBaseWindow.
Get/SetDimensions() can be implemented as part of nsIWebBrowserChrome
where nsIBaseWindow is not necessary. This removes the need for
nsIEmbeddingSiteWindow.
Blur() has also been moved to nsIWebBrowserChrome, as only
nsContentTreeOwner has an actual implementation which we in theory also
want to call from BrowserChild/Parent, but the spec suggests to
"selectively or uniformly ignore calls".
GetVisibility() had an implementation in BrowserChild that pretended to
always be visible. Instead of providing an interface for that,
nsDocShell now handles the not implemented case for tree owners.
nsIEmbeddingSiteWindow::GetSiteWindow() used to call through to
nsIBaseWindow::GetParentNativeWindow().
The Get/SetDimensions() implementation has been replaced with a strongly
typed setter, which is now also used directly from nsGlobalWindowOuter
to avoid problems that come with autodetecting unchanged dimensions,
when the current dimensions are outdated (e.g. immediately reverting a
change can be ignored).
Differential Revision: https://phabricator.services.mozilla.com/D160260
Without flushing the layout, new windows appear to the opener to
initially open at the size of the opener instead of the specified size.
We can flush the layout unconditionally when we have a specified size
where we otherwise would make sure that the frame loader has been
reflowed at least once.
Thanks to Emilio for providing the changes to avoid tokenizing the
window features twice.
Differential Revision: https://phabricator.services.mozilla.com/D158584
Updating mBounds.Size() without calling WindowResized leaves the window
temporarily in a state where inner and outer sizes are out of sync.
BrowserParent::UpdatePosition should call BrowserParent::UpdateDimension
with the size during the last update, rather than the current window
size. There is an edge case where a call can happen between a resize and
its reflow, and a second resize could prevent the reflow from changing
the frame loader size, leaving the BrowserChild with an outdated outer
size.
Differential Revision: https://phabricator.services.mozilla.com/D158343
The first size-allocate is likely (or guaranteed) to be of the size at
the time of the first NativeShow(true) call. Any resize between show and
the first size-allocate will be accounted for in a second size-allocate
signal. If we update and dispatch the window size at the beginning of
such a resize, we end up reverting back to previous size from the first
size-allocate signal before dispatching the size for the resize again
from the second size-allocate signal.
Differential Revision: https://phabricator.services.mozilla.com/D158580
To more properly support Linux having a different default at runtime.
Expose the resolved value in appinfo for convenience, and use it in the
front-end as needed.
Differential Revision: https://phabricator.services.mozilla.com/D129004
