You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
I have 2 top level sites www.site11.com and www.site22.com and both of them embeds www.connect11.com website which spins up a new shared worker called "Connect11SharedWorker" which takes care of keeping "master tab" information and make sure only one tab handles audio at any time.
What i have observed is when i navigate to site11.com , there is one shared worker called Connect11SharedWorker spun up and site22.com there is another shared worker with the same name "Connect11SharedWorker" is spun up too, this is problematic because there are 2 shared worker which are trying to identify the master tab and trying to handle audio. my expectation was to have the same logic in place as CHIPS while creating a new storage partition for shared worker, in this case as site22.com is recognized as the FPS site , we should have connected to the same existing shared worker instead.
Also i observed that cookies set within site11.com by connect11.com with CHIPS enabled aren't available to the shared worker spun up by connect11.com in an embedded context. My expectation here was shared worker cookie access should also follow the same CHIPS model while retrieving the cookie for the embedded context which is to look up cookie based on the partition (site11.com, connect11.com) key instead of just (connect11.com)
My questions here are
how do we prevent spinning up same shared worker multiple times per top level sites which basically takes away the meaning of true shared worker concept
could we use FPS to prevent such duplicate shared workers getting spun up?
Is there a alternative for shared worker to read data from shared storage?
When is storage partition getting rolled out?
would shared worker work seamlessly with FPS + CHIPS
The text was updated successfully, but these errors were encountered:
This is essentially a duplicate of #102, although maybe we should keep it open for now as it doesn't directly discuss shared workers. This is not a feature that's currently present in any capacity.
I have 2 top level sites www.site11.com and www.site22.com and both of them embeds www.connect11.com website which spins up a new shared worker called "Connect11SharedWorker" which takes care of keeping "master tab" information and make sure only one tab handles audio at any time.
What i have observed is when i navigate to site11.com , there is one shared worker called Connect11SharedWorker spun up and site22.com there is another shared worker with the same name "Connect11SharedWorker" is spun up too, this is problematic because there are 2 shared worker which are trying to identify the master tab and trying to handle audio. my expectation was to have the same logic in place as CHIPS while creating a new storage partition for shared worker, in this case as site22.com is recognized as the FPS site , we should have connected to the same existing shared worker instead.
Also i observed that cookies set within site11.com by connect11.com with CHIPS enabled aren't available to the shared worker spun up by connect11.com in an embedded context. My expectation here was shared worker cookie access should also follow the same CHIPS model while retrieving the cookie for the embedded context which is to look up cookie based on the partition (site11.com, connect11.com) key instead of just (connect11.com)
My questions here are
The text was updated successfully, but these errors were encountered: