We allow swapping frameloaders between unrelated documents, so we need to
reparent wrappers when the owner content changes.
MozReview-Commit-ID: LNIf4ZrCZLo
--HG--
extra : rebase_source : 8041d1601962d61e675e78e3447c7772eee89df0
XPConnect wrapper overhead for this interface has been showing up heavily in a
lot of my profiles, in some places accounting for 50ms of the 80ms we spend
getting getting <browser> messageManagers. This improves the situation
considerably.
MozReview-Commit-ID: 9d1hCORxsYG
--HG--
rename : dom/base/nsIFrameLoader.idl => dom/webidl/FrameLoader.webidl
extra : rebase_source : d8a1fc1a19632ba36a9fc6f63873f7534671a13b
Editor treated in nsFrameLoader is always HTMLEditor. So, it should treat the editor as is.
MozReview-Commit-ID: 7bZMbLGKsED
--HG--
extra : rebase_source : 47c22423062cd724551ad3b4fde168e03891b4c7
This patch makes the following changes to the macros.
- Removes PROFILER_LABEL_FUNC. It's only suitable for use in functions outside
classes, due to PROFILER_FUNCTION_NAME not getting class names, and it was
mostly misused.
- Removes PROFILER_FUNCTION_NAME. It's no longer used, and __func__ is
universally available now anyway.
- Combines the first two string literal arguments of PROFILER_LABEL and
PROFILER_LABEL_DYNAMIC into a single argument. There was no good reason for
them to be separate, and it forced a '::' in the label, which isn't always
appropriate. Also, the meaning of the "name_space" argument was interpreted
in an interesting variety of ways.
- Adds an "AUTO_" prefix to PROFILER_LABEL and PROFILER_LABEL_DYNAMIC, to make
it clearer they construct RAII objects rather than just being function calls.
(I myself have screwed up the scoping because of this in the past.)
- Fills in the 'js::ProfileEntry::Category::' qualifier within the macro, so
the caller doesn't need to. This makes a *lot* more of the uses fit onto a
single line.
The patch also makes the following changes to the macro uses (beyond those
required by the changes described above).
- Fixes a bunch of labels that had gotten out of sync with the name of the
class and/or function that encloses them.
- Removes a useless PROFILER_LABEL use within a trivial scope in
EventStateManager::DispatchMouseOrPointerEvent(). It clearly wasn't serving
any useful purpose. It also serves as extra evidence that the AUTO_ prefix is
a good idea.
- Tweaks DecodePool::SyncRunIf{Preferred,Possible} so that the labelling is
done within them, instead of at their callsites, because that's a more
standard way of doing things.
--HG--
extra : rebase_source : 318d1bc6fc1425a94aacbf489dd46e4f83211de4
All the instances are converted as follows.
- nsAFlatString --> nsString
- nsAFlatCString --> nsCString
--HG--
extra : rebase_source : b37350642c58a85a08363df2e7c610873faa6e41
Every JS plugin is assigned a unique ID. When an instance of a JS plugin is created the
frame loader that we use to load the plugin's handler URI will create a special
TabContext. This TabContext causes the ContentParent to use the process for this specific
JS plugin (creating one if it hasn't already) when it creates the PBrowser actors.
This causes the iframes for all the instances of a specific JS plugin to be grouped in the
same process.
--HG--
extra : rebase_source : c39560bdf66cda1a005c7b823b3a46e4734878a4
extra : source : 9cba1db527c7eed4371c9f4caf96fd942608cab6
Since we now want to support APZ for remote frameloaders in popups, but do not
want to needlessly enable it in simple popup widgets which should never host
remote content, we need to prevent remote content from being loaded into those
popups.
MozReview-Commit-ID: WfjMC2p2eK
Currently, we only correctly support remote layer trees for frameloaders that
use the same layer manager as their document. Since we need to be able to host
remote <browser> content in popup widgets for remote WebExtensions, we need to
tie the frameloaders to the layer manager of their host element, rather than
the root layer manager for the document.
MozReview-Commit-ID: 4RCsamFBiQw
Since we now want to support APZ for remote frameloaders in popups, but do not
want to needlessly enable it in simple popup widgets which should never host
remote content, we need to prevent remote content from being loaded into those
popups.
MozReview-Commit-ID: WfjMC2p2eK
--HG--
extra : rebase_source : 51704fa761053e947a2c56706627c8ae903790ee
extra : histedit_source : 463b2c88c28476a824bc2951e0731453016aaa2b
Currently, we only correctly support remote layer trees for frameloaders that
use the same layer manager as their document. Since we need to be able to host
remote <browser> content in popup widgets for remote WebExtensions, we need to
tie the frameloaders to the layer manager of their host element, rather than
the root layer manager for the document.
MozReview-Commit-ID: 4RCsamFBiQw
--HG--
extra : rebase_source : 86bca4ae1c012ff1bb84a9ad796be311cfe580f6
extra : histedit_source : 19577d69430adc8cb38c195f13db2c6de6605c4c
This patch replaces the usage of sNextTabParent pointer to store the next
PBrowser parent actor to be used by the next frame loader with the
following information:
* In the case where the content JS has requested a new tab, the ID of the
next TabParent will be stored on the <xul:browser> element.
* In the case where the content JS has requested a new window, the ID of
the next TabParent will be stored on the created nsXULWindow.
In bug 1147911, the concept of a remoteType was added to a xul:browser.
This was an attribute which would control the type of remote process was
intended to be used to load the page.
In order to swap two frameLoaders, it has always been necessary for them
to either both contain remote content, or both contain non-remote
content. This check is made in nsFrameLoader::SwapWithOtherLoader, by
checking `IsRemoteFrame() != aOther->IsRemoteFrame()`, and then
returning `NS_ERROR_NOT_IMPLEMENTED` if that was not the case.
In the follow-up bug 1317293, the check which is being removed here was
added to ensure that the remoteType of two frameLoaders which are being
swapped also matched. This was not a technical limitation, but rather
something which "seemed to make sense to do".
This bug removes that check as it is not a technical limitation and
causes problems in edge cases around Large-Allocation processes now that
the remoteType is being used to denote a Large-Allocation process.
Namely, it means that attempting to drag a Large-Allocation window into
a new window when at the Large-Allocation process cap will fail, due to
being unable to create a new Large-Allocation process in the new window
to swap with.
The new swapping of the attributes which is added below is done with the
intent that the `remoteType` attribute of the xul:browser element should
match the `remoteType` attribute of the frameLoader inside of it at all
times. As the swap can now occur between two different `remoteType`s,
this is necessary to keep that constraint.
MozReview-Commit-ID: BHFgjwRGrge
This changes the `relatedBrowser` property which held a <xul:browser> to the
more explicit `sameProcessAsFrameLoader` which takes an nsIFrameLoader.
This clarifies the purpose of the property and also (by switching to the frame
loader) makes it easier to set in some contexts.
MozReview-Commit-ID: LnEvSP8zkto
--HG--
extra : rebase_source : f9f4c07995ef39f1ccd5042e9ae3df37879423b6
Kris Maglione
Masayuki Nakano
Wes Kocher
Tim Taubert
Masatoshi Kimura
Sebastian Hengst
Kris Maglione
Alphan Chen
Samael Wang
Carsten "Tomcat" Book
Bill McCloskey
Nicholas Nethercote
Andreas Farre
Michael Layzell
Peter Van der Beken
Andrea Marchesini
Andrew McCreight
Kartikaya Gupta
Olli Pettay
Ting-Yu Chou
Ehsan Akhgari
Manish Goregaokar
Yoshi Huang
Mats Palmgren
Benjamin Smedberg
J. Ryan Stinnett
Bob Owen