Given meta/ctrl key should use browser.tabs.loadInBackground pref instead of
browser.tabs.loadDivertedInBackground pref, the existing
nsIBrowserDOMWindow.OPEN_NEWTAB behavior doesn't match the requirement.
Add dedicate flag for "open in foreground tab" to make it controllable from
nsWindowWatcher::IsWindowOpenLocationModified.
Differential Revision: https://phabricator.services.mozilla.com/D201929
This comes back to bug 42557 and co. It only does something
half-reasonable on Windows (on macOS we just lie and make z-order
tracking be latest-active tracking), and given we don't use the special
zorder flags elsewhere I'm pretty sure we should be able to just rip
this off... On some DEs like Wayland we can't re-stack toplevel windows.
Differential Revision: https://phabricator.services.mozilla.com/D213602
This never worked according to its description: it merely set the
_window-class_ background-color. We neither have nor need any mechanism
to give individual windows their own per-widget background color under
Win32.
Instead, we just set the background color to be dark grey, which is
probably good enough for the few purposes for which the background brush
is actually used. (Alas, this does not _quite_ include the initial white
flash.)
The comment in this bug about this being important for Windows dates
from bug 574638, and is no longer relevant -- at least, not in the
particular way it used to be.
Differential Revision: https://phabricator.services.mozilla.com/D212761
Otherwise we start painting the window too early, which after
bug 1891063 causes the non-client area to be filled, but we don't paint
anything on top.
Differential Revision: https://phabricator.services.mozilla.com/D208898
Previously the `boolean` type was also declared using a `bool` typedef in
xpidl, meaning that both were used in various places. This patch standardizes
on the built-in `boolean` type, removing the typedef.
Differential Revision: https://phabricator.services.mozilla.com/D206382
Firefox never uses this. TB could use the same approach Firefox uses,
but for now on macOS the sheets become regular modal dialogs, which is
the same as on Windows and Linux.
See bug 1755330 and bug 1737489 for more context.
Differential Revision: https://phabricator.services.mozilla.com/D204209
This implements the basic infrastructure to use use libdbusmenu to
export the Linux menubar.
For now, this is not integrated with the front-end, and there are some
remaining bugs, so it lands disabled by default behind the
widget.gtk.global-menu.enabled pref.
Differential Revision: https://phabricator.services.mozilla.com/D200259
Given meta/ctrl key should use browser.tabs.loadInBackground pref instead of
browser.tabs.loadDivertedInBackground pref, the existing
nsIBrowserDOMWindow.OPEN_NEWTAB behavior doesn't match the requirement.
Add dedicate flag for "open in foreground tab" to make it controllable from
nsWindowWatcher::IsWindowOpenLocationModified.
Differential Revision: https://phabricator.services.mozilla.com/D201929
Given meta/ctrl key should use browser.tabs.loadInBackground pref instead of
browser.tabs.loadDivertedInBackground pref, the existing
nsIBrowserDOMWindow.OPEN_NEWTAB behavior doesn't match the requirement.
Add dedicate flag for "open in foreground tab" to make it controllable from
nsWindowWatcher::IsWindowOpenLocationModified.
Differential Revision: https://phabricator.services.mozilla.com/D201929
Bug 1870512 removed top level windows with WindowType::Popup, instead
replacing it with an "alert" feature for the only use of them that we
had.
Turns out that on Windows they need a bit more special handling than I
thought, so this patch uses the alert boolean to fix two regressions
(that alerts now create taskbar icons, and that they steal focus).
Remove mIsForMenuPopupFrame since that is now a synonym with
WindowType::Popup.
Remove also the dialog vs. toplevel difference of using
WS_EX_DLGMODALFRAME, since that doesn't seem to have an effect at all on
windows 10+.
Differential Revision: https://phabricator.services.mozilla.com/D200508
Reflect modifiers to chromeFlags and nsIBrowserDOMWindow::OPEN_* location,
to perform the equivalent of BrowserUtils.whereToOpenLink in window.open with
modifier keys.
Differential Revision: https://phabricator.services.mozilla.com/D197864
Pass UserActivation::Modifiers from nsGlobalWindowOuter::OpenInternal
to nsPIWindowWatcher.openWindowWithRemoteTab, through the following interfaces
and protocol:
* nsPIWindowWatcher.openWindow2
* nsIWindowProvider.provideWindow
* PContent.CreateWindow or PContent.CreateWindowInDifferentProcess
* nsPIWindowWatcher.openWindowWithRemoteTab
Differential Revision: https://phabricator.services.mozilla.com/D197863
In order to achieve "load in a new background tab" operation in `window.open`,
add OPEN_NEWTAB_BACKGROUND which is equivalent to OPEN_NEWTAB except for
not selecting the tab.
Differential Revision: https://phabricator.services.mozilla.com/D197859
When we open a new window on top of a fullscreen window, we deliberately
make that window "normal" (non-fullscreen, non-maximized), which was
documented as having been "a standard [W]indows convention" [1].
Chromium does the same (with fiddly differences involving the window
size).
Unfortunately, we do this by checking if there are _any_ fullscreen
windows open -- which produces false positives on multimonitor or
multi-virtual-desktop setups.
Therefore, adjust the code to match the original comment, and only take
the parent window into account. This seems likely to better match user
expectations.
[1] https://bugzilla.mozilla.org/show_bug.cgi?id=575195#c5
Differential Revision: https://phabricator.services.mozilla.com/D197823
Before bug 1869796 they had an utility type hint, now they have a
toplevel type hint, after the patch they have a notification type hint,
which seems more appropriate.
Differential Revision: https://phabricator.services.mozilla.com/D197872
These are only used right now for XUL notifications. They are extremely
weird (I bet there's tons of code that assume that WindowType::Popup
corresponds to nsMenuPopupFrame), and afaict there's no good reason why
these have to be this way.
They no longer are on Linux (because Wayland doesn't support such
thing for example).
XUL alerts work fine with this patch on all platforms after some basic
testing.
The other usage of this for the gfx sanity test can use type=dialog.
Actually it can just be a toplevel, but that breaks the XUL skeleton UI.
Differential Revision: https://phabricator.services.mozilla.com/D196665
These are only used right now for XUL notifications. They are extremely
weird (I bet there's tons of code that assume that WindowType::Popup
corresponds to nsMenuPopupFrame), and afaict there's no good reason why
these have to be this way.
They no longer are on Linux (because Wayland doesn't support such
thing for example).
XUL alerts work fine with this patch on all platforms after some basic
testing.
Depends on D196664
Differential Revision: https://phabricator.services.mozilla.com/D196665
The screen lifetime seems like it was a lot more complicated
in the past (looking at the comments in Window.webidl).
But nowadays it seems it can be more similar to the other
objects like VisualViewport etc.
Differential Revision: https://phabricator.services.mozilla.com/D193212
This adds a native fallback menu for early startup modals (e.g.
ProfileManager/ProfileDowngrade) which consists of a "Quit" menu item only,
allowing users to quit the app in a regular way (cmd+Q).
According to the bug report the "Quit" menu item used to exist but caused a
crash. With this patch crash doesn't repro anymore.
Differential Revision: https://phabricator.services.mozilla.com/D191525
The implementation of AppWindow::ForceRoundedDimensions makes clear that
the window size from GetSize` is unscaled. This patch updates the math in
FullscreenWillChange to also consider devices pixels per css pixel.
Differential Revision: https://phabricator.services.mozilla.com/D180886