Support HTTP feature-policy to fix broken live samples on current Chrome and Safari

RESOLVED FIXED

Status

enhancement
P1
normal
RESOLVED FIXED
10 months ago
9 months ago

People

(Reporter: sheppy, Assigned: jwhitlock)

Tracking

({in-triage})

Details

(Whiteboard: [points=2])

Attachments

(1 attachment)

Reporter

Description

10 months ago
Because we don't support HTTP's feature-policy header, our live samples are now broken on release builds of Chrome. We need to implement feature-policy so that our sample iframes function again.
Assignee

Comment 1

10 months ago
Can you give an example of a broken iframe, and an affected Chrome version? They seem to work for me.
Flags: needinfo?(eshepherd)
Reporter

Comment 2

10 months ago
Here's an example that is broken on the current Chrome:

https://developer.mozilla.org/en-US/docs/Web/API/Media_Streams_API/Constraints#Result

The problem is that the iframe doesn't indicate that it wants to use the media APIs, so it doesn't get to.
Flags: needinfo?(eshepherd)
Reporter

Comment 3

10 months ago
Chrome 68 definitely doesn't work. I just tried it on my Mac.
Assignee

Comment 4

10 months ago
Thanks Sheppy, same for me. Detailed steps to reproduce:

- On a laptop or desktop with a microphone and camera, Go to https://developer.mozilla.org/en-US/docs/Web/API/Media_Streams_API/Constraints#Result. An example is loaded in an iframe.
- Click "Start" in the iframe. 

In Chrome 68.0.3440.106, there is no visual change, and these messages are printed to the console:

AudioCapture permission has been blocked because of a Feature Policy applied to the current document. See https://goo.gl/EuHzyv for more details.
VideoCapture permission has been blocked because of a Feature Policy applied to the current document. See https://goo.gl/EuHzyv for more details.

In Firefox 62.0b15, a dialog "Will you allow mdn.mozillademos.org to use your camera and microphone?" is displayed. If you select "Allow", the Actual video/audio settings are populated, and a Video is displayed.

The issue does _not_ reproduce in the development environment by default, as the example is loaded from the same domain.
Assignee

Comment 5

10 months ago
Posted image FF-Working-Demo.png
The expected results of pressing "Start", using Firefox 62.0b15 (Developer Edition) on macOS 10.13.6 on a MacBook Pro (15-inch, 2017)
This might affect Safari as well, need to investigate.
Assignee: nobody → jwhitlock
Flags: needinfo?(jwhitlock)
Keywords: in-triage
Priority: -- → P1
Whiteboard: [points=2]
Assignee

Comment 7

9 months ago
The Media_Streams_API example fails on Safari 11.1.2 with the console error:

The top-level frame has prevented a document with a different security origin to call getUserMedia.

Related links:

https://stackoverflow.com/questions/48705480/iframe-trying-to-call-getusermedia-from-a-document-with-a-different-security-ori
https://bugs.webkit.org/show_bug.cgi?id=182638

I haven't found documentation confirming if shipping Safari supports the feature-policy headers, iframe allow=, both, or neither.
Flags: needinfo?(jwhitlock)
Assignee

Comment 8

9 months ago
I can reproduce the issue locally, if I serve the demos from a different domain then the website, and serve both over SSL. I was also able to add the <iframe allow="microphone, video"> parameter, and the Web/API/Media_Streams_API/Constraints demo then works in Firefox, Chrome, and Safari. All three browsers continue to ask for user confirmation to use the hardware.

The code change to fix the issue is small. However, many changes were needed to test existing functionality of the {{EmbedLiveSample}} macro, to configure a different demo domain in Kuma and KumaScript, and to add SSL to the development environment (yet again). There are many PRs open across several repos:

- https://github.com/mdn/sprints/issues/401 - MDN sprint issue
- https://github.com/mdn/kumascript/pull/777 - Configure sample server URL
- https://github.com/mdn/kumascript/pull/785 - Test EmbedLiveSample
- https://github.com/mdn/kumascript/pull/786 - Set <iframe allow=> attribute
- https://github.com/mdn/infra/pull/46 Configure sample server URL
- https://github.com/mozilla/kuma/pull/4940 - Refactor iframe allow list
- https://github.com/mozilla/kuma/pull/4950 - SSL configuration
- https://github.com/mozilla/kuma/pull/4951 - Configure sample server URL
- https://github.com/mozilla/kuma/pull/4952 - Refactor content cleaning
- https://github.com/mozilla/kuma/pull/4953 - Disable iframe filtering, or extend patterns
- https://github.com/mozilla/kuma/pull/4956 - Allow <iframe allow=> attribute
Status: NEW → ASSIGNED
Summary: Support HTTP feature-policy to fix broken live samples on recent production Chrome releases → Support HTTP feature-policy to fix broken live samples on current Chrome and Safari

Comment 9

9 months ago
Commits pushed to master at https://github.com/mdn/kumascript

https://github.com/mdn/kumascript/commit/a45b11443b533a0b402dfaea442681bec97b5ac3
bug 1482159: Add tests for LiveSampleURL

Test most of current behaviour of LiveSampleURL, before using a
configuration item for the live sample base URL.

https://github.com/mdn/kumascript/commit/10df433327dfacf1e8564d760689d0a3cbb8a3d6
bug 1482159: Add sample server URL to config

Add the live sample base URL as an environment-overridable configuraton,
and use it in the LiveSampleURL macro to switch to the live sample
server hostname. The default configuration is the production value.

The tests for EmbedLiveSample also need this config.

This also switches to the WHATWG URL class, which properly encodes the
URLs.

https://github.com/mdn/kumascript/commit/40dcd98a8f79d862baf24f27f0bf47700f8325a2
bug 1482159: Move common setup to beforeEachMacro

https://github.com/mdn/kumascript/commit/6773791543da465ec3fb7beee5de95ef4e0ecef4
Merge pull request #777 from jwhitlock/live-sample-url-1482159

bug 1482159: Get sample server from config for LiveSampleURL

Comment 10

9 months ago
Commits pushed to master at https://github.com/mozilla/kuma

https://github.com/mozilla/kuma/commit/0cb94bc0d40a1c5514b74d5e5d02423b01c2801b
bug 1482159: Set live samples URL for Kumascript

Use the ATTACHMENT_HOST setting to customize the live samples base URL
for KumaScript.

https://github.com/mozilla/kuma/commit/bc68f64fadd1fc7c3c500a79f26963f9b0677ac8
Merge pull request #4951 from jwhitlock/live-samples-1482159

bug 1482159: Set live samples URL for Kumascript

Comment 11

9 months ago
Commit pushed to master at https://github.com/mdn/kumascript

https://github.com/mdn/kumascript/commit/cc1e5c3c154f7748f7f0f044a5fb38a64981832a
EmbedLiveSample: Add allow="feature" parameter

Add a seventh optional argument that includes an allow= parameter to
allow restricted features to be used in an iframe. See bug 1482159.

Comment 12

9 months ago
Commits pushed to master at https://github.com/mozilla/kuma

https://github.com/mozilla/kuma/commit/a3f5fb16657767c56a1675072ba3f7113fb51843
bug 1482159: Allow allow attribute for iframes

The allow value is a semicolon-separated list of restricted features to
allow an iframe to use. In Chrome and Safari, this is required for some
demos (such as those using the video camera) to run.  These browsers
still ask for the user's permission to use the feature.

https://github.com/mozilla/kuma/commit/6e7fc6489836b9824fa40c65bf61c50ad4c67b87
Merge pull request #4956 from jwhitlock/iframe-allow-1482159

bug 1482159: Allow allow attribute for iframes
Assignee

Comment 13

9 months ago
I misspoke in comment 8, multiple features are split by semicolons, not commas, so it would be <iframe allow="microphone; video">.

This change has been pushed to production, and I updated the document in revision 1411870:

https://developer.mozilla.org/en-US/docs/Web/API/Media_Streams_API/Constraints$compare?to=1411870&from=1401022

The live sample now works in Firefox, Chrome, and Safari.
Status: ASSIGNED → RESOLVED
Last Resolved: 9 months ago
Resolution: --- → FIXED
You need to log in before you can comment on or make changes to this bug.