Move it to the mozilla::widget namespace.
Use enum classes for transparency, popup type, popup level, etc.
Mostly automated with sed, but there were a few manual changes required
as well in windows code because they relied on Atomic<TransparencyMode>
working (which now doesn't because TransparencyMode is 1 byte instead of
4 bytes).
Differential Revision: https://phabricator.services.mozilla.com/D167537
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
Previously we would pull this information frequently from the subject
principal, which is unreliable. With this new approach, we more explicitly pass
the principals around as-needed into where they're going to be used.
Some assertions about the subject principal were introduced to ensure that
assumptions made about chrome windows and the system principal are not
incorrect.
Differential Revision: https://phabricator.services.mozilla.com/D154563
Previously we would pull this information frequently from the subject
principal, which is unreliable. With this new approach, we more explicitly pass
the principals around as-needed into where they're going to be used.
Some assertions about the subject principal were introduced to ensure that
assumptions made about chrome windows and the system principal are not
incorrect.
Differential Revision: https://phabricator.services.mozilla.com/D154563
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
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
And have it mirror in the parent process more automatically.
The docShellIsActive setter in the browser-custom-element side needs to
be there rather than in the usual DidSet() calls because the
AsyncTabSwitcher code relies on getting an exact amount of notifications
as response to that specific setter. Not pretty, but...
BrowserChild no longer sets IsActive() on the docshell itself for OOP
iframes. This fixes bug 1679521. PresShell activeness is used to
throttle rAF as well, which handles OOP iframes nicely as well.
Differential Revision: https://phabricator.services.mozilla.com/D96072
When window is PiP window on Windows7, WS_EX_COMPOSITED is set to suppress flickering during resizing with hardware acceleration as a workaround.
PiP window detection in nsAppShellService::JustCreateTopWindow() mimics Linux/Gtk implementation.
Differential Revision: https://phabricator.services.mozilla.com/D77663
The enforcement is only important when users are able to resize the windows. Otherwise,
we let Gecko set the window dimensions to whatever dimensions they'd like.
Differential Revision: https://phabricator.services.mozilla.com/D78538
This value is determined in Parent process and passed down to nsDocShell. Delete
the messages to pass the setting down and set it on the BrowsingContext in the
Parent process.
Refactor the code that determines to opt-out of using global history. Code
inspection determines that windowless browsing contexts want to opt-out as well
as any frame with `disableglobalhistory` attribute set on it.
Differential Revision: https://phabricator.services.mozilla.com/D72279
There were previously a number of different APIs for creating BrowsingContext
instances. This simplifies them into two major cases: "CreateDetached", which
allows for creating BrowsingContexts which are related to other
BrowsingContexts, and "CreateIndependent" which creates new, fully unrelated,
browsing contexts.
Differential Revision: https://phabricator.services.mozilla.com/D71237
There were previously a number of different APIs for creating BrowsingContext
instances. This simplifies them into two major cases: "CreateDetached", which
allows for creating BrowsingContexts which are related to other
BrowsingContexts, and "CreateIndependent" which creates new, fully unrelated,
browsing contexts.
Differential Revision: https://phabricator.services.mozilla.com/D71237
There were previously a number of different APIs for creating BrowsingContext
instances. This simplifies them into two major cases: "CreateDetached", which
allows for creating BrowsingContexts which are related to other
BrowsingContexts, and "CreateIndependent" which creates new, fully unrelated,
browsing contexts.
Differential Revision: https://phabricator.services.mozilla.com/D71237
There were previously a number of different APIs for creating BrowsingContext
instances. This simplifies them into two major cases: "CreateDetached", which
allows for creating BrowsingContexts which are related to other
BrowsingContexts, and "CreateIndependent" which creates new, fully unrelated,
browsing contexts.
Differential Revision: https://phabricator.services.mozilla.com/D71237
There were previously a number of different APIs for creating BrowsingContext
instances. This simplifies them into two major cases: "CreateDetached", which
allows for creating BrowsingContexts which are related to other
BrowsingContexts, and "CreateIndependent" which creates new, fully unrelated,
browsing contexts.
Differential Revision: https://phabricator.services.mozilla.com/D71237
Stephen A Pohl