Re-ship setting background tab's activeness to false - Tabs opened in the background but not switched to are considered active and waste power
Categories
(GeckoView :: General, task, P2)
Tracking
(Not tracked)
People
(Reporter: kaya, Assigned: kaya)
References
(Blocks 2 open bugs)
Details
(Whiteboard: [fxdroid] [foundation][group1][geckoview:2024H2?])
Attachments
(1 file)
As in Bug 1815015, newly created background browsers' (tabs') activeness is set to inactive by default. After running the regular train, this was backed out due to some inconsistent behavior on the telemetry data. Bug 1836795 will improve the current telemetry schema. After shipping and baking that ticket for some time, the patch that was implemented for Bug 1815015 will be re-shipped.
Assignee | ||
Updated•1 year ago
|
Updated•1 year ago
|
Assignee | ||
Updated•10 months ago
|
Assignee | ||
Updated•7 months ago
|
Updated•6 months ago
|
Updated•5 months ago
|
Updated•5 months ago
|
Assignee | ||
Comment 1•4 months ago
|
||
Updated•3 months ago
|
Comment 2•19 hours ago
|
||
Can you update the bug with its current status? Is there a bug filed on the work that's blocking it?
Assignee | ||
Comment 3•18 hours ago
|
||
We discussed this offline with Will. The extension process is using the same API in which I was trying to start off the browser's docshell inactive. Will warned me that there are some extensions that have background pages, i.e. pages with windows, even if they're invisible and that won't work without an active docshell.
I've tried to verify locally whether the inactive docshell was breaking any extensions or not. I did not spot any issues, but I'll need to follow-up with either Will or someone from his team to conclude this discussion. There's no ticket for this investigation as we haven't concluded that if this change would be a blocker. Once the discussions/investigations end and then I can create a blocker ticket if that'd be the case. I'll soon re-prioritize this task (within the next 2 weeks).
Description
•