Closed Bug 1325428 Opened 5 years ago Closed 5 years ago

[webvr] WebVR content continues to run after navigating away from content.

Categories

(Core :: DOM: Core & HTML, defect)

defect
Not set
normal

Tracking

()

RESOLVED FIXED
mozilla54
Tracking Status
firefox54 --- fixed

People

(Reporter: caseyyee.ca, Assigned: kip)

References

Details

(Whiteboard: [webvr])

Attachments

(1 file)

Firefox should automatically exitPresent unless traversing links.

To reproduce this:
1. navigate to https://threejs.org/examples/webvr_cubes.html
2. click Enter VR
3. navigate to another page.

See that content continues to render into the headset even after navigating away.

This also causes issues when reloading content.  Performance in headset and mirrored drops by half.  I suspect that this is due to the existing scene (pre-refresh) to continue to run.
Flags: needinfo?(kgilbert)
Component: General → DOM
Product: Firefox → Core
See Also: → 1299285
Taking this bug...  It appears to be cycle-collection / garbage collection related.
Assignee: nobody → kgilbert
Flags: needinfo?(kgilbert)
Does VR not explicitly close itself when the page goes to bfcache or so?
I don't see anything WebVR related in http://searchfox.org/mozilla-central/rev/8144fcc62054e278fe5db9666815cc13188c96fa/dom/base/nsDocument.cpp#8318

The example page here seems to enter bfcache. (pagehide event's .persisted is true)
Blocks: webvr_1.1
(In reply to Olli Pettay [:smaug] from comment #2)
> Does VR not explicitly close itself when the page goes to bfcache or so?
> I don't see anything WebVR related in
> http://searchfox.org/mozilla-central/rev/
> 8144fcc62054e278fe5db9666815cc13188c96fa/dom/base/nsDocument.cpp#8318
> 
> The example page here seems to enter bfcache. (pagehide event's .persisted
> is true)

Thanks for pointing me to this function.  It seems that pages that are presenting VR content should return false in this function.  I'll give it a try and see if it fixes the issue.
Attachment #8833565 - Flags: review?(bugs)
(In reply to :kip (Kearwood Gilbert) from comment #3)
> (In reply to Olli Pettay [:smaug] from comment #2)
> > Does VR not explicitly close itself when the page goes to bfcache or so?
> > I don't see anything WebVR related in
> > http://searchfox.org/mozilla-central/rev/
> > 8144fcc62054e278fe5db9666815cc13188c96fa/dom/base/nsDocument.cpp#8318
> > 
> > The example page here seems to enter bfcache. (pagehide event's .persisted
> > is true)
> 
> Thanks for pointing me to this function.  It seems that pages that are
> presenting VR content should return false in this function.  I'll give it a
> try and see if it fixes the issue.

The attached patch seems to correct the issue, by preventing active WebVR pages from entering the bfcache.

I noticed in the try run that I see some test failures, possibly intermittent:

112 INFO TEST-UNEXPECTED-FAIL | dom/security/test/contentverifier/browser_verify_content_about_newtab2.js | Valid remote newtab page must have built-in CSP. - Got {}, expected {"csp-policies":[{"report-only":false,"script-src":["https://example.com","'unsafe-inline'"],"style-src":["https://example.com"]}]}

113 INFO TEST-UNEXPECTED-FAIL | dom/security/test/contentverifier/browser_verify_content_about_newtab2.js | Expect the following value in the result
Just a fully good testpage for Bug 1226928

I have reproduced them locally both with and without my patch applied, so I believe they are not related to the patch.

If you are too busy to review this, please advise and I'll find another.  Thanks again for the tip on bfcache!
Comment on attachment 8833565 [details]
Bug 1325428 - Disable bfcache for WebVR pages

https://reviewboard.mozilla.org/r/109788/#review111302
Attachment #8833565 - Flags: review?(bugs) → review+
Pushed by kgilbert@mozilla.com:
https://hg.mozilla.org/integration/autoland/rev/6ce29dfac81b
Disable bfcache for WebVR pages r=smaug
Blocks: 1299285
https://hg.mozilla.org/mozilla-central/rev/6ce29dfac81b
Status: NEW → RESOLVED
Closed: 5 years ago
Resolution: --- → FIXED
Target Milestone: --- → mozilla54
Component: DOM → DOM: Core & HTML
You need to log in before you can comment on or make changes to this bug.