We want to skip InitRendering only when parent side does not requested to connect layers. Current implementation is not clear about meaning of "mLayersConnected == Some(false)". It has the following 2 meanings.
[1] parent side does not request to connect layers.
[2] parent side requested to connect layers, but the connect was failed.
We need to distinguish between [1] and [2]. mLayersConnectRequested is added for it.
Differential Revision: https://phabricator.services.mozilla.com/D149637
In bug 1728062 we made it so that we that we skip
BrowserChild::ReinitRendering if the BrowserChild is not connected to
a compositor. This was in order to avoid initializing the compositor
for windowless browsers.
However, in cases where the GPU process dies before an initial
InitRendering has completed, then the BrowserChild will also be left
not connected to a compositor, with mLayersConnected == Some(false).
ReinitRendering will be called once the new GPU process has been
launched, but due to this condition we will exit early, and the tab
will be left in an unusable state.
To fix this, this patch changes the early return condition to only
check for mLayersConnected.isNothing(), ie we never even attempted to
initialize rendering. When it is Some(false), ie we attempted and
failed, then ReinitializeRendering is still executed.
Differential Revision: https://phabricator.services.mozilla.com/D149619
With the use of mStorageAccessPermissionGranted reduced to a single meaning, it turns out to be entirely redundant with the variable on the inner window.
Depends on D147867
Differential Revision: https://phabricator.services.mozilla.com/D147868
With the use of mStorageAccessPermissionGranted reduced to a single meaning, it turns out to be entirely redundant with the variable on the inner window.
Depends on D147867
Differential Revision: https://phabricator.services.mozilla.com/D147868
This is largely a straightforward find and replace of various methods, with the
unnecessary arguments removed and compiler errors fixed.
Differential Revision: https://phabricator.services.mozilla.com/D148532
With the use of mStorageAccessPermissionGranted reduced to a single meaning, it turns out to be entirely redundant with the variable on the inner window.
Depends on D147867
Differential Revision: https://phabricator.services.mozilla.com/D147868
For making this, `BrowserParent` (temporarily) store sent keyboard events which
wants reply from the remote process. Then, when it gets a reply event received,
it compares whether the event data is broken or not.
Differential Revision: https://phabricator.services.mozilla.com/D145944
Previously, even for remote in-process iframes, it was only possible to retrieve the top level BrowsingContext for the remote process by getting the managing BrowserParent.
This makes it possible to get the correct BrowsingContext even for in-process iframes.
Differential Revision: https://phabricator.services.mozilla.com/D147716
If a IPCDataTransferItem fails to be converted, the subsequent IPCDataTransferItems
will be ignored, and the data in Shmem won't be deallocated properly if any.
Differential Revision: https://phabricator.services.mozilla.com/D145940
Lately nsIPrintSession was only used to pass around RemotePrintJobChild objects.
Now that we pass those objects explicitly where needed (part 1), this class
serves no purpose.
Another reason to want to get rid of this class is that having it as a member
of nsIPrintSettings made no sense and was confusing.
Differential Revision: https://phabricator.services.mozilla.com/D146381
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
Content processes can provide screen coordinates in e.g. window objects and events without waiting for the proper client-to-screen transforms to be given to them from the parent process. This poses a problem for tests that want to check the screen coordinates, so we add SpecialPowers.ContentTransformsReceived() to allow content processes to wait for these transforms.
Differential Revision: https://phabricator.services.mozilla.com/D144742
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
Other places in BrowserChild explicitly just handle null docshell.
(The only special case is when we have just created WebBrowser object in Init())
Differential Revision: https://phabricator.services.mozilla.com/D138657
This is introduced by bug 805939, but no one uses it.
Screen orientation information is handled by `hal::ScreenConfiguration` now.
Differential Revision: https://phabricator.services.mozilla.com/D136119
This shouldn't change behavior but makes following the code a bit
easier. There's no point in using callbacks for touch-action as:
* We return the computed flags anyways.
* Each caller wants to do something different.
* (more importantly) The callback gets called synchronously.
So move the relevant code to TouchActionHelper and make the callers deal
with the flags as they please. I've preserved the behavior of only doing
the thing if the flags array is non-empty.
Differential Revision: https://phabricator.services.mozilla.com/D134933
VsyncChild is main thread only, and we would like to reuse PVsync on the
worker threads via PBackgroundChild which already implements it. This
patch does the necessary refactoring to have multiple implementations of
PVsyncChild.
Differential Revision: https://phabricator.services.mozilla.com/D130264
VsyncChild is main thread only, and we would like to reuse PVsync on the
worker threads via PBackgroundChild which already implements it. This
patch does the necessary refactoring to have multiple implementations of
PVsyncChild.
Differential Revision: https://phabricator.services.mozilla.com/D130264
Now we use `mozilla::widget::ScreenManager` even if on content process, so no
one uses `PuppetScreen` and `PuppetScreenManager`.
And I would like to remove `Hal.h` reference from `PuppetWidget`, so I remove
unused method.
Differential Revision: https://phabricator.services.mozilla.com/D132564
This patch ensures that, following a GPU process crash, we
re-initialize the compositor and resume painting on Android.
nsWindow::GetWindowRenderer() is made to always reinitialize the
window renderer if there is none, like on other platforms. We
therefore no longer need to track whether webrender is being disabled,
as this is no longer a special case.
Previously we started the compositor as initially paused in
nsBaseWidget::CreateCompositorSession only if the widget did not yet
have a surface. Now we must unconditionally (re)start it as initially
paused, as even though the widget in the parent process may have a
surface, we will not have been able to send it to the GPU process
yet. We will send the surface to the compositor once control flow
returns to nsWindow::CreateLayerManager, where we will also now resume
the compositor if required.
Finally, we must ensure that we manually trigger a paint, both in the
parent and content processes. On other platforms this occurs
automatically following a GPU process loss through various refresh
driver events. On Android, however, nothing causes the refresh driver
to paint by itself, and we cannot receive input without first
initializing our APZ controllers, which does not happen until the
compositor receives a display list. We therefore must manually
schedule a paint. We do so from nsWindow::NotifyCompositorSessionLost
for the parent process, and BrowserChild::ReinitRendering for content
processes.
Differential Revision: https://phabricator.services.mozilla.com/D131232
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
Instead of passing this flag all of the time for double taps we want to decide to do this or not in CalculateRectToZoomTo. Moving it into ZoomTarget seems like a good way to do this (which is done in the next patch).
Differential Revision: https://phabricator.services.mozilla.com/D128435
This adds an optional paper orientation to PrintPreviewResultInfo populates it
from the CSS page size when finishing print preview. The value is then placed
in the PrintPreviewSuccessInfo to be sent to the frontend.
Differential Revision: https://phabricator.services.mozilla.com/D124248
In some cases, like when we create a windowless browser, RemoteLayerTreeOwner/BrowserChild is not connected to a compositor.
When widget in parent process is PuppetWidget by nsAppShellService::CreateWindowlessBrowser() RemoteLayerTreeOwner/BrowserChild was not connected to compositor.
Differential Revision: https://phabricator.services.mozilla.com/D123917
