Responsible browsing context of an environment settings object seems fishy #1580
Comments
|
Can you explain in more detail? What do you think browsers do here for checking if scripting is disabled in workers? |
|
I have no idea. Do browsers even check that in cases like |
|
Also, scripting being disabled can't be scoped to browsing contexts given service workers. |
|
I was thinking we could tie "scripting is disabled" to an agent cluster, but I guess what really needs to happen here is that we need to figure out what browsers do and are willing to do? @foolip @smaug---- thoughts? |
|
Not sure I understand the issue here. Which "scripting is disabled" are we talking about? Some user setting or non-current-Window objects? But neither of those is bound to tab groups in Gecko (and I think tab group is what this new agent cluster is. (that 'agent' is for some reason really hard for me to understand in this context. )) Note, if a page enters bfcache, that does not kill workers but freezes them. |
|
The user agent setting to disable scripts. An agent cluster is more like a "doc group", including any associated workers. |
|
I don't think I understand the original issue, is https://html.spec.whatwg.org/#responsible-browsing-context especially fishy or is the access of any browsing context from a worker fishy? As for disabling scripts, it looks like in Blink that's a per "execution context" thing, i.e. per-document or per-worker global scope. That calls into the rough equivalent of "browsing context" to check the user setting. I can only assume it's more complicated than meets the eye. Is there a test case that could be written to show that something is amiss here, or is it "just" that the spec says funny things that doesn't obviously map to how one would implement it? |
Previously it was per-browsing context. This caused a number of problems when used from workers; it went through the "responsible document" indirection which did not exist for service workers and was racy in other cases. In theory this might be cleaner if it were per agent, i.e. if agents maintained internal consistency about disabling or enabling scripting. In practice user agents seem to have a single user-agent-wide switch, and at least some of them wire that to a per-global boolean, so we just use per-global as it fits most cleanly into existing architecture and matches at least some implementation internals. Closes #1580. Helps with #5422.
Previously it was per-browsing context. This caused a number of problems when used from workers; it went through the "responsible document" indirection which did not exist for service workers and was racy in other cases. In theory this might be cleaner if it were per agent, i.e. if agents maintained internal consistency about disabling or enabling scripting. In practice user agents seem to have a single user-agent-wide switch, and at least some of them wire that to a per-global boolean, so we just use per-global as it fits most cleanly into existing architecture and matches at least some implementation internals. Closes #1580. Helps with #5422.
Especially when it's used on worker threads. On worker threads, it seems like only
concept-bc-noscriptis used, but that still looks at the active document; that seems like a race condition.The text was updated successfully, but these errors were encountered: