Thanks Mason! I wasn't sure if it was possible to share it cross-origin, 
hence my question. If you can only get a non-shared copied version, then 
this is fine from a security POV.

On Tuesday, December 14, 2021 at 4:53:52 AM UTC+1 Mason Freed wrote:

> Thanks Alex! I did file a TAG review for ObservableArray and this first 
> use by adoptedStyleSheets 
> <https://github.com/w3ctag/design-reviews/issues/693>. No response yet.
>
> On Mon, Dec 13, 2021 at 4:03 PM Alex Russell <slightly...@chromium.org> 
> wrote:
>
>> Thanks Mason, that matches my understanding of the situation too.
>>
>> Can you please file an FYI with the TAG to let them know this new type is 
>> being put into use? It is often helpful for them to stay informed of new 
>> WebIDL primitives that they can suggest to others to help drive consistency.
>>
>> Sending LGTM1 in the tool.
>>
>> On Wednesday, December 8, 2021 at 3:49:55 PM UTC-8 Mason Freed wrote:
>>
>>> Hi Camille,
>>>
>>> Thanks for the question. I guess I have two points/questions:
>>> 1. That sounds like a general question about adoptedStyleSheets (which 
>>> we shipped a few years ago), and isn't at all particular to the conversion 
>>> from FrozenArray to ObservableArray. But did I miss something relevant 
>>> about this change?
>>> 2. Can you help me understand how you'd go about sharing a single 
>>> CSSStyleSheet between cross-origin documents? If you passed it around via 
>>> postMessage, it'd be a (structured clone) copy, so it would no longer be 
>>> shared. I agree that it'd be a (huge) privacy concern if this were 
>>> possible, but I don't see how it could be done. I'm sure I'm missing 
>>> something - perhaps give me more specifics and I'm happy to dig further.
>>>
>>> Thanks,
>>> Mason
>>>
>>>
>>> On Tue, Dec 7, 2021 at 8:04 AM Camille Lamy <cl...@chromium.org> wrote:
>>>
>>>> Hi Mason,
>>>>
>>>> We reviewed this intent in the S&P review today, and we were not quite 
>>>> clear on the scope of the change. In particular, is it possible for 
>>>> cross-origin documents to share the adoptedStyelSheets? If so, can a style 
>>>> sheet used across cross-origin documents be modified and the modifications 
>>>> apply cross-origin as well? If so, this would be a security and privacy 
>>>> concern.
>>>>
>>>> Thanks!
>>>> Camille
>>>>
>>>> On Wednesday, December 1, 2021 at 7:09:08 PM UTC+1 Mason Freed wrote:
>>>>
>>>>> On Tue, Nov 30, 2021 at 8:40 AM Mason Freed <mas...@chromium.org> 
>>>>> wrote:
>>>>>
>>>>>> Was ObservableArray and its use in the web platform reviewed by the 
>>>>>>> TAG? If not then I think it should be, as there are plans to use it in 
>>>>>>> more 
>>>>>>> places than just this. 
>>>>>>>
>>>>>>
>>>>>> No, it wasn't. This is a good suggestion - I'll open a TAG review for 
>>>>>> ObservableArray and this conversion of adoptedStyleSheets. There 
>>>>>> definitely 
>>>>>> are plans to expand its use on the platform. 
>>>>>>
>>>>>
>>>>> TAG review filed <https://github.com/w3ctag/design-reviews/issues/693>
>>>>> . 
>>>>>
>>>>>  
>>>>>
>>>>>>  
>>>>>>
>>>>>>>
>>>>>>>>
>>>>>>>> Risks
>>>>>>>>
>>>>>>>>
>>>>>>>> Interoperability and Compatibility
>>>>>>>>
>>>>>>>> Chromium is the only shipped implementation of adoptedStyleSheets. 
>>>>>>>> Gecko would like to ship this feature, but has been waiting for the 
>>>>>>>> resolution of this issue (FrozenArray vs. ObservableArray) to ship 
>>>>>>>> their 
>>>>>>>> implementation. This should unblock Gecko [1]. The Edge team supports 
>>>>>>>> this 
>>>>>>>> change [2]. WebKit continues to be skeptical [3] of this usefulness of 
>>>>>>>> this 
>>>>>>>> feature, despite the general agreement of the rest of the web 
>>>>>>>> components 
>>>>>>>> community [4], and the support of the developer community [5][6][7]. 
>>>>>>>> So the 
>>>>>>>> interop risk is mainly that WebKit decides not to implement this 
>>>>>>>> feature. 
>>>>>>>> Compat risks (from the change from FrozenArray to ObservableArray) 
>>>>>>>> should 
>>>>>>>> be minimal, as the same re-assignment semantics will continue to work. 
>>>>>>>> As 
>>>>>>>> documentation improves, and usage expands, we expect re-assignment 
>>>>>>>> usage to 
>>>>>>>> wane, and mutation (e.g. adoptedStyleSheets.push()) to expand. [1] 
>>>>>>>> https://github.com/WICG/construct-stylesheets/issues/45#issuecomment-834749590
>>>>>>>>  
>>>>>>>> [2] 
>>>>>>>> https://github.com/whatwg/webidl/issues/1027#issuecomment-940204556 
>>>>>>>> [3] 
>>>>>>>> https://github.com/WICG/construct-stylesheets/issues/45#issuecomment-826036758
>>>>>>>>  
>>>>>>>> [4] 
>>>>>>>> https://github.com/WICG/construct-stylesheets/issues/45#issuecomment-825055766
>>>>>>>>  
>>>>>>>> [5] 
>>>>>>>> https://github.com/WICG/construct-stylesheets/issues/45#issuecomment-577941622
>>>>>>>>  
>>>>>>>> [6] 
>>>>>>>> https://github.com/WICG/construct-stylesheets/issues/45#issuecomment-827229881
>>>>>>>>  
>>>>>>>> [7] 
>>>>>>>> https://github.com/WICG/construct-stylesheets/issues/45#issuecomment-827234689
>>>>>>>>
>>>>>>>
>>>>>>> I appreciate your extensive efforts to achieve consensus and a good 
>>>>>>> design. The result is in a spec and has broad consensus, which is great!
>>>>>>>
>>>>>>
>>>>>> Thanks! It has definitely taken some time.
>>>>>>  
>>>>>>
>>>>>>> Gecko: Positive (
>>>>>>>> https://github.com/whatwg/webidl/issues/1027#issuecomment-940204556
>>>>>>>> )
>>>>>>>>
>>>>>>>> WebKit: Negative (
>>>>>>>> https://github.com/WICG/construct-stylesheets/issues/45#issuecomment-826036758
>>>>>>>> )
>>>>>>>>
>>>>>>>
>>>>>>> While those two links are not signals, I think it's:
>>>>>>>
>>>>>>> * OK to not ask for a formal Gecko signal on this, if you can point 
>>>>>>> to clear evidence they are implementing. Can you provide a link?
>>>>>>>
>>>>>>> * OK to not ask for a formal webkit signal, given their negative 
>>>>>>> signal on the public issues. Another one would be redundant and likely 
>>>>>>> yield the same (negative) result.
>>>>>>>
>>>>>>
>>>>>> I appreciate it. For Gecko, the main adoptedStyleSheets bug 
>>>>>> <https://bugzilla.mozilla.org/show_bug.cgi?id=1520690> hasn't had 
>>>>>> any activity in some time, but I believe that's because the 
>>>>>> ObservableArray 
>>>>>> implementation <https://bugzilla.mozilla.org/show_bug.cgi?id=1683281> 
>>>>>> is now blocking it. That bug has had regular recent activity, getting 
>>>>>> ObservableArray implemented.
>>>>>>
>>>>>>  
>>>>>>
>>>>>>> Web developers: Strongly positive Several large web component 
>>>>>>>> developers are strongly positive on this feature and change. See 
>>>>>>>> several 
>>>>>>>> links in the "Interoperability and Compatibility Risks" section.
>>>>>>>>
>>>>>>>> Other signals:
>>>>>>>>
>>>>>>>>
>>>>>>>> Debuggability
>>>>>>>>
>>>>>>>> This feature should remain debuggable via existing JS/devtools 
>>>>>>>> infrastructure. There is good support for adoptedStyleSheets already 
>>>>>>>> in 
>>>>>>>> devtools.
>>>>>>>>
>>>>>>>>
>>>>>>>> Is this feature fully tested by web-platform-tests 
>>>>>>>> <https://chromium.googlesource.com/chromium/src/+/master/docs/testing/web_platform_tests.md>
>>>>>>>> ?Yes
>>>>>>>>
>>>>>>>> Flag nameBecause few compat risks are anticipated, and because it 
>>>>>>>> is relatively difficult to switch the representation (FrozenArray to 
>>>>>>>> ObservableArray) via a feature flag, this feature will be enabled by 
>>>>>>>> default. This will be done at the start of a new Chromium milestone 
>>>>>>>> (M99), 
>>>>>>>> and bugs will be monitored carefully in case any breakages are 
>>>>>>>> observed.
>>>>>>>>
>>>>>>>> Requires code in //chrome?False
>>>>>>>>
>>>>>>>> Tracking bughttps://crbug.com/1236777
>>>>>>>>
>>>>>>>> Estimated milestones
>>>>>>>>
>>>>>>>> No milestones specified
>>>>>>>>
>>>>>>>>
>>>>>>>> Link to entry on the Chrome Platform Status
>>>>>>>> https://chromestatus.com/feature/5638996492288000
>>>>>>>>
>>>>>>>> This intent message was generated by Chrome Platform Status 
>>>>>>>> <https://www.chromestatus.com/>.
>>>>>>>>
>>>>>>>> -- 
>>>>>>>> You received this message because you are subscribed to the Google 
>>>>>>>> Groups "blink-dev" group.
>>>>>>>> To unsubscribe from this group and stop receiving emails from it, 
>>>>>>>> send an email to blink-dev+unsubscr...@chromium.org.
>>>>>>>> To view this discussion on the web visit 
>>>>>>>> https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CAM%3DNeDijQpNhJJJUjtCzLSDrPngTHYY31H4oJrULxm%3DtxLVHew%40mail.gmail.com
>>>>>>>>  
>>>>>>>> <https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CAM%3DNeDijQpNhJJJUjtCzLSDrPngTHYY31H4oJrULxm%3DtxLVHew%40mail.gmail.com?utm_medium=email&utm_source=footer>
>>>>>>>> .
>>>>>>>>
>>>>>>>

-- 
You received this message because you are subscribed to the Google Groups 
"blink-dev" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to blink-dev+unsubscr...@chromium.org.
To view this discussion on the web visit 
https://groups.google.com/a/chromium.org/d/msgid/blink-dev/1544fa2d-29aa-475b-948d-e04208d8ebcdn%40chromium.org.

Reply via email to