Safari returns different results for current permission state

[miketaylr]

Safari is the only known UA that returns different results from this algorithm for different settings objects with the same origin. We should test which of the several possible settings objects it uses.

[miketaylr]

@jyasskin do you have any additional context on this one? Having a hard time parsing it. :)

[jyasskin]

Oh, yes, from https://www.w3.org/TR/permissions/#reading-current-states. When I poked at this several years ago, it appeared possible to have different iframes or tabs from the same origin that had different states for a given permission. For example, one could have the permission "granted" while the other had it "denied". In cases where those could directly manipulate each other's DOM (i.e. iframes and tabs with an opener relationship), that means that calling otherframe.window.permissions.query(...) could return something different from window.permissions.query(...), and similarly for calling a cross-frame function that then calls permissions.query(...). I never wrote the tests to figure out exactly what happened, and the landscape has changed enough since then that my claim about Safari might not even be true anymore.

[miketaylr]

Thank you! I'll do some testing to see if anything like this still exists, and close it out otherwise.

[miketaylr]

OK, I made the world's worst test page at https://miketaylr.com/misc/permission-window.html.

I'm not able to create a scenario where an iframe, or a new window has a permission state that isn't synced with the permission state of all other frames for the origin. I think we can just close this out and remove the note from the spec.

[marcoscaceres]

WebKit has some of the API itself implemented, so (in theory) we will pick up an interop differences with testing.