Disable WebVR by default
Categories
(Core :: WebVR, task)
Tracking
()
People
(Reporter: mt, Assigned: jgilbert)
References
(Blocks 2 open bugs)
Details
(Keywords: dev-doc-complete)
Attachments
(1 file)
48 bytes,
text/x-phabricator-request
|
RyanVM
:
approval-mozilla-beta+
RyanVM
:
approval-mozilla-esr91+
|
Details | Review |
We're currently exposing this in Nightly and Dev Edition, plus Windows and Mac. It's an old and long deprecated API (see Bug 1635867).
Anyone using this API is probably capable of finding the pref and turning it on, but having the API available means that we have an expanded fingerprinting surface for no real gain.
Reporter | ||
Comment 1•3 years ago
|
||
I don't know if we are likely to see test failures with this, which is the only bustage that we should care about, so: https://treeherder.mozilla.org/jobs?repo=try&revision=5bc7c7b98aa139cd6b0b58a5d0cc8737da098bb0 (./mach try auto
might not generate anything useful, but it is better than the shotgun approach).
Comment 2•3 years ago
|
||
There is an existing bug regarding this here. Seems like the intention was to separate WebVR functionality from the dom.vr.enabled pref first before disabling it, but that never happened before layoffs in 2020.
Reporter | ||
Comment 3•3 years ago
|
||
Huh. Why Bugzilla failed to show me a bug with an identical title in the same component, I have no idea.
In any case, I think that the reasons Olli gave for rejecting that patch are good. This should be easier as we are not currently considering how to best retain WebXR capabilities.
Assignee | ||
Updated•3 years ago
|
Assignee | ||
Comment 4•3 years ago
|
||
Preserve testing, just disable the pref by default.
Assignee | ||
Updated•3 years ago
|
Comment 5•3 years ago
|
||
BTW, this is enabled on Windows and Mac all the way to release. It's only limited to Nightly-only on other platforms (noting that RELEASE_OR_BETA is true for DevEdition ever since Project Dawn back around ~Fx54).
Reporter | ||
Comment 6•3 years ago
|
||
Thanks for the correction; I've amended c0.
Assignee | ||
Comment 7•3 years ago
|
||
Intent to unship posted: https://groups.google.com/a/mozilla.org/g/dev-platform/c/S9ltYIfjCpg
Comment 9•3 years ago
|
||
bugherder |
Assignee | ||
Comment 10•3 years ago
|
||
Comment on attachment 9259794 [details]
Bug 1750902 - Disable dom.vr.enabled by default.
Beta/Release Uplift Approval Request
- User impact if declined: Spurious "website wants access to your VR hardware" permission dialogs.
- Is this code covered by automated tests?: No
- Has the fix been verified in Nightly?: No
- Needs manual test from QE?: No
- If yes, steps to reproduce:
- List of other uplifts needed: None
- Risk to taking this patch: Low
- Why is the change risky/not risky? (and alternatives if risky): The main risk is any users that still use this old (but functional) API that are caught off-guard.
- String changes made/needed: none
ESR Uplift Approval Request
- If this is not a sec:{high,crit} bug, please state case for ESR consideration: This is just a pref disable.
- User impact if declined: Spurious "website wants access to your VR hardware" permission dialogs.
Security bugs we may not notice due to less field testing because we've dropped support on non-ESR Firefox. - Fix Landed on Version: 98
- Risk to taking this patch: Low
- Why is the change risky/not risky? (and alternatives if risky): The main risk is any users that still use this old (but functional) API that are caught off-guard. This will be in the enterprise patchnotes though.
Updated•3 years ago
|
Comment 11•3 years ago
|
||
Comment on attachment 9259794 [details]
Bug 1750902 - Disable dom.vr.enabled by default.
Approved for 97.0b7.
Comment 12•3 years ago
|
||
bugherder uplift |
Comment 13•3 years ago
|
||
Comment on attachment 9259794 [details]
Bug 1750902 - Disable dom.vr.enabled by default.
Approved for 91.6esr.
Comment 14•3 years ago
|
||
bugherder uplift |
Updated•3 years ago
|
Comment 15•3 years ago
|
||
FYI FF98 docs work for this can be tracked in https://github.com/mdn/content/issues/12582#issuecomment-1029646325 . This includes updating browser compatibility data, release note, and making sure all the MDN docs are marked as deprecated.
Updated•3 years ago
|
Description
•