LGTM3 On Tue, Dec 14, 2021 at 4:12 PM Mike Taylor <miketa...@chromium.org> wrote:
> LGTM2 > > On 12/14/21 10:05 AM, Camille Lamy wrote: > > 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 name Because 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 bug https://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 > <https://groups.google.com/a/chromium.org/d/msgid/blink-dev/1544fa2d-29aa-475b-948d-e04208d8ebcdn%40chromium.org?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/55dde308-ffc9-196a-aafd-b435ae852544%40chromium.org > <https://groups.google.com/a/chromium.org/d/msgid/blink-dev/55dde308-ffc9-196a-aafd-b435ae852544%40chromium.org?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/CAL5BFfUv1NhFgU9A3fCicL3mRNi8j7L2PcXViNOC%2BAWuUbNkwQ%40mail.gmail.com.