This is done differently depending on whether the Private Browsing window is the initial one, or if it's a new window from a running application. In the former case, we're still not setting it up early enough -- the window will initially show up in one icon, and then switch to the other one after we've adjusted the AUMID.
Regardless, the fact that we're doing it for every new window appears to mean that other places that require it (such as GeckoChildProcessHost.cpp) will Do The Right Thing (because they'll pull the cached version that `GetAppUserModelID` finds).
This behind a pref for now both because of the issue noted above, as well as the fact that we're waiting on finalized branding for this.
Differential Revision: https://phabricator.services.mozilla.com/D138194
This is done differently depending on whether the Private Browsing window is the initial one, or if it's a new window from a running application. In the former case, we're still not setting it up early enough -- the window will initially show up in one icon, and then switch to the other one after we've adjusted the AUMID.
Regardless, the fact that we're doing it for every new window appears to mean that other places that require it (such as GeckoChildProcessHost.cpp) will Do The Right Thing (because they'll pull the cached version that `GetAppUserModelID` finds).
This behind a pref for now both because of the issue noted above, as well as the fact that we're waiting on finalized branding for this.
Differential Revision: https://phabricator.services.mozilla.com/D138194
This is done differently depending on whether the Private Browsing window is the initial one, or if it's a new window from a running application. In the former case, we're still not setting it up early enough -- the window will initially show up in one icon, and then switch to the other one after we've adjusted the AUMID.
Regardless, the fact that we're doing it for every new window appears to mean that other places that require it (such as GeckoChildProcessHost.cpp) will Do The Right Thing (because they'll pull the cached version that `GetAppUserModelID` finds).
This behind a pref for now both because of the issue noted above, as well as the fact that we're waiting on finalized branding for this.
Differential Revision: https://phabricator.services.mozilla.com/D138194
This is done differently depending on whether the Private Browsing window is the initial one, or if it's a new window from a running application. In the former case, we're still not setting it up early enough -- the window will initially show up in one icon, and then switch to the other one after we've adjusted the AUMID.
Regardless, the fact that we're doing it for every new window appears to mean that other places that require it (such as GeckoChildProcessHost.cpp) will Do The Right Thing (because they'll pull the cached version that `GetAppUserModelID` finds).
This behind a pref for now both because of the issue noted above, as well as the fact that we're waiting on finalized branding for this.
Differential Revision: https://phabricator.services.mozilla.com/D138194
And cleanup similar code in nsXULTooltipListener. That code shouldn't
need to deal with zoom since the target and the tooltip are in the same
document.
Differential Revision: https://phabricator.services.mozilla.com/D139235
Add BrowsingContext::FieldValues.mIsPopupRequested, and pass "is popup"
value calculated before opening window/tab to BrowsingContext::CreateDetached.
Other code path that is unrelated to content-priv window.open uses the
default value false.
Differential Revision: https://phabricator.services.mozilla.com/D129411
Removed "width" feature from the popup condition, and removed related parameters
(aWidthSpecified, and aSizeSpec) from functions.
Also added "popup" feature that explicitly specify whether to request popup or
not.
This is only for content context, and it behaves differently than existing
"popup" feature for chrome context that makes the window no-style.
Differential Revision: https://phabricator.services.mozilla.com/D129410
Add BrowsingContext::FieldValues.mIsPopupRequested, and pass "is popup"
value calculated before opening window/tab to BrowsingContext::CreateDetached.
Other code path that is unrelated to content-priv window.open uses the
default value false.
Differential Revision: https://phabricator.services.mozilla.com/D129411
Removed "width" feature from the popup condition, and removed related parameters
(aWidthSpecified, and aSizeSpec) from functions.
Also added "popup" feature that explicitly specify whether to request popup or
not.
This is only for content context, and it behaves differently than existing
"popup" feature for chrome context that makes the window no-style.
Differential Revision: https://phabricator.services.mozilla.com/D129410
mReady is false both before nsWindowMediator is initialized and after it observed xpcom-shutdown. In the latter case we can still receive Javascript calls as the service is not yet unregistered. We want to ensure that:
- we cannot register new windows anymore (this was already the case but we want to assert, too).
- we do not throw while asking for enumerators even late in shutdown, returning an empty enumerator.
- we assert on other late calls (but keep returning an error in non-debug).
Differential Revision: https://phabricator.services.mozilla.com/D129942
Automatically generated path that adds flag `REQUIRES_UNIFIED_BUILD = True` to `moz.build`
when the module governed by the build config file is not buildable outside on the unified environment.
This needs to be done in order to have a hybrid build system that adds the possibility of combing
unified build components with ones that are built outside of the unified eco system.
Differential Revision: https://phabricator.services.mozilla.com/D122345
This makes sure to clear and set the value more consistently when replacing
documents within a WindowGlobal, and makes sure to include the relevant flag in
the initializer.
In addition, the place where the flag is set is moved ahead to happen before
the call to `Embed` so that the information is ready before the window is
created.
Differential Revision: https://phabricator.services.mozilla.com/D119815
This is a little more than we need to disable it, but I figure we'll want to
support different UI densities in the skeleton UI long term.
Differential Revision: https://phabricator.services.mozilla.com/D111906
This is a little more than we need to disable it, but I figure we'll want to
support different UI densities in the skeleton UI long term.
Differential Revision: https://phabricator.services.mozilla.com/D111906
There are no code changes, only #include changes.
It was a fairly mechanical process: Search for all "AUTO_PROFILER_LABEL", and in each file, if only labels are used, convert "GeckoProfiler.h" into "ProfilerLabels.h" (or just add that last one where needed).
In some files, there were also some marker calls but no other profiler-related calls, in these cases "GeckoProfiler.h" was replaced with both "ProfilerLabels.h" and "ProfilerMarkers.h", which still helps in reducing the use of the all-encompassing "GeckoProfiler.h".
Differential Revision: https://phabricator.services.mozilla.com/D104588
This is, for the most part, just a large refactor of the skeleton UI stuff to
support coarse-grained error reporting via telemetry. There are a few slight
changes in how we handle some errors. For example, if CreateWindow fails, we
will now bail out and report the failure. The flow for the happy path, however,
should remain unchanged.
Differential Revision: https://phabricator.services.mozilla.com/D102098
