I think the `stride < width * bpp` is the right thing to check for, since I
don't know if there's any guarantee of it of the stride being equal, but let me
know if I'm wrong.
Differential Revision: https://phabricator.services.mozilla.com/D17851
--HG--
extra : moz-landing-system : lando
This cleans up a bit and allows us to be smarter about which cursors
should we allow from content or what not, which will help with bug 1445844 and
co.
Differential Revision: https://phabricator.services.mozilla.com/D16711
Summary: Really sorry for the size of the patch. It's mostly automatic
s/nsIDocument/Document/ but I had to fix up in a bunch of places manually to
add the right namespacing and such.
Overall it's not a very interesting patch I think.
nsDocument.cpp turns into Document.cpp, nsIDocument.h into Document.h and
nsIDocumentInlines.h into DocumentInlines.h.
I also changed a bunch of nsCOMPtr usage to RefPtr, but not all of it.
While fixing up some of the bits I also removed some unneeded OwnerDoc() null
checks and such, but I didn't do anything riskier than that.
For a better user experience of auto-blocking canvas extraction, this
patch changes the behavior when detecting a canvas extraction without
user interaction. It will show a canvas identity block icon with a
hidden doorhanger when auto-blocking the canvas extraction. Users can
make their choice to either block or allow the canvas extraction by
clicking the identity block icon and then refresh the page to make
the canvas permission taking effect.
Differential Revision: https://phabricator.services.mozilla.com/D14259
--HG--
extra : moz-landing-system : lando
This logging topic will output the topic of MEssageManager data at log
level 4 (debug); and will output the entire content of the data at level
5 (verbose).
--HG--
extra : histedit_source : 7be60b456a1652f9a9985fd4a01571b207a5f9e6
MozPromise most common use is to have an single or exclusive listener. By making the MozPromise generated by IPDL exclusive we can also use move semantics.
While at it, we also use move semantics for the ResponseRejectReason and via the callback's reject method so that the lambda used with the MozPromise::Then can be identical to the one used by the IPDL callback.
As it currently is, it provides no advantage over a copy as it's just an enum; however, this will facilitate future changes where it may not be.
Differential Revision: https://phabricator.services.mozilla.com/D13906
--HG--
extra : moz-landing-system : lando
This should make BrowsingContext more usable by making it much easier to obtain
for a given frame or browser. BrowsingContext and nsFrameLoader should have
the same lifetime.
Differential Revision: https://phabricator.services.mozilla.com/D9395
This allows getting the set of all window globals for a given browsing context.
This is less useful at the moment as the active window global is not exposed as
such. That will be added as a follow-up.
Differential Revision: https://phabricator.services.mozilla.com/D9393
This actor can be used for communicating with individual frames, without
depending on walking the tree in the content process.
This is not yet complete. No tests have been written for it, the
WindowGlobalParent objects need to be exposed to chrome JS, and a form of JS
actors should be installed under them.
In addition, BrowsingContextChrome objects should be updated to allow access to
the current WindowGlobalParent in that context.
Differential Revision: https://phabricator.services.mozilla.com/D4623
This gets rid of an unnecessary allocation.
Differential Revision: https://phabricator.services.mozilla.com/D11066
--HG--
extra : rebase_source : 138c808d78e666e55242bf142269d77fb065d7a6
extra : histedit_source : de8f5f4566cb886e155bce1a22e36f40af7b26f7
All remaining code paths hardcode true here, we can remove this argument.
It wasn't clear to me how this could ever be null before this series. The
only case I could find is that DoFakeShow might be called with a null
RenderFrameChild, but that code is gone now.
Differential Revision: https://phabricator.services.mozilla.com/D11063
--HG--
extra : rebase_source : 872d78ae1b46b0651bc4e109786f4d0d332859c2
extra : histedit_source : 40719e865f2243f90618deba5261124a260ba974
This commit removes all destruction code for RenderFrameParent to be handled by
TabParent. It's important that we remove the layer mapping in ActorDestroy to
prevent a race condition where the TabChild isn't fully destroyed yet and
sends a LayerTransaction constructor to the compositor and hits an
assertion.
Differential Revision: https://phabricator.services.mozilla.com/D11062
--HG--
extra : rebase_source : 61df2cfa3867617c39805883c06649624fffa518
extra : histedit_source : a810303ec335b4ab064dbd56b4652ea4c66deaad
SetRenderFrame() can be implemented in terms of InitRenderFrame(). I'm not sure if
the call to MaybeShow() is necessary, but to be conservative I've moved it into
the window.open path which might need it. BrowserElementParent shouldn't need it
because nsFrameLoader::SetRemoteFrame will call Show().
Differential Revision: https://phabricator.services.mozilla.com/D11061
--HG--
extra : rebase_source : 7d5defc113d107bf77296f1a0a4f7e7dad910db6
extra : histedit_source : 397121af3a86ed3820f055292a8622d3e0bea2b5
We should just have the parent handle initialization here. This lets us
cut down on the information we have to pipe around and simplifies our
amount of code paths.
Differential Revision: https://phabricator.services.mozilla.com/D11060
--HG--
extra : rebase_source : d6c52cb81c7deceb34ad6813d2a55f779d3a1a7d
extra : histedit_source : 4e5a24206e4b8142f2ee788a18c2e186969acfd7
This commit removes the PRenderFrame protocol, while keeping the same ordering
and semantics of graphics IPC initialization.
To do this, some messages are added to PBrowser to simulate the constructor
and destructor of PRenderFrame. Messages that expected a nullable PRenderFrame
are updated to get a boolean instead.
One tricky area is the destruction of PRenderFrame. I've tried to keep it the
same as much as possible, but it's possible it might be slightly semantically
different than IPDL destruction. Destruction will be touched up in a later
patch, so I'm not too concerned.
Differential Revision: https://phabricator.services.mozilla.com/D11057
--HG--
extra : rebase_source : bb8a7896bb4aefb6e9957d8808b755fa76cc00ed
extra : histedit_source : 6377819a946b5b6bc18b15f748229360e42a6f3a
This commit removes a bunch of cruft from RenderFrameParent that isn't
used and isn't needed. Some functions that have no reason to be in
RenderFrameParent are moved to TabParent in anticipation of the
PRenderFrame protocol being dropped.
Differential Revision: https://phabricator.services.mozilla.com/D10411
--HG--
extra : rebase_source : 79f830e0ad48e868480108c3bbb01e3faca5e70a
extra : histedit_source : 4ddb361e4e4acae10ab16124b5d6548490f770ee
This commit attempts to lower the pain of modifying FrameMetrics.h.
It looks like most includes really only want ViewID or
ScrollableLayerGuid, so this commit factors them out into a separate
header. In the process FrameMetrics::ViewID is changed to
ScrollableLayerGuid::ViewID, which personally seems like a better
place for it now that we have RepaintRequest. Unfortunately that
requires a lot of places to be updated.
After this commit there are still a couple of major places that
FrameMetrics is included.
* nsDisplayList.h
* nsIScrollableFrame.h
* Layers.h
Those are going to be more tricky or impossible to fix so they're
not in this commit.
Differential Revision: https://phabricator.services.mozilla.com/D10722
--HG--
rename : gfx/layers/FrameMetrics.h => gfx/layers/ScrollableLayerGuid.h
rename : gfx/layers/FrameMetrics.h => gfx/layers/ZoomConstraints.h
extra : rebase_source : 29ac79f91460a181bf7437af5c371207e22858e2
extra : source : c2e70e531075493fc6e374dcec862827f0bc6e77
This commit adds a CrossProcessPaint class which can be used to paint a
cross process document tree. This API is async, as we cannot block on child
processes, and initially geared towards servicing a JS API and not internal
consumers. The API can only be used in the chrome process for security
reasons.
The class is implemented as a recursive resolver, requesting a root paint,
gathering dependent frames to be painted, then requesting paints from those
tabs. Once all paints have been completed, the dependency tree is rasterized
in a bottom up fashion.
Future improvements can be made here. Currently, the rasterization is
performed on the main thread which could cause jank. We also transmit
recordings directly over IPDl, and no effort is made to minimize the
recordings from child layer trees.
Differential Revision: https://phabricator.services.mozilla.com/D6790
--HG--
extra : rebase_source : b213de269b33486552ddc0be17207f9fb3f78c9c
If class A is derived from class B, then an instance of class A can be
converted to B via a static cast, so a slower QI is not needed.
Differential Revision: https://phabricator.services.mozilla.com/D6861
--HG--
extra : moz-landing-system : lando
Our current prioritization mechanism doesn't account for tab
warming, or for the fact that the current tab should be
deprioritized. This corrects that.
Differential Revision: https://phabricator.services.mozilla.com/D7205
--HG--
extra : moz-landing-system : lando
This also removes the (afaict, unused) stub implementation from TabParent. The netwerk header
inclusions were necessary because those files included TabParent.h and through it,
nsISecureBrowserUI, but now TabParent.h no longer does that.
Differential Revision: https://phabricator.services.mozilla.com/D6829
--HG--
extra : moz-landing-system : lando
The framework to simulate the setting change works as following;
- nsIDOMWindowUtils.setPrefersReducedMotion() calls an IPC function which ends
up calling nsChildView::SetPrefersReducedMotion() in the parent process
- nsChildView::SetPrefersReducedMotion() sets the given value into
nsLookAndFeel::mPrefersReducedMotionCached just like we set the value queried
via NSWorkspace.accessibilityDisplayShouldReduceMotion in the parent process
and send a notification which is the same notification MacOSX sends when the
system setting changed
- Normally the cached value is cleared before quering new values since the
cache value is stale, but in this case the value is up-to-date one, so
nsChildView::SetPrefersReducedMotion() tells that we don't need to clear the
cache, and nsIDOMWindowUtils.resetPrefersReducedMotion() resets that state
of 'we don't need to clear the cache'
There are two test cases with the framework in this commit, one is just setting
the value and checking the value queried by window.matchMedia. The other one is
receiving 'change' event and checking the value of the event target.
Note that to make this test works the patch for bug 1478212 is necessary since
the test runs in an iframe.
Depends on D5003
Differential Revision: https://phabricator.services.mozilla.com/D5004
--HG--
extra : moz-landing-system : lando
This patch removes the 'ScreenOrientationInternal' type from
dom/base/ScreenOrientation.h and moves it into the
HalScreenConfiguration.h header, renaming it simply to 'ScreenOrientation'
in the process. This has several knock-off effects:
- It allows files that needed ScreenOrientationInternal to include a much
smaller header than before
- It greatly reduces the number of headers pulled in when including Hal.h
- It clarifies the role of the type. The 'Internal' part in the name had
nothing to do with it being part of the implementation. The type was public
and called that way only to avoid clashing with the 'ScreenOrientation'
class. Since we moved it into a different namespace it can be renamed
safely.
- It allows a file that was manually re-declaring 'ScreenConfigurationInternal'
type to use the original one
- Finally this fixes a few files which were missing headers they actually
required but that would still build because unified compilation put them into
units that already had those headers thanks to ScreenConfiguration.h
Differential Revision: https://phabricator.services.mozilla.com/D4458
--HG--
extra : moz-landing-system : lando
The test case in this patch fails without the proper fix in the first patch
in this patch series.
In this patch two new nsIDOMWindowUtils APIs are introduced to change the
system font settins in tests. Currently the APIs work only on GTK+ platform.
Also to work the test case properly we need to open a new XUL window because we
don't propagate font changes into descendant documents yet (bug 1478212).
MozReview-Commit-ID: 4OLxEkEuF8d
--HG--
extra : rebase_source : 683e64f07c4d8820e5499d8c15b90975618559b8
Browsers can switch at runtime from remote to non-remote and vice versa,
which on the C++ side is detected from a XBL binding change which causes
nsIRemoteBrowser to either be implemented or not. Custom Elements can't
change at runtime in the same way, so unifying on a single [implements]
will allow browser (both remote and non-remote) to be migrated to a single
Custom Element.
To keep current functionality, this updates Qi calls into nsIRemoteBrowser
to instead Qi into nsIBrowser and check isRemoteBrowser.
Differential Revision: https://phabricator.services.mozilla.com/D3346
--HG--
extra : moz-landing-system : lando
Andreas Farre
Emilio Cobos Álvarez
Ehsan Akhgari
Cosmin Sabou
Nika Layzell
Tooru Fujisawa
Tim Huang
Gijs Kruitbosch
Coroiu Cristina
Tom Ritter
Jean-Yves Avenard
Neil Deakin
Sylvestre Ledru
Lina Cambridge
Ryan Hunt
Eden Chuang
Boris Zbarsky
Andrew McCreight
Doug Thayer
Hiroyuki Ikezoe
Gabriele Svelto
Brian Grinstead
Ting-Yu Lin
Kartikaya Gupta
Blake Kaplan