These casts are now unnecessary after Part 2, due to all consumers directly
using `ContentParent`.
Depends on D20551
Differential Revision: https://phabricator.services.mozilla.com/D20552
--HG--
extra : moz-landing-system : lando
This patch tries to move them to `ContentParent` instead.
`ProcessPriorityManagerImpl::ObserveContentParentCreated` could not be moved
due to using `do_QueryInterface` to cast from a `nsISupports` down to the
`ContentParent` object. This could be fixed to remove the interfaces entirely,
but I left that for a follow-up.
Depends on D20549
Differential Revision: https://phabricator.services.mozilla.com/D20550
--HG--
extra : moz-landing-system : lando
This actor won't be being used anymore, and acts only as a maintenance burden
for people working on this code (which we're doing pretty often these days!).
Differential Revision: https://phabricator.services.mozilla.com/D20549
--HG--
extra : moz-landing-system : lando
These casts are now unnecessary after Part 2, due to all consumers directly
using `ContentParent`.
Depends on D20551
Differential Revision: https://phabricator.services.mozilla.com/D20552
--HG--
extra : moz-landing-system : lando
This patch tries to move them to `ContentParent` instead.
`ProcessPriorityManagerImpl::ObserveContentParentCreated` could not be moved
due to using `do_QueryInterface` to cast from a `nsISupports` down to the
`ContentParent` object. This could be fixed to remove the interfaces entirely,
but I left that for a follow-up.
Depends on D20549
Differential Revision: https://phabricator.services.mozilla.com/D20550
--HG--
extra : moz-landing-system : lando
This actor won't be being used anymore, and acts only as a maintenance burden
for people working on this code (which we're doing pretty often these days!).
Differential Revision: https://phabricator.services.mozilla.com/D20549
--HG--
extra : moz-landing-system : lando
We had previously missed to call browser.updateSecurityUIForContentBlockingEvent on
onLocationChange updates, to reset the contentBlockingEvent state. This would mean that
on tab switch the contentBlockingEvent state for benign pages would still be what it was
set to on the last tracker page.
Differential Revision: https://phabricator.services.mozilla.com/D20328
--HG--
extra : moz-landing-system : lando
This patch changes the logic such that we use the new direct
BrowsingContext ParamTraits implementation when possible, and avoids
doing manual lookups.
Depends on D19178
Differential Revision: https://phabricator.services.mozilla.com/D19179
--HG--
extra : moz-landing-system : lando
Replacing js and text occurences of asyncOpen2
Replacing open2 with open
Differential Revision: https://phabricator.services.mozilla.com/D16885
--HG--
rename : layout/style/test/test_asyncopen2.html => layout/style/test/test_asyncopen.html
extra : moz-landing-system : lando
A TabParent for a remote subframe will have the same owner content as the top-level
remote browser. This means that 'TabParent::GetFrameLoader()' will return the
frame loader of the top-level remote browser.
This is fine for getting the layer manager and compositor for connecting layer trees,
but the frame loader is also used to acquire a TabParent for its process ID. This
is incorrect in the remote subframe case, and will lead to the compositor rejecting
layer transactions for the remote subframe because it will only accept them from
the top-level remote browser's process.
This commit switches RenderFrame to just hold on to TabParent, and acquire the
nsFrameLoader as necessary.
Another change is to RenderFrame::SetOwnerContent. Previously this method would
take the new owner content and check an assertion. I don't see much value in the
assertion, so I've removed it. Additionally, now that we acquire the owner content,
and therefore the layer manager, from TabParent, we need to ensure that
RenderFrame::SetOwnerContent is ran after the TabParent has had it's owner content
updated. So the callsite has been moved into TabParent. This resolved a test failure
with frame loader swapping.
Differential Revision: https://phabricator.services.mozilla.com/D17447
--HG--
extra : source : 4c85fb68f2ed297828bf4646301c2d80d1c8e0a1
extra : intermediate-source : 62ad54fb95eb76f88865f43da1a5d556421e7884
extra : histedit_source : 6b7085118bca83433b26fcec3983a385bd536672
This commit adds a PRemoteFrame actor which is managed by PBrowser. It will
be created in a child process nsFrameLoader when loading a remote subframe.
This actor will mostly just bounce messages from a nsFrameLoader in the child
process to the actor in the parent process which will redirect the messages
to the TabParent of the remote subframe.
The piece in the parent actor to create the proxied PBrowser actors is
deferred to the next commit.
Differential Revision: https://phabricator.services.mozilla.com/D17442
--HG--
extra : source : e72d9d31a8bc15e0d3e17d3bdae0b5717465c4b9
extra : intermediate-source : 12d7dba3473315edbdc2d73e3febec3ca9e987ae
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
Nika Layzell
Henri Sivonen
Ryan Hunt
Andreea Pavel
Johann Hofmann
Sylvestre Ledru
Kyle Machulis
Jonathan Kingston
Andreas Farre
Emilio Cobos Álvarez
Ehsan Akhgari
Cosmin Sabou
Tooru Fujisawa
Tim Huang
Gijs Kruitbosch
Coroiu Cristina
Tom Ritter
Jean-Yves Avenard
Neil Deakin
Lina Cambridge