1752632 - Verify that priority for processes is correct

Status: RESOLVED FIXED

(GeckoView :: General, task)

Description

[[:owlish] 🦉 PST]

One of the possible reasons for the tab reloading issue might be incorrect priority set for content processes by Gecko and/or incorrect translation of those priorities in the bindings by GV.

Investigate to make sure the priorities are correct and not being unexpectedly changed.

Comment 1

[[:owlish] 🦉 PST]

We investigated, and here are our results:

We first looked at process priority of GVE/Fenix: in Foreground the behavior matches chrome (main tab = highest priority, other tabs = background priority) but when the screen is off or when the browser is in the background, Chrome sets a higher priority for the current tab while we set background priority to all tabs.

We looked at GeckoView's Process management code. GeckoView receives a priority of either: FOREGROUND, BACKGROUND or IDLE from Gecko and sets bindings accordingly: BIND_IMPORTANT ,0 , WAIVE_PRIORITY.

Gecko sets the priority according to various parameters https://searchfox.org/mozilla-central/rev/049f3e8d328c4b6bac9bf4b27309541a2e913686/dom/ipc/ProcessPriorityManager.cpp#743-756 . One crucial parameter is whether the browser is active or not. If no browsers are active, the process will get BACKGROUND priority.
GeckoView sets a browser to inactive when it loses the surface (which happens whenver the screen is off or the app is in the background) indirectly causing us to drop the priority on the current tab.

We discussed options to make this better:

• We could guess what the current tab is by looking at what was the last active tab and ignore BACKGROUND priority when the entire app is in the background
• We could add a new priority API that lets embedders set a relative priority to GeckoSessions so they can tell us what the most important session is and consider that value in the Gecko priority code

We then discussed the API with AC to see if it's feasible for them to use it. csadilek said that an API wouldn't be too hard to implement in AC as they already have to select the active tab for extensions. Owlish mentioned that we could offer a more fine-grained API where the app can tell us about a list of “important” tabs, like the last 5 used tabs. We concluded that we want to first prioritize the “current” tab as it’s the most likely to be interesting for a user switching between the browser and another app. We can consider more complex prioritization features after that. We also realized we can use the extension "active" signal to determine which one is the current active tab for now, and see if that improves things. If it does, we can add an API to control this behaviour that can be used by apps that don't use extensions (both Fenix and Focus do use the extension API). We also decided to adjust the current process prioritization logic in Gecko and GV.

Further work is done in the bug https://bugzilla.mozilla.org/show_bug.cgi?id=1753700, and we will file bugs for the future API work once we start on that.