The priority manager tracks which browser parents are active in each process,
so it needs to be told when a browser parent is no longer active. This
is currently implemented by observing ipc:browser-destroyed, which happens
in BrowserHost::DestroyComplete().
However, with Fission, not all BrowserParents are held by BrowserHosts. I
don't think this is an issue right now, but if the priority manager is going
to properly prioritize processes due to the presence of active non-top-level
frames, then it needs to also deprioritize them when they go away.
This patch deals with this situation by directly telling the priority
manager that the browser parent is becoming inactive via the existing
ActivityChanged method, in the BrowserParent::Deactivated() method,
which is called when a browser parent is being destroyed or entering
the BF cache. I think it makes sense in both cases that we no longer
want to prioritize the process that the page is in.
This does mean that we are telling the priority manager about more
ContentParents which is potentially more expensive, but the old code
also ended up doing a hashtable remove in every single
ParticularProcessPriorityManager, whereas the new code only does it
for one, so hopefully it is a net win overall.
(The reason for this is that in ParticularProcessPriorityManager's
OnBrowserParentDestroyed() method the browserHost->GetContentParent()
check will always return null because the browser host nulls out
mRoot immediately before it does ipc:browser-destroyed, so the hash
table remove is never skipped.)
This patch also removes the last thing that ParticularProcessPriorityManager
was observing, so it no longer needs to be an nsIObserver.
Differential Revision: https://phabricator.services.mozilla.com/D111654
As of the next patch, it won't be used just for indicating the
activity of an entire tab, so let's rename it.
Also alphabetize the order of some forward declarations.
Differential Revision: https://phabricator.services.mozilla.com/D111701
ParticularProcessPriorityManager observes remote-browser-shown and recomputes
the priority for the given browser. This patch eliminates the observer call
and instead makes the frame loader do a direct call.
I think doing it this way is a little clearer, and also the next patch will
eliminate the other reason ParticularProcessPriorityManager is an observer,
which will let us not not register something as an observer for every content
process, which I think is also good.
There should be no change in behavior.
Differential Revision: https://phabricator.services.mozilla.com/D111653
Also remove the default arguments. This function is only called in a single
place, so drop some of the unnecessary generality.
Differential Revision: https://phabricator.services.mozilla.com/D110709
The only reason to immediate create a ParticularProcessPriorityManager
when a ContentParent is created is to ensure that the test only
observer notification for process-created is accurate, but no test
actually listens for it, so we can delete the test notification
and then stop observing ipc:content-created.
Differential Revision: https://phabricator.services.mozilla.com/D110708
This patch was generated by running:
```
perl -p -i \
-e 's/^(\s+)([a-zA-Z0-9.]+) = NS_ConvertUTF8toUTF16\((.*)\);/\1CopyUTF8toUTF16(\3, \2);/;' \
-e 's/^(\s+)([a-zA-Z0-9.]+) = NS_ConvertUTF16toUTF8\((.*)\);/\1CopyUTF16toUTF8(\3, \2);/;' \
$FILE
```
against every .cpp and .h in mozilla-central, and then fixing up the
inevitable errors that happen as a result of matching C++ expressions with
regexes. The errors fell into three categories:
1. Calling the convert functions with `std::string::c_str()`; these were
changed to simply pass the string instead, relying on implicit conversion
to `mozilla::Span`.
2. Calling the convert functions with raw pointers, which is not permitted
with the copy functions; these were changed to invoke `MakeStringSpan` first.
3. Other miscellaneous errors resulting from over-eager regexes and/or the
replacement not being type-aware. These changes were reverted.
Differential Revision: https://phabricator.services.mozilla.com/D88903
CLOSED TREE
Backed out changeset 51d7c644a1e6 (bug 1650163)
Backed out changeset 3d2b6908447a (bug 1650163)
Backed out changeset 79141707d47b (bug 1650163)
The inclusions were removed with the following very crude script and the
resulting breakage was fixed up by hand. The manual fixups did either
revert the changes done by the script, replace a generic header with a more
specific one or replace a header with a forward declaration.
find . -name "*.idl" | grep -v web-platform | grep -v third_party | while read path; do
interfaces=$(grep "^\(class\|interface\).*:.*" "$path" | cut -d' ' -f2)
if [ -n "$interfaces" ]; then
if [[ "$interfaces" == *$'\n'* ]]; then
regexp="\("
for i in $interfaces; do regexp="$regexp$i\|"; done
regexp="${regexp%%\\\|}\)"
else
regexp="$interfaces"
fi
interface=$(basename "$path")
rg -l "#include.*${interface%%.idl}.h" . | while read path2; do
hits=$(grep -v "#include.*${interface%%.idl}.h" "$path2" | grep -c "$regexp" )
if [ $hits -eq 0 ]; then
echo "Removing ${interface} from ${path2}"
grep -v "#include.*${interface%%.idl}.h" "$path2" > "$path2".tmp
mv -f "$path2".tmp "$path2"
fi
done
fi
done
Differential Revision: https://phabricator.services.mozilla.com/D55442
--HG--
extra : moz-landing-system : lando
The inclusions were removed with the following very crude script and the
resulting breakage was fixed up by hand. The manual fixups did either
revert the changes done by the script, replace a generic header with a more
specific one or replace a header with a forward declaration.
find . -name "*.idl" | grep -v web-platform | grep -v third_party | while read path; do
interfaces=$(grep "^\(class\|interface\).*:.*" "$path" | cut -d' ' -f2)
if [ -n "$interfaces" ]; then
if [[ "$interfaces" == *$'\n'* ]]; then
regexp="\("
for i in $interfaces; do regexp="$regexp$i\|"; done
regexp="${regexp%%\\\|}\)"
else
regexp="$interfaces"
fi
interface=$(basename "$path")
rg -l "#include.*${interface%%.idl}.h" . | while read path2; do
hits=$(grep -v "#include.*${interface%%.idl}.h" "$path2" | grep -c "$regexp" )
if [ $hits -eq 0 ]; then
echo "Removing ${interface} from ${path2}"
grep -v "#include.*${interface%%.idl}.h" "$path2" > "$path2".tmp
mv -f "$path2".tmp "$path2"
fi
done
fi
done
Differential Revision: https://phabricator.services.mozilla.com/D55442
--HG--
extra : moz-landing-system : lando
Converts dom.ipc.processPriorityManager.backgroundPerceivableGracePeriodMS and dom.ipc.processPriorityManager.backgroundGracePeriodMS to static prefs and removes the initializer function they were in, as they were the last prefs initialized there.
Differential Revision: https://phabricator.services.mozilla.com/D40702
--HG--
extra : moz-landing-system : lando
It's possible for front-end references to nsIRemoteTab to outlive the IPDL actor. When
this happens, we should ignore methods and property accesses.
The one special case is that some code expects to be able to
access the TabId after the browser has been destroyed. For this
we can just cache the ID.
Differential Revision: https://phabricator.services.mozilla.com/D31449
--HG--
extra : source : 9b79caa460a01a7bdf9c27ede487de0ec642ae0b
extra : histedit_source : ec32bc78fac57f523b4c1b2aef08fddfccfbe546%2C8770eefa09a764733a09d8256ef9b3e2f04244df
This commit moves the actual implementation of nsIRemoteTab from BrowserParent
to BrowserHost, without any functional changes.
Differential Revision: https://phabricator.services.mozilla.com/D31445
--HG--
extra : source : d25963c72ff7981990660050182a82ea3e935f53
This commit removes nsIRemoteTab as a parent class from BrowserParent,
so that BrowserHost is the only concrete implementation of nsIRemoteTab.
Some static_cast's are updated to cast to BrowserHost, and other places
have to be updated to pass a BrowserHost instead of a BrowserParent.
WindowGlobalParent had a getter to return it's managing BrowserParent
as a nsIRemoteTab. I couldn't find a use of this in-tree, so I've just
opt-ed to remove it. If there's a use-case, we can add something back
in.
Differential Revision: https://phabricator.services.mozilla.com/D31444
--HG--
extra : source : 810b7371987139844429d0206f9da6a7701a1efc
This commit moves the actual implementation of nsIRemoteTab from BrowserParent
to BrowserHost, without any functional changes.
Differential Revision: https://phabricator.services.mozilla.com/D31445
--HG--
extra : rebase_source : 2e6533dfa69a3278300eb70d5258bcd0a3aba68b
extra : histedit_source : a26ba68b78eb6d16cdffbc630f4410c5dd46a367
This commit removes nsIRemoteTab as a parent class from BrowserParent,
so that BrowserHost is the only concrete implementation of nsIRemoteTab.
Some static_cast's are updated to cast to BrowserHost, and other places
have to be updated to pass a BrowserHost instead of a BrowserParent.
WindowGlobalParent had a getter to return it's managing BrowserParent
as a nsIRemoteTab. I couldn't find a use of this in-tree, so I've just
opt-ed to remove it. If there's a use-case, we can add something back
in.
Differential Revision: https://phabricator.services.mozilla.com/D31444
--HG--
extra : rebase_source : 63070e3c2b90c9134f9106028e124935c8dad009
extra : histedit_source : 807f2ff684d86008077be07b0894f39a925fe778
nsITabParent is exposed to frontend code and is generally used as a representation of a remote tab. We could just rename the interface to nsIBrowserParent and worry about it later, but I think it's better to rename the interface to nsIRemoteTab so that we can later work on splitting the interface away from the PBrowser protocol.
Note: Some frontend code refers to a TabParentId. This commit renames this to RemoteTabId. We need to figure out the purpose of TabId with fission.
Differential Revision: https://phabricator.services.mozilla.com/D28132
--HG--
rename : dom/interfaces/base/nsITabParent.idl => dom/interfaces/base/nsIRemoteTab.idl
extra : rebase_source : 9d8a1790a7bb10195ad063644d1a93d63b2afb72
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
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
