Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

WebKit export of https://bugs.webkit.org/show_bug.cgi?id=198078 #16940

Conversation

youennf
Copy link
Contributor

@youennf youennf commented May 21, 2019

Copy link
Collaborator

@wpt-pr-bot wpt-pr-bot left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Already reviewed downstream.

@youennf youennf force-pushed the wpt-export-for-webkit-198078 branch from ee7802b to f7aaadc Compare May 22, 2019 01:23
@youennf youennf force-pushed the wpt-export-for-webkit-198078 branch from f7aaadc to c287d51 Compare May 22, 2019 01:24
@youennf
Copy link
Contributor Author

youennf commented May 22, 2019

@jan-ivar, could you look at Firefox stability results and see whether there is any specific issue with the test?
It seems tests are timing out at various place, the test should not be that long to run though.
Chrome and Safari seems fine and do not time out.

Copy link
Member

@jan-ivar jan-ivar left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

It looks like Firefox is failing intermittently, perhaps over bug 1517555.

We see similar results in the existing feature-policy test (how come you added a new one?)

It looks green atm, but clicking "Show History" and scroll in the Firefox box to see some intermittent red.

var crossDomain = get_host_info().HTTPS_REMOTE_ORIGIN;
function runTestInIFrame(allow, crossOrigin)
{
return new Promise(async resolve => {
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

async should never be used in promise constructor executor functions, as they lead to uncaught errors.

See https://stackoverflow.com/questions/43036229/is-it-an-anti-pattern-to-use-async-await-inside-of-a-new-promise-constructor/43050114#43050114

return new Promise(async resolve => {
window.addEventListener('message', function handler(event) {
resolve(event.data);
window.removeEventListener('message', handler);
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

There's also window.addEventListener('message', f, {once: true});

parent.postMessage(data, '*');
}, error => {
parent.postMessage('error', '*');
});
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Since we're already in an async function, this could be:

try {
  parent.postMessage(await doTest(), '*');
} catch(error) {
  parent.postMessage('error', '*');
}

{
let results = { };
try {
await navigator.mediaDevices.getUserMedia({audio : true});
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Have you considered doing a stream.getTracks().forEach(track => track.stop()); after each gUM call?

This might help on resource use, at least in the top-level domain, which I assume stays open while the iframes come and go, and perhaps help the test succeed on systems where hardware is used and is limited from being opened in multiple tabs at once maybe.

This might be related to why Firefox is failing. It may be running into bug 1517555.

@foolip
Copy link
Member

foolip commented Oct 21, 2019

@youennf looks like https://trac.webkit.org/changeset/245625/webkit was landed 5 months ago, can this export PR be unstuck? As a start, rebasing it to retrigger CI would give a view of the current state of implementation.

stephenmcgruer added a commit that referenced this pull request Aug 5, 2020
This is a manual rebase of
#16940, to see what the
results are nowadays.
stephenmcgruer added a commit that referenced this pull request Aug 5, 2020
This is a manual rebase of
#16940, to see what the
results are nowadays.
@stephenmcgruer
Copy link
Contributor

See #24889 (comment)

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

Successfully merging this pull request may close these issues.

None yet

5 participants