VsyncSource should not run when GeckoView is not visible
Categories
(GeckoView :: General, defect, P1)
Tracking
(firefox68 fixed)
Tracking | Status | |
---|---|---|
firefox68 | --- | fixed |
People
(Reporter: agi, Assigned: agi)
References
(Blocks 1 open bug)
Details
Attachments
(1 file)
For more context see https://bugzilla.mozilla.org/show_bug.cgi?id=1539263#c5 and earlier comments.
VsyncSource
runs even when the app is on the background and uses a lot of CPU power. Since we are not actually painting anything to the screen we can just not send Vsync messages until the app comes back to the foreground again.
Assignee | ||
Comment 1•5 years ago
|
||
The problem here is that we're creating a GeckoSession
which embedders don't know about here. Embedders don't call .close()
on this session which causes GeckoView to not release the native window object, leaking it until the GC gets rid of the GeckoSession
object (potentially hanging out for hours and draining resources).
Given that taking care of the lifecycle of these sessions is really hard we decided to stop doing that and let our embedders create the session instead.
Assignee | ||
Comment 2•5 years ago
|
||
This fixes a problem where Gecko would call Vsync even when the browser does
not have a surface attached to.
This can be triggered by attaching a GeckoView without a session and then
attaching a GeckoSession to the view. This causes GeckoView to create two
Windows, one of which never gets put in the background causing Gecko to think
the browser is still visible.
The GeckoSession should be cleaned up by the GC but this may take a long time.
To avoid this footgun we just don't create a GeckoSession when there isn't one
already attached to the GeckoView, logging a warning in case the embedder is
confused by the blank screen.
Pushed by asferro@mozilla.com: https://hg.mozilla.org/integration/autoland/rev/82ec6a86a2bc Don't create a GeckoSession if there isn't one. r=geckoview-reviewers,esawin,snorp
Comment 4•5 years ago
|
||
bugherder |
Description
•