When entering fullscreen and saving the original position of a window,
also save the position to which it was moved.
When leaving fullscreen, keep the window on the same screen. Restore its
_screen-relative_ position, rather than its absolute position.
Differential Revision: https://phabricator.services.mozilla.com/D153410
`HideWindowChrome(false)` may change the reported window size on Mac:
the OS menu bar appears at the top of the screen, and this will cause the
window to shrink if it was fullscreen.
This isn't a problem yet, since we don't check the window dimensions
when exiting fullscreen... but the following commit will do exactly
that. Delay calling `HideWindowChrome` until the last possible minute --
but make sure that it _does_ get called.
Since HideWindowChrome(true) does not presently change the window size
(see bug 498835), no functional changes.
Differential Revision: https://phabricator.services.mozilla.com/D154469
Use desktop pixels everywhere:
- Store the old window position as a `DesktopRect`.
- Since `GetRectDisplayPix` is infallible, use the convenience getter
that hands us a `DesktopIntRect`.
- Add a helper function that wraps `Resize()` and takes any `Rect`
which uses `DesktopPixel`s.
No functional changes.
Differential Revision: https://phabricator.services.mozilla.com/D153409
A window is fullscreenable iff it's a desktop window (that is, a
positional child of the desktop rather than of another window) -- and
desktop windows are the windows which use desktop-pixel units in
Resize().
Code coverage confirms that the branch when `BoundsUseDesktopPixels()`
returns `false` is never taken in tests.
Under the (hopefully justified) assumption that it's never taken at all,
no functional changes.
Differential Revision: https://phabricator.services.mozilla.com/D153408
Otherwise, it changes the move-to-rect inputs, which can change the
output as well, making us move the anchor all the way to the right.
You could, I guess, consider this a mutter bug of sorts, because it
feels weird that you pass it an anchor that has been a `move-to-rect`
output and you get another rect as an output.
But also, it's kinda silly that we're doing that to begin with, so avoid
it by telling the popup frame whether it's been positioned / moved by
move-to-rect (and keeping the anchor in that case).
The reason this works on my setup without "Large text" is just dumb luck
(the front-end computes a max-height for the panel that is small enough
to fit on the screen).
Differential Revision: https://phabricator.services.mozilla.com/D155406
Otherwise, it changes the move-to-rect inputs, which can change the
output as well, making us move the anchor all the way to the right.
You could, I guess, consider this a mutter bug of sorts, because it
feels weird that you pass it an anchor that has been a `move-to-rect`
output and you get another rect as an output.
But also, it's kinda silly that we're doing that to begin with, so avoid
it by telling the popup frame whether it's been positioned / moved by
move-to-rect (and keeping the anchor in that case).
The reason this works on my setup without "Large text" is just dumb luck
(the front-end computes a max-height for the panel that is small enough
to fit on the screen).
Differential Revision: https://phabricator.services.mozilla.com/D155406
When entering fullscreen and saving the original position of a window,
also save the original position of its screen.
When leaving fullscreen, keep the window on the same screen. Restore its
_screen-relative_ position, rather than its absolute position.
Differential Revision: https://phabricator.services.mozilla.com/D153410
`HideWindowChrome(false)` may change the reported window size on Mac:
the OS menu bar appears at the top of the screen, and this will cause the
window to shrink if it was fullscreen.
This isn't a problem yet, since we don't check the window dimensions
when exiting fullscreen... but the following commit will do exactly
that. Delay calling `HideWindowChrome` until the last possible minute --
but make sure that it _does_ get called.
Since HideWindowChrome(true) does not presently change the window size
(see bug 498835), no functional changes.
Differential Revision: https://phabricator.services.mozilla.com/D154469
Use desktop pixels everywhere:
- Store the old window position as a `DesktopRect`.
- Since `GetRectDisplayPix` is infallible, use the convenience getter
that hands us a `DesktopIntRect`.
- Add a helper function that wraps `Resize()` and takes any `Rect`
which uses `DesktopPixel`s.
No functional changes.
Differential Revision: https://phabricator.services.mozilla.com/D153409
A window is fullscreenable iff it's a desktop window (that is, a
positional child of the desktop rather than of another window) -- and
desktop windows are the windows which use desktop-pixel units in
Resize().
Code coverage confirms that the branch when `BoundsUseDesktopPixels()`
returns `false` is never taken in tests.
Under the (hopefully justified) assumption that it's never taken at all,
no functional changes.
Differential Revision: https://phabricator.services.mozilla.com/D153408
Make RevokeTransactionIdAllocator() call part of nsBaseWidget::DestroyCompositor() so we don't need to do extra call.
Depends on D154004
Differential Revision: https://phabricator.services.mozilla.com/D154005
When entering fullscreen and saving the original position of a window,
also save the original position of its screen.
When leaving fullscreen, keep the window on the same screen. Restore its
_screen-relative_ position, rather than its absolute position.
Differential Revision: https://phabricator.services.mozilla.com/D153410
Use desktop pixels everywhere:
- Store the old window position as a `DesktopRect`.
- Since `GetRectDisplayPix` is infallible, use the convenience getter
that hands us a `DesktopIntRect`.
- Add a helper function that wraps `Resize()` and takes any `Rect`
which uses `DesktopPixel`s.
No functional changes.
Differential Revision: https://phabricator.services.mozilla.com/D153409
A window is fullscreenable iff it's a desktop window (that is, a
positional child of the desktop rather than of another window) -- and
desktop windows are the windows which use desktop-pixel units in
Resize().
Code coverage confirms that the branch when `BoundsUseDesktopPixels()`
returns `false` is never taken in tests.
Under the (hopefully justified) assumption that it's never taken at all,
no functional changes.
Differential Revision: https://phabricator.services.mozilla.com/D153408
It's used by the DevTools to emulate touch events from mouse events in the
responsive design mode. Therefore, we should make it accept IPC messages
even if it's not in the automation mode, but it's in the responsive design mode.
Differential Revision: https://phabricator.services.mozilla.com/D148365
All users of nsIWidget::GetVsyncSource just want the dispatcher anyway.
Getting the dispatcher directly from the widget will allow us to remove VsyncSource::GetVsyncDispatcher.
Differential Revision: https://phabricator.services.mozilla.com/D144374
This makes it so that the VsyncSource doesn't need to keep track of the compositor vsync dispatchers.
And the moving-between-sources logic needs to be handled only for the VsyncDispatcher.
Once we have one VsyncDispatcher per window, we can probably eliminate CompositorVsyncDispatcher.
Differential Revision: https://phabricator.services.mozilla.com/D144366
This makes it so that the VsyncSource doesn't need to keep track of the compositor vsync dispatchers.
And the moving-between-sources logic needs to be handled only for the VsyncDispatcher.
Once we have one VsyncDispatcher per window, we can probably eliminate CompositorVsyncDispatcher.
Differential Revision: https://phabricator.services.mozilla.com/D144366
This member is no longer used on Windows, and having it in the
base class doesn't provide a real abstraction anyway since
the child classes will break if anything about it is changed.
Differential Revision: https://phabricator.services.mozilla.com/D145132
If we want to re-enable SanityTest.jsm test, we need to disable native compositor(DirectComposition) on the testing window, since taking snapshot of native compositor is very slow on Windows. Then CompositorOptions could be used to notice to disable native compositor(DirectComposition).
To notice it from SanityTest.jsm to gecko, nsIAppWindow::needFastSnaphot() is used.
Differential Revision: https://phabricator.services.mozilla.com/D130824
This patch just adds the plumbing to allow for baked in blocklist rules
or the downloadable blocklist to prevent certain configurations from
getting WebGPU. It does not add any rules.
It also changes us from allowing WebGPU only in nightly, including
tests, to not release and not beta. This allows try to run the WebGPU
tests as expected, since even try builds forked from mozilla-central are
not considered nightly builds by CI (or so it seems).
Differential Revision: https://phabricator.services.mozilla.com/D141682
I'd like to use it in `IMEData.h`. However, adding new include into it may
cause bustage with MinGW, and it's included by `nsIWidget.h` because `nsIWidget`
requires some classes defined in `IMEData.h`. Therefore, I'd like to make a
new header file for avoiding the include hell.
Differential Revision: https://phabricator.services.mozilla.com/D138007
I'd like to use `OffsetAndData` in `IMMHandler` to store selection range.
Before doing this, this patch adds some useful methods into it.
Differential Revision: https://phabricator.services.mozilla.com/D137411
