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
DONTBUILD because this is just whitespace cleanup.
I found the files to fix up here using this command:
grep -r ' ' * 2>/dev/null | grep -v "other-licenses" | grep "idl:"
I replaced the tab characters with however many spaces seemed consistent with
the indentation in the surrounding code (and did some minor space-indentation
cleanup in contextual lines to preserve alignment, in a few cases).
Differential Revision: https://phabricator.services.mozilla.com/D160577
In bug 1773342 I made OS text scale factor behave like a full zoom
factor which applies to all pages (including the browser chrome). That's
generally straight forward but it makes some callsites that use unzoomed
CSS coordinates misbehave (or behave correctly accidentally actually in
some other cases).
The main fix here is making
nsIBaseWindow::UnscaledDevicePixelsPerCSSPixel() and
nsIScreen::GetDefaultCSSScaleFactor() account for OS zoom as necessary.
However, I also went through the relevant code and cleaned it up to use
typed units and operations when possible.
The setup means:
* nsIWidget::GetDefaultScale() doesn't account for OS full zoom.
* nsIBaseWindow and nsIScreen does.
These are the places where this should matter and stuff can get
confused, but this works surprisingly well for all callers (except one
nsDeviceContext one which we use only for PuppetWidget and we can
remove by falling back to 1.0 like all other widgets until the update
comes).
Differential Revision: https://phabricator.services.mozilla.com/D149033
In bug 1773342 I made OS text scale factor behave like a full zoom
factor which applies to all pages (including the browser chrome). That's
generally straight forward but it makes some callsites that use unzoomed
CSS coordinates misbehave (or behave correctly accidentally actually in
some other cases).
The main fix here is making
nsIBaseWindow::UnscaledDevicePixelsPerCSSPixel() and
nsIScreen::GetDefaultCSSScaleFactor() account for OS zoom as necessary.
However, I also went through the relevant code and cleaned it up to use
typed units and operations when possible.
The setup means:
* nsIWidget::GetDefaultScale() doesn't account for OS full zoom.
* nsIBaseWindow and nsIScreen does.
These are the places where this should matter and stuff can get
confused, but this works surprisingly well for all callers (except one
nsDeviceContext one which we use only for PuppetWidget and we can
remove by falling back to 1.0 like all other widgets until the update
comes).
Differential Revision: https://phabricator.services.mozilla.com/D149033
Given how nsIPrintSettings is passed around, stored and copied all over the
place, it's very hard to reason about where and when a RemotePrintJobChild is
needed or valid. This patch avoids all that by explicitly passing a
RemotePrintJobChild when it's needed.
Another reason to make this change is because RemotePrintJobChild really does
not belong on nsIPrintSettings. That interface is supposed to represent a
collection of settings for laying out the document that is to be printed.
Differential Revision: https://phabricator.services.mozilla.com/D146380
nsIPrintingPromptService comes from an era when the platform print code would
open the print settings dialog, which defaulted to the OS native dialogs.
Its purpose was to allow that dialog to be overridden by embedders to provide
their own interface for the user to select print settings. Nowadays the
platform print code does not open the dialogs. Instead apps like Firefox are
responsible for getting the print settings to pass to the platform code, and
the platform code provides a way to open the OS native print dialog if they
want to use that (nsIPrintDialogService). So nsIPrintingPromptService no longer
has any purpose, and just adds indirection and needless complexity.
Differential Revision: https://phabricator.services.mozilla.com/D146232
It seems the new tab-modal printing code doesn't actually use this. Instead it
relies on the window being closed (see cancelPrint() in
toolkit/components/printing/content/print.js ).
Differential Revision: https://phabricator.services.mozilla.com/D144821
-Wshadow warnings are not enabled globally, so these -Wno-shadow suppressions have no effect. I had intended to enable -Wshadow globally along with these suppressions in some directories (in bug 1272513), but that was blocked by other issues.
There are too many -Wshadow warnings (now over 2000) to realistically fix them all. We should remove all these unnecessary -Wno-shadow flags cluttering many moz.build files.
Differential Revision: https://phabricator.services.mozilla.com/D132289
This simplifies the chromeFlag calculation for:
* chrome-priv case, by removing not-fully-chrome-priv case
* content case, by removing presenceFlag calculation
both by removing the special case for
nsGlobalWindowOuter::Print and nsDocShell::PerformRetargeting,
that has chrome caller but no chrome parent.
Code path for nsGlobalWindowOuter::Print and nsDocShell::PerformRetargeting
now uses the content case instead of the chrome-priv case, but the resulting
flag doesn't change (CHROME_ALL) for those 2 consumers.
Differential Revision: https://phabricator.services.mozilla.com/D129530
This simplifies the chromeFlag calculation for:
* chrome-priv case, by removing not-fully-chrome-priv case
* content case, by removing presenceFlag calculation
both by removing the special case for
nsGlobalWindowOuter::Print and nsDocShell::PerformRetargeting,
that has chrome caller but no chrome parent.
Code path for nsGlobalWindowOuter::Print and nsDocShell::PerformRetargeting
now uses the content case instead of the chrome-priv case, but the resulting
flag doesn't change (CHROME_ALL) for those 2 consumers.
Differential Revision: https://phabricator.services.mozilla.com/D129530
These are only used for frameset painting and the non-e10s <select>
dropdown focus codepath. We have other more appropriate standard
colors for this.
Differential Revision: https://phabricator.services.mozilla.com/D129992
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 will, for example, make it possible to behave differently for a normal navigation,
a reload navigation, a history navigation, and a pushstate navigation.
Differential Revision: https://phabricator.services.mozilla.com/D122532
This shouldn't change behavior, but is the biggest cross-platform part
of the change so I'd like to get it landed sooner rather than later.
The two calls like:
GetColor(ColorID::TextSelectBackground, color);
if (color == 0x000000) {
mColorTextSelectForeground = NS_RGB(0xff, 0xff, 0xff);
} else {
mColorTextSelectForeground = NS_DONT_CHANGE_COLOR;
}
that I'm removing are just broken. They were calling the version of
GetColor the function that took a default value when the color wasn't
available, not the version of the color with the outparam.
To prevent such mistakes, add two signatures, GetColor(), returning a
Maybe<nscolor> and Color(), returning a color with a fallback.
Differential Revision: https://phabricator.services.mozilla.com/D110651
This shouldn't change behavior, but is the biggest cross-platform part
of the change so I'd like to get it landed sooner rather than later.
The two calls like:
GetColor(ColorID::TextSelectBackground, color);
if (color == 0x000000) {
mColorTextSelectForeground = NS_RGB(0xff, 0xff, 0xff);
} else {
mColorTextSelectForeground = NS_DONT_CHANGE_COLOR;
}
that I'm removing are just broken. They were calling the version of
GetColor the function that took a default value when the color wasn't
available, not the version of the color with the outparam.
To prevent such mistakes, add two signatures, GetColor(), returning a
Maybe<nscolor> and Color(), returning a color with a fallback.
Differential Revision: https://phabricator.services.mozilla.com/D110651
