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 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
With the new loading model for frame scripts, lexical variables defined in a
global frame script are not available to other frame scripts.
Additionally, scripts loaded into a context object by the subscript loader
should not depend on being able to access properties of the message manager as
if they were globals.
MozReview-Commit-ID: 6QEyA1sBVOV
--HG--
extra : rebase_source : d3a7820104645dc356bdf8ea660b970e1f6c20e7
There's no particular reason for us to have this interface. The only consumer
is JS-implemented, and the only caller has JS values to start with; we can just
pass these as jsval.
The changes made to this test make the test failure messages more useful. The
test is disabled because the test fails on some platforms. The failures seem
to indicate that, after a Find for text with multiple matches, the match that
is selected is not the first match after the currently highlighted text. Other
expected success indicators like total number of matches are correct.
Bug 1458393 has been opened to investigate this differing behavior and
re-enable the test.
MozReview-Commit-ID: 8Jwr9mKNzGr
--HG--
extra : rebase_source : a8a79a85e08dc5fdc7efe6b14f74a9bd18cb8864
This also removes any redundant Ci.nsISupports elements in the interface
lists.
This was done using the following script:
acecb401b7/processors/chromeutils-generateQI.jsm
MozReview-Commit-ID: AIx10P8GpZY
--HG--
extra : rebase_source : a29c07530586dc18ba040f19215475ac20fcfb3b
This patch goes through and changes a bunch of places in our tree which mention
this bug to use the new feature, making the methods more strongly typed.
There are probably more places in tree which could be changed, but I didn't try
to find them.
The new struct is in LayersTypes.h, all the rest of the changes are just
replacing existing uint64_t instances with the new LayersId struct.
Note that there is one functional change, in
CompositorBridgeParent::DeallocPWebRenderBridgeParent, where we now
correctly convert the PipelineId to a LayersId before using it to index
into sIndirectLayerTrees, whereas before we were incorrectly just using
the mHandle part of the PipelineId.
MozReview-Commit-ID: GFHZSZiwMrP
--HG--
extra : rebase_source : d2b274f63aaee2ee9bba030297e0a37a19af0d6c
nsFrameLoader is on WebIDL bindings, so those QIs are no-ops anyway, unless the given object is no a frameloader to start with.
MozReview-Commit-ID: IPiW70H5NPc
The change from "docShell" to "mDocShell" for the SetName call in the
OwnerIsMozBrowserFrame case in nsFrameLoader::MaybeCreateDocShell is a
drive-by correctness fix for a bug the rename of "docShell" to "parentDocShell"
caught: setting the name of our _parent_ docshell based on the name attr of our
owner makes no sense.
MozReview-Commit-ID: DwnWt8jTokV
Ryan Hunt
Daniel Varga
Boris Zbarsky
Julian Descottes
Mark Banner
Nicholas Nethercote
Ehsan Akhgari
Noemi Erli
Gijs Kruitbosch
Jason Orendorff
Cosmin Sabou
Tooru Fujisawa
Kris Maglione
Jan de Mooij
Olli Pettay
Brad Werth
Adrian Wielgosik
Nika Layzell
Kartikaya Gupta