Closed Bug 1697680 Opened 2 months ago Closed 2 months ago

Disable Presentation API on GeckoView Nightly

Categories

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

Unspecified
Android
enhancement

Tracking

()

RESOLVED FIXED
88 Branch
Tracking Status
firefox88 --- fixed

People

(Reporter: m_kato, Assigned: saschanaz)

References

Details

(Keywords: dev-doc-complete)

Attachments

(1 file)

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.

Is there a tracking issue for GeckoView to enable it? Do we want to maintain this API at all in Gecko?

Flags: needinfo?(jstutte)

Hi :overholt, do you have an updated answer for comment #1 since https://bugzilla.mozilla.org/show_bug.cgi?id=1371346#c3?

Flags: needinfo?(overholt)

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.

Flags: needinfo?(overholt)
Flags: needinfo?(jstutte)

Thanks, I'll just disable this then.

Severity: -- → S3
Assignee: nobody → krosylight

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.

Ah, I somehow misunderstood comment #3. Let's remove this altogether since no one is really using this.

Pushed by krosylight@mozilla.com:
https://hg.mozilla.org/integration/autoland/rev/3c458ed737cd
Remove Presentation API implementation r=smaug,agi
Status: NEW → RESOLVED
Closed: 2 months ago
Resolution: --- → FIXED
Target Milestone: --- → 88 Branch

This is sad.

See Also: → 1699332

fabrice, do you have still use for the API?

(See also comment 3)

(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.

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?

Flags: needinfo?(krosylight)

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?

Flags: needinfo?(krosylight) → needinfo?(annevk)

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.

BTW, I doubt Firefox (and Fenix) ever really exposed navigator.presentation per my mozregression test and the current Fenix 87 behavior?

For the release notes my leaning is to just say FF88 removes support for the API.

No objection from me 👍

I rather we don't say anything unless we actually had support for it. I would classify this as code cleanup, if anything.

Flags: needinfo?(annevk)

OK, rel note removed again, compat-data clarified, and docs complete. See https://github.com/mdn/content/issues/3461 for the docs work.

You need to log in before you can comment on or make changes to this bug.