Disable Presentation API on GeckoView Nightly
Categories
(Core :: DOM: Core & HTML, enhancement)
Tracking
()
Tracking | Status | |
---|---|---|
firefox88 | --- | fixed |
People
(Reporter: m_kato, Assigned: saschanaz)
References
Details
(Keywords: dev-doc-complete)
Attachments
(1 file)
(deleted),
text/x-phabricator-request
|
Details |
Although Fennec Nightly enabled Presentation API, since GeckoView didn't implement nsIPresentationRequestUIGlue
and nsIPresentationDevicePrompt
, this API won't work on GeckoView.
When looking prefs (https://searchfox.org/mozilla-central/rev/ca910762568921c0faa34838d6a4efac2471dff1/modules/libpref/init/StaticPrefList.yaml#2471-2497), GeckoView turns on this API if GeckoView Nightly. I think that we should disable this until we implement some interfaces for this API on GeckoView.
Also, desktop removed these interfaces by bug 1371346.
Assignee | ||
Comment 1•4 years ago
|
||
Is there a tracking issue for GeckoView to enable it? Do we want to maintain this API at all in Gecko?
Assignee | ||
Comment 2•4 years ago
|
||
Hi :overholt, do you have an updated answer for comment #1 since https://bugzilla.mozilla.org/show_bug.cgi?id=1371346#c3?
Comment 3•4 years ago
|
||
Let's remove this until we have more concrete plans to work on this feature. It's been more or less abandoned since 2016 and I don't think the protocol part ever got somewhere satisfactory security- and standards-wise.
Assignee | ||
Comment 4•4 years ago
|
||
Thanks, I'll just disable this then.
Assignee | ||
Updated•4 years ago
|
Assignee | ||
Updated•4 years ago
|
Comment 5•4 years ago
|
||
Disabling seems fine, but let's file a follow-up for removal? No need to keep dead code around that people occasionally have to touch for various reasons.
Assignee | ||
Comment 6•4 years ago
|
||
Ah, I somehow misunderstood comment #3. Let's remove this altogether since no one is really using this.
Assignee | ||
Comment 7•4 years ago
|
||
Updated•4 years ago
|
Comment 9•4 years ago
|
||
bugherder |
Comment 10•4 years ago
|
||
This is sad.
Assignee | ||
Updated•4 years ago
|
Comment 11•4 years ago
|
||
fabrice, do you have still use for the API?
(See also comment 3)
Comment 12•4 years ago
|
||
(In reply to Olli Pettay [:smaug] from comment #11)
fabrice, do you have still use for the API?
(See also comment 3)
We are not actively using it, but I had some hope we would.
I understand that there is not much traction so far, but it's a bit of a chicken and egg situation... Geckoview support would actually been a great way to promote this api, allowing developers to build apps for Android TV and leverage it in an ideal context for instance.
Comment 13•4 years ago
|
||
I'm documenting this change for FF88 (tracking issue here).
Can you please confirm my understanding
- BCD issue - API removed from Android in FF88 and desktop in FF61
- This API is technically still experimental (we normally remove mark if it is implemented in release of more than one major browser)
- This API is not deprecated, just not implemented by FF.
My understanding from above is that the main reason for this removal is that the code is not doesn't work. It is being removed until such time as proper investment/implementation can be done. Is that correct?
Do you have any particular way that you'd like this "framed" for the release notes? If not, then I will simply state that FF88 removes support for the whole API.
Do you happen to know, would this whole API have required a secure context from its first introduction into Firefox?
Assignee | ||
Comment 14•4 years ago
|
||
BCD should also notice that the API never really worked on Fenix. And yeah, it's still experimental and not deprecated.
It is being removed until such time as proper investment/implementation can be done. Is that correct?
Yes, and I think we also want the spec to evolve before we decide to do anything there, but better to let Anne say for that part.
Do you have any particular way that you'd like this "framed" for the release notes? If not, then I will simply state that FF88 removes support for the whole API.
Not that in my mind, maybe Anne have some? Should we say we are not satisfied by the spec? Or mozilla-position would be the better place for that?
Comment 15•4 years ago
|
||
Thank you
Should we say we are not satisfied by the spec? Or mozilla-position would be the better place for that?
I think mozilla-position
would be the better place for that - if you want something actually done. For the release notes my leaning is to just say FF88 removes support for the API.
Assignee | ||
Comment 16•4 years ago
|
||
BTW, I doubt Firefox (and Fenix) ever really exposed navigator.presentation
per my mozregression test and the current Fenix 87 behavior?
Assignee | ||
Comment 17•4 years ago
|
||
For the release notes my leaning is to just say FF88 removes support for the API.
No objection from me 👍
Comment 18•4 years ago
|
||
I rather we don't say anything unless we actually had support for it. I would classify this as code cleanup, if anything.
Comment 19•4 years ago
|
||
OK, rel note removed again, compat-data clarified, and docs complete. See https://github.com/mdn/content/issues/3461 for the docs work.
Description
•