Re: [blink-dev] Intent to Ship: Last Baseline Item Alignment

[Ian Kilpatrick]

On Mon, Oct 10, 2022 at 8:02 PM Yoav Weiss  wrote:

>
>
> On Tue, Oct 11, 2022 at 1:37 AM TAMURA, Kent  wrote:
>
>> LGTM1.
>> Two other browsers already shipped this. No doubt to proceed this.
>>
>> On Sat, Oct 8, 2022 at 4:15 AM Ian Kilpatrick 
>> wrote:
>>
>>> Contact emailsikilpatr...@chromium.org
>>>
>>> ExplainerNone
>>>
>>> Specificationhttps://drafts.csswg.org/css-align-3/#baseline-rules
>>>
>>> Summary
>>>
>>> This feature allows developers to align items within either flex or grid
>>> layout by their last baseline, instead of their first. This is done via the
>>> following properties: align-items: last baseline; /* flex/grid container */
>>> justify-items: last baseline; /* grid container */ align-self: last
>>> baseline; /* flex/grid item */ justify-self: last baseline; /* grid item */
>>>
>>>
>>> Blink componentBlink>Layout
>>> 
>>>
>>> TAG reviewNone - I don't believe CSS Align 3 ever went through Tag
>>> Review. However I'm happy to file one and cc/ the specification editors.
>>>
>>> TAG review statusNot applicable
>>>
>>> Risks
>>>
>>>
>>> Interoperability and Compatibility
>>>
>>>
>>>
>>> *Gecko*: Shipped/Shipping (note - relatively basic support)
>>>
>>> *WebKit*: Shipped/Shipping "It's complicated". WebKit currently parses
>>> "align-items: last baseline" however doesn't support it currently in layout
>>> (for Stable versions of the browser).
>>> https://caniuse.com/?search=last%20baseline
>>>  This is currently changing
>>> however with recent commits by WebKit implementing the "last baseline"
>>> behaviour. E.g. https://bugs.webkit.org/show_bug.cgi?id=245792
>>>
>>> *Web developers*: No signals
>>>
>>> *Other signals*:
>>>
>>> Activation
>>>
>>> This feature will likely be difficult to use initially for web
>>> developers for a few reasons. Support and implementation status is patchy.
>>> While adding tests for this feature...
>>> https://wpt.fyi/results/css?label=master&label=experimental&aligned&view=subtest&q=flex-align-baseline%20or%20grid-align-baseline%20or%20grid-justify-baseline
>>> 
>>> ...existing implementations typically only supported relatively simple
>>> cases well. This primarily was because various specifications which this
>>> feature interacts with didn't specify what the last baseline of various
>>> boxes should be. Additionally "@supports(align-items: last baseline)" will
>>> return true for many versions of browsers that don't have any (or partial)
>>> layout support for this feature. Web developers may rely on UA versions
>>> and/or javascript to check actual support.
>>>
>>
> This is not great.. Any ways in which we can improve the story? e.g. can
> we push for better WPT coverage? Have this feature be a part of Interop 23?
> Rename the feature into something that can be reliably detected? Something
> else?
>

We'll likely be able to incorporate these tests into interop 2023 for both
grid & flexbox which will hopefully improve interop. Renaming the feature
isn't a great option (IMO) as it describes what it does well, and Firefox
has already shipped support.

Ian


>
>
>>>
>>> WebView application risks
>>>
>>> Does this intent deprecate or change behavior of existing APIs, such
>>> that it has potentially high risk for Android WebView-based applications?
>>>
>>>
>>>
>>> Debuggability
>>>
>>> Basic CSS property debugging in DevTools.
>>>
>>>
>>> Will this feature be supported on all six Blink platforms (Windows, Mac,
>>> Linux, Chrome OS, Android, and Android WebView)?Yes
>>>
>>> Is this feature fully tested by web-platform-tests
>>> 
>>> ?Yes
>>>
>>> https://wpt.fyi/results/css?label=master&label=experimental&aligned&view=subtest&q=flex-align-baseline%20or%20grid-align-baseline%20or%20grid-justify-baseline
>>> 
>>>
>>> Flag name--enable-experimental-web-platform-features or
>>> --enable-blink-features=CSSLastBaseline
>>>
>>> Requires code in //chrome?False
>>>
>>> Tracking bughttps://bugs.chromium.org/p/chromium/issues/detail?id=885175
>>>
>>> Estimated milestones
>>>
>>> 108 or 109
>>>
>>> Anticipated spec changes
>>>
>>> We filed multiple issues related to this feature - primarily for all the
>>> different types of layout algorithms how to determine their last baseline
>>> was underspecified.
>>>
>>> Scroll container - https://github.com/w3c/csswg-drafts/issues/7660
>>>
>>> Flexbox - https://github.com/w3c/csswg-drafts/issues/7641
>>>
>>> Multicol - https://github.com/w3c/csswg-drafts/issues/7639
>>>
>>> Tables - https://github.com/w3c/csswg-drafts/issues/7

Re: [blink-dev] Intent to Ship: Last Baseline Item Alignment

[Yoav Weiss]

On Tue, Oct 11, 2022 at 1:37 AM TAMURA, Kent  wrote:

> LGTM1.
> Two other browsers already shipped this. No doubt to proceed this.
>
> On Sat, Oct 8, 2022 at 4:15 AM Ian Kilpatrick 
> wrote:
>
>> Contact emailsikilpatr...@chromium.org
>>
>> ExplainerNone
>>
>> Specificationhttps://drafts.csswg.org/css-align-3/#baseline-rules
>>
>> Summary
>>
>> This feature allows developers to align items within either flex or grid
>> layout by their last baseline, instead of their first. This is done via the
>> following properties: align-items: last baseline; /* flex/grid container */
>> justify-items: last baseline; /* grid container */ align-self: last
>> baseline; /* flex/grid item */ justify-self: last baseline; /* grid item */
>>
>>
>> Blink componentBlink>Layout
>> 
>>
>> TAG reviewNone - I don't believe CSS Align 3 ever went through Tag
>> Review. However I'm happy to file one and cc/ the specification editors.
>>
>> TAG review statusNot applicable
>>
>> Risks
>>
>>
>> Interoperability and Compatibility
>>
>>
>>
>> *Gecko*: Shipped/Shipping (note - relatively basic support)
>>
>> *WebKit*: Shipped/Shipping "It's complicated". WebKit currently parses
>> "align-items: last baseline" however doesn't support it currently in layout
>> (for Stable versions of the browser).
>> https://caniuse.com/?search=last%20baseline
>>  This is currently changing
>> however with recent commits by WebKit implementing the "last baseline"
>> behaviour. E.g. https://bugs.webkit.org/show_bug.cgi?id=245792
>>
>> *Web developers*: No signals
>>
>> *Other signals*:
>>
>> Activation
>>
>> This feature will likely be difficult to use initially for web developers
>> for a few reasons. Support and implementation status is patchy. While
>> adding tests for this feature...
>> https://wpt.fyi/results/css?label=master&label=experimental&aligned&view=subtest&q=flex-align-baseline%20or%20grid-align-baseline%20or%20grid-justify-baseline
>> 
>> ...existing implementations typically only supported relatively simple
>> cases well. This primarily was because various specifications which this
>> feature interacts with didn't specify what the last baseline of various
>> boxes should be. Additionally "@supports(align-items: last baseline)" will
>> return true for many versions of browsers that don't have any (or partial)
>> layout support for this feature. Web developers may rely on UA versions
>> and/or javascript to check actual support.
>>
>
This is not great.. Any ways in which we can improve the story? e.g. can we
push for better WPT coverage? Have this feature be a part of Interop 23?
Rename the feature into something that can be reliably detected? Something
else?


>>
>> WebView application risks
>>
>> Does this intent deprecate or change behavior of existing APIs, such that
>> it has potentially high risk for Android WebView-based applications?
>>
>>
>>
>> Debuggability
>>
>> Basic CSS property debugging in DevTools.
>>
>>
>> Will this feature be supported on all six Blink platforms (Windows, Mac,
>> Linux, Chrome OS, Android, and Android WebView)?Yes
>>
>> Is this feature fully tested by web-platform-tests
>> 
>> ?Yes
>>
>> https://wpt.fyi/results/css?label=master&label=experimental&aligned&view=subtest&q=flex-align-baseline%20or%20grid-align-baseline%20or%20grid-justify-baseline
>> 
>>
>> Flag name--enable-experimental-web-platform-features or
>> --enable-blink-features=CSSLastBaseline
>>
>> Requires code in //chrome?False
>>
>> Tracking bughttps://bugs.chromium.org/p/chromium/issues/detail?id=885175
>>
>> Estimated milestones
>>
>> 108 or 109
>>
>> Anticipated spec changes
>>
>> We filed multiple issues related to this feature - primarily for all the
>> different types of layout algorithms how to determine their last baseline
>> was underspecified.
>>
>> Scroll container - https://github.com/w3c/csswg-drafts/issues/7660
>>
>> Flexbox - https://github.com/w3c/csswg-drafts/issues/7641
>>
>> Multicol - https://github.com/w3c/csswg-drafts/issues/7639
>>
>> Tables - https://github.com/w3c/csswg-drafts/issues/7655
>>
>> Fieldset - https://github.com/w3c/csswg-drafts/issues/7656
>>
>> (and more).
>>
>> All of these issues have been resolved, and added tests.
>>
>> Link to entry on the Chrome Platform Status
>> https://chromestatus.com/feature/5093352798683136
>>
>> Links to previous Intent discussionsIntent to prototype:
>> https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CAJL3UpT5eVmfB6e-adc8exG1ouse25C_0A_2tn3fEVTwh-SetQ%40mail.gmail.c

Re: [blink-dev] Intent to Ship: Last Baseline Item Alignment

[TAMURA, Kent]

LGTM1.
Two other browsers already shipped this. No doubt to proceed this.

On Sat, Oct 8, 2022 at 4:15 AM Ian Kilpatrick 
wrote:

> Contact emailsikilpatr...@chromium.org
>
> ExplainerNone
>
> Specificationhttps://drafts.csswg.org/css-align-3/#baseline-rules
>
> Summary
>
> This feature allows developers to align items within either flex or grid
> layout by their last baseline, instead of their first. This is done via the
> following properties: align-items: last baseline; /* flex/grid container */
> justify-items: last baseline; /* grid container */ align-self: last
> baseline; /* flex/grid item */ justify-self: last baseline; /* grid item */
>
>
> Blink componentBlink>Layout
> 
>
> TAG reviewNone - I don't believe CSS Align 3 ever went through Tag
> Review. However I'm happy to file one and cc/ the specification editors.
>
> TAG review statusNot applicable
>
> Risks
>
>
> Interoperability and Compatibility
>
>
>
> *Gecko*: Shipped/Shipping (note - relatively basic support)
>
> *WebKit*: Shipped/Shipping "It's complicated". WebKit currently parses
> "align-items: last baseline" however doesn't support it currently in layout
> (for Stable versions of the browser).
> https://caniuse.com/?search=last%20baseline
>  This is currently changing
> however with recent commits by WebKit implementing the "last baseline"
> behaviour. E.g. https://bugs.webkit.org/show_bug.cgi?id=245792
>
> *Web developers*: No signals
>
> *Other signals*:
>
> Activation
>
> This feature will likely be difficult to use initially for web developers
> for a few reasons. Support and implementation status is patchy. While
> adding tests for this feature...
> https://wpt.fyi/results/css?label=master&label=experimental&aligned&view=subtest&q=flex-align-baseline%20or%20grid-align-baseline%20or%20grid-justify-baseline
> 
> ...existing implementations typically only supported relatively simple
> cases well. This primarily was because various specifications which this
> feature interacts with didn't specify what the last baseline of various
> boxes should be. Additionally "@supports(align-items: last baseline)" will
> return true for many versions of browsers that don't have any (or partial)
> layout support for this feature. Web developers may rely on UA versions
> and/or javascript to check actual support.
>
>
> WebView application risks
>
> Does this intent deprecate or change behavior of existing APIs, such that
> it has potentially high risk for Android WebView-based applications?
>
>
>
> Debuggability
>
> Basic CSS property debugging in DevTools.
>
>
> Will this feature be supported on all six Blink platforms (Windows, Mac,
> Linux, Chrome OS, Android, and Android WebView)?Yes
>
> Is this feature fully tested by web-platform-tests
> 
> ?Yes
>
> https://wpt.fyi/results/css?label=master&label=experimental&aligned&view=subtest&q=flex-align-baseline%20or%20grid-align-baseline%20or%20grid-justify-baseline
> 
>
> Flag name--enable-experimental-web-platform-features or
> --enable-blink-features=CSSLastBaseline
>
> Requires code in //chrome?False
>
> Tracking bughttps://bugs.chromium.org/p/chromium/issues/detail?id=885175
>
> Estimated milestones
>
> 108 or 109
>
> Anticipated spec changes
>
> We filed multiple issues related to this feature - primarily for all the
> different types of layout algorithms how to determine their last baseline
> was underspecified.
>
> Scroll container - https://github.com/w3c/csswg-drafts/issues/7660
>
> Flexbox - https://github.com/w3c/csswg-drafts/issues/7641
>
> Multicol - https://github.com/w3c/csswg-drafts/issues/7639
>
> Tables - https://github.com/w3c/csswg-drafts/issues/7655
>
> Fieldset - https://github.com/w3c/csswg-drafts/issues/7656
>
> (and more).
>
> All of these issues have been resolved, and added tests.
>
> Link to entry on the Chrome Platform Status
> https://chromestatus.com/feature/5093352798683136
>
> Links to previous Intent discussionsIntent to prototype:
> https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CAJL3UpT5eVmfB6e-adc8exG1ouse25C_0A_2tn3fEVTwh-SetQ%40mail.gmail.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://g

[blink-dev] Are you interested in hosting a talk at BlinkOn 17? Sign up now!

[BlinkOn Planning Committee]

bcc: blink-dev


Hi everyone,



BlinkOn 17 is fast approaching, and we're looking forward to hosting you
both in-person and virtually on November 15-17, 2022 PDT! If you haven't
already done so, don't forget to register now

.



Breakout Talks

If you'd like to host a 25-minute breakout talk (presentation, discussion,
etc.), sign up here

by Wednesday, November 2nd.

Lightning Talks

If you'd like to host a 3-minute lightning talk, sign up here

by Monday, October 24th and upload your deck by Monday, November 7th.

If you have any questions, please email us at blin...@chromium.org.

Thanks,

Victor, on behalf of the BlinkOn Planning Committee

-- 
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/CABjKNU65QLZe%3DnuBc0efC-EUhG%2BwBvVYMrubXTe79aLh%2BMPjdQ%40mail.gmail.com.

Re: [blink-dev] Debugging compressed pointers in Blink

[Stefan Zager]

Maybe add NOINLINE for good measure, but yeah, I think that should work.

On Mon, Oct 10, 2022 at 11:45 AM Daniel Cheng  wrote:

> For now, I guess it should be sufficient to add something
> to v8/include/cppgc/internal/member-storage.h like
>
> #ifndef NDEBUG  // DCHECK_IS_ON() would be nicer, but not sure what v8 uses
> extern "C" void* DecompressPointerForDebugger(uint32_t value) {
>   return cppgc::internal::CompressedPointer::Decompress(value);
> }
> #endif
>
> Which should hopefully be callable from the debugger and not eliminated by
> the linker?
>
> Daniel
>
> On Mon, 10 Oct 2022 at 11:32, Stefan Zager  wrote:
>
>> I ran into this today, and it's pretty frustrating:
>>
>> (rr) p inner_node_
>>
>> $11 = {
>>
>>= {
>>
>> raw_ = {
>>
>>   static kCompressedSentinel = 1,
>>
>>   value_ = 2148082696 <(214)%20808-2696>
>>
>> }
>>
>>   },
>>
>>= {}, > data fields>}
>> (rr) p inner_node_.Load()
>>
>> Couldn't find method blink::Member::Load
>>
>> (rr) p inner_node_.raw_.Load()
>>
>> Cannot evaluate function -- may be inlined
>>
>> (rr) p
>> cppgc::internal::CompressedPointer::Decompress(inner_node_.raw_.value_)
>>
>> Cannot evaluate function -- may be inlined
>>
>> (rr)
>>
>> I found that I can avoid the issue with this in args.gn:
>>
>> cppgc_enable_caged_heap = false
>> cppgc_enable_pointer_compression = false
>>
>> ... but I would prefer a better solution.
>>
>> On Mon, Oct 10, 2022 at 10:22 AM Ian Kilpatrick 
>> wrote:
>>
>>> Is there a bug to follow regarding the debuggability of the pointers?
>>>
>>> Ian
>>>
>>> On Thu, Sep 22, 2022 at 11:10 AM Anton Bikineev 
>>> wrote:
>>>
 There is "cppgc::internal::CompressedPointer::Decompress(void*)". I
 would, however, hide it behind a simpler name in .gdbinit.

 On Thu, Sep 22, 2022 at 5:51 PM Daniel Cheng 
 wrote:

> Is there a callable C++ function that can turn a compressed pointer
> into the actual pointer value?
>
> Daniel
>
> On Thu, 22 Sept 2022 at 08:43, Anton Bikineev 
> wrote:
>
>> We have plans to provide more debugging tooling for Oilpan. I haven't
>> had a need to examine compressed pointers myself, however I see that some
>> simple gdb/windbg function that'd follow pointers would be useful.
>>
>> On Thu, Sep 22, 2022 at 1:14 AM Kentaro Hara 
>> wrote:
>>
>>> +Michael Lippautz 
>>>
>>> 2022年9月22日(木) 4:01 'Daniel Libby' via blink-dev <
>>> blink-dev@chromium.org>:
>>>
 https://crrev.com/c/3835682 enabled pointer compression for Blink
 Member<> pointers. How are folks handling these while debugging (either
 live or crash dumps)? Is there some tooling available that will look 
 up and
 apply the cage base?

 I didn't see anything mentioned in
 https://docs.google.com/document/d/1neGN8Jq-1JLrWK3cvwRIfrSjLgE0Srjv-uq7Ze38Iao/edit#
 but maybe there are better known tools/techniques from v8 (which IIUC 
 has
 had compressed pointers for some time now).

 --
 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/4b3e5bbb-134a-4483-9a1e-8e33fbc6f38en%40chromium.org
 
 .

>>> --
>>> 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/CABg10jxSdx3JzWvTC2j7RUEcw01P9gTRhT%3DnftwehY3br4qNWA%40mail.gmail.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/CABH6udYH6VGy8Ooz6ZLZWpWR_LjjQfu1xh-AMBvWoyAnArojbA%40mail.gmail.com
>> 
>> .
>>
> --
 You received this message because you a

Re: [blink-dev] Debugging compressed pointers in Blink

[Daniel Cheng]

For now, I guess it should be sufficient to add something
to v8/include/cppgc/internal/member-storage.h like

#ifndef NDEBUG  // DCHECK_IS_ON() would be nicer, but not sure what v8 uses
extern "C" void* DecompressPointerForDebugger(uint32_t value) {
  return cppgc::internal::CompressedPointer::Decompress(value);
}
#endif

Which should hopefully be callable from the debugger and not eliminated by
the linker?

Daniel

On Mon, 10 Oct 2022 at 11:32, Stefan Zager  wrote:

> I ran into this today, and it's pretty frustrating:
>
> (rr) p inner_node_
>
> $11 = {
>
>= {
>
> raw_ = {
>
>   static kCompressedSentinel = 1,
>
>   value_ = 2148082696 <(214)%20808-2696>
>
> }
>
>   },
>
>= {},  fields>}
> (rr) p inner_node_.Load()
>
> Couldn't find method blink::Member::Load
>
> (rr) p inner_node_.raw_.Load()
>
> Cannot evaluate function -- may be inlined
>
> (rr) p
> cppgc::internal::CompressedPointer::Decompress(inner_node_.raw_.value_)
>
> Cannot evaluate function -- may be inlined
>
> (rr)
>
> I found that I can avoid the issue with this in args.gn:
>
> cppgc_enable_caged_heap = false
> cppgc_enable_pointer_compression = false
>
> ... but I would prefer a better solution.
>
> On Mon, Oct 10, 2022 at 10:22 AM Ian Kilpatrick 
> wrote:
>
>> Is there a bug to follow regarding the debuggability of the pointers?
>>
>> Ian
>>
>> On Thu, Sep 22, 2022 at 11:10 AM Anton Bikineev 
>> wrote:
>>
>>> There is "cppgc::internal::CompressedPointer::Decompress(void*)". I
>>> would, however, hide it behind a simpler name in .gdbinit.
>>>
>>> On Thu, Sep 22, 2022 at 5:51 PM Daniel Cheng 
>>> wrote:
>>>
 Is there a callable C++ function that can turn a compressed pointer
 into the actual pointer value?

 Daniel

 On Thu, 22 Sept 2022 at 08:43, Anton Bikineev 
 wrote:

> We have plans to provide more debugging tooling for Oilpan. I haven't
> had a need to examine compressed pointers myself, however I see that some
> simple gdb/windbg function that'd follow pointers would be useful.
>
> On Thu, Sep 22, 2022 at 1:14 AM Kentaro Hara 
> wrote:
>
>> +Michael Lippautz 
>>
>> 2022年9月22日(木) 4:01 'Daniel Libby' via blink-dev <
>> blink-dev@chromium.org>:
>>
>>> https://crrev.com/c/3835682 enabled pointer compression for Blink
>>> Member<> pointers. How are folks handling these while debugging (either
>>> live or crash dumps)? Is there some tooling available that will look up 
>>> and
>>> apply the cage base?
>>>
>>> I didn't see anything mentioned in
>>> https://docs.google.com/document/d/1neGN8Jq-1JLrWK3cvwRIfrSjLgE0Srjv-uq7Ze38Iao/edit#
>>> but maybe there are better known tools/techniques from v8 (which IIUC 
>>> has
>>> had compressed pointers for some time now).
>>>
>>> --
>>> 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/4b3e5bbb-134a-4483-9a1e-8e33fbc6f38en%40chromium.org
>>> 
>>> .
>>>
>> --
>> 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/CABg10jxSdx3JzWvTC2j7RUEcw01P9gTRhT%3DnftwehY3br4qNWA%40mail.gmail.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/CABH6udYH6VGy8Ooz6ZLZWpWR_LjjQfu1xh-AMBvWoyAnArojbA%40mail.gmail.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/

Re: [blink-dev] Intent to Ship: Android OSK resizes visual viewport by default + opt-out

[David Bokan]

Thanks everyone!

I'm still waiting on a confirmation for the last remaining issue on the 
spec PR 
 but I 
hope to have that resolved and the changes enabled in trunk in the next day 
or two.

I'll update this thread when that happens.

On Friday, October 7, 2022 at 5:52:39 AM UTC-4 Mike West wrote:

> LGTM3.
>
> -mike
>
>
> On Fri, Oct 7, 2022 at 4:56 AM Yoav Weiss  wrote:
>
>> LGTM2 under the same conditions!
>>
>> On Fri, Oct 7, 2022 at 2:23 AM Mike Taylor  
>> wrote:
>>
>>> I see that Emilio has approved 
>>> https://github.com/w3c/csswg-drafts/pull/7826, with a few suggestions.
>>>
>>> LGTM1 to ship w/ the review comments addressed and the PR landing (and 
>>> thanks for speccing it!).
>>>
>>> On 9/23/22 10:17 PM, David Bokan wrote:
>>>
>>> Contact emails
>>>
>>> bo...@chromium.org
>>>
>>> Explainer 
>>> https://github.com/bramus/viewport-resize-behavior/blob/main/explainer.md
>>>
>>> Specification
>>> The resize behavior of the virtual keyboard is not specified.
>>> The viewport meta tag is not yet fully specified 
>>> .
>>> See also https://github.com/w3c/csswg-drafts/issues/7767.
>>>
>>> Summary
>>> This intent:
>>>
>>>- Changes the Android virtual keyboard such that it resizes the visual 
>>>viewport only, rather than the current behavior of resizing the initial 
>>>containing block (ICB) and layout viewport (LVP). 
>>>- Ships support for a new meta-viewport key interactive-widgets 
>>>which can be used to opt-out of the above change, and instead retain the 
>>>old behavior.
>>>
>>>Example: >>content=”interactive-widgets=resize-layout”> 
>>>
>>>
>>> *Motivation *Browsers do not currently agree on how the virtual 
>>> keyboard should interact with the viewport:
>>>
>>>- 
>>>
>>>Chrome for Android and Firefox for Android both resize the initial 
>>>containing block and  layout viewport.
>>>- 
>>>
>>>Chrome for ChromeOS and Windows; and Safari/iOS both resize the visual 
>>>viewport only.
>>>
>>> This discrepancy is a source of frustration for authors [1] 
>>> 
>>>  
>>> [2] 
>>> 
>>>  
>>> [3] 
>>> 
>>>  
>>> [4] . 
>>> While both approaches have valid use-cases, we believe that resizing the 
>>> visual viewport is the best default, as it avoids any layout-jank from 
>>> opening the keyboard, and in general interferes with the page as little as 
>>> possible.
>>>
>>> Other vendors also have long-standing issues in this area: 
>>> https://bugzilla.mozilla.org/show_bug.cgi?id=1007286
>>>
>>> This intent improves interop for mobile viewports, a priority investigation 
>>> area for Interop 2022 . Mobile viewports 
>>> (especially the meta tag) are unfortunately not well specified, and we plan 
>>> to work on resolving CSSWG issue 7767 
>>>  in parallel with this 
>>> intent. In the meantime we plan to add this feature to the Compat spec 
>>> .
>>>
>>> Blink component
>>> Blink>Scroll 
>>> 
>>>
>>> TAG review
>>> N/A
>>>
>>> TAG review status
>>> Not applicable
>>>
>>> Risks
>>>
>>> Interoperability and Compatibility
>>>
>>> The main risk with this change is web apps which critically depend on 
>>> the current LVP-resize behavior, e.g. a chat app with a message box fixed 
>>> above the keyboard.
>>>
>>> Those use-cases would no longer be possible with the default behavior, 
>>> and it was exactly this concern that stopped the previous attempt to 
>>> ship this behavior 
>>> 
>>>  
>>> at LGTM2.
>>>
>>> What makes this intent different:
>>>
>>>- 
>>>
>>>The VirtualKeyboard API 
>>> 
>>>now exists, which exposes the geometry of the keyboard as CSS-reachable 
>>>environment variables allowing app full control over keyboard behavior.
>>>- 
>>>
>>>For an easier fix, a new  opt-out has been added which can be 
>>>used to maintain the current LVP-resize behavior. This is a trivial fix 
>>> for 
>>>any affected web app.
>>>
>>> As there is no good way to detect the problematic cases with a 
>>> use-counter / HTTP Archive query, we must instead rely on developer 
>>> outreach to inform this change. That outreach wi

Re: [blink-dev] Debugging compressed pointers in Blink

[Stefan Zager]

I ran into this today, and it's pretty frustrating:

(rr) p inner_node_

$11 = {

   = {

raw_ = {

  static kCompressedSentinel = 1,

  value_ = 2148082696

}

  },

   = {}, }
(rr) p inner_node_.Load()

Couldn't find method blink::Member::Load

(rr) p inner_node_.raw_.Load()

Cannot evaluate function -- may be inlined

(rr) p
cppgc::internal::CompressedPointer::Decompress(inner_node_.raw_.value_)

Cannot evaluate function -- may be inlined

(rr)

I found that I can avoid the issue with this in args.gn:

cppgc_enable_caged_heap = false
cppgc_enable_pointer_compression = false

... but I would prefer a better solution.

On Mon, Oct 10, 2022 at 10:22 AM Ian Kilpatrick 
wrote:

> Is there a bug to follow regarding the debuggability of the pointers?
>
> Ian
>
> On Thu, Sep 22, 2022 at 11:10 AM Anton Bikineev 
> wrote:
>
>> There is "cppgc::internal::CompressedPointer::Decompress(void*)". I
>> would, however, hide it behind a simpler name in .gdbinit.
>>
>> On Thu, Sep 22, 2022 at 5:51 PM Daniel Cheng  wrote:
>>
>>> Is there a callable C++ function that can turn a compressed pointer into
>>> the actual pointer value?
>>>
>>> Daniel
>>>
>>> On Thu, 22 Sept 2022 at 08:43, Anton Bikineev 
>>> wrote:
>>>
 We have plans to provide more debugging tooling for Oilpan. I haven't
 had a need to examine compressed pointers myself, however I see that some
 simple gdb/windbg function that'd follow pointers would be useful.

 On Thu, Sep 22, 2022 at 1:14 AM Kentaro Hara 
 wrote:

> +Michael Lippautz 
>
> 2022年9月22日(木) 4:01 'Daniel Libby' via blink-dev <
> blink-dev@chromium.org>:
>
>> https://crrev.com/c/3835682 enabled pointer compression for Blink
>> Member<> pointers. How are folks handling these while debugging (either
>> live or crash dumps)? Is there some tooling available that will look up 
>> and
>> apply the cage base?
>>
>> I didn't see anything mentioned in
>> https://docs.google.com/document/d/1neGN8Jq-1JLrWK3cvwRIfrSjLgE0Srjv-uq7Ze38Iao/edit#
>> but maybe there are better known tools/techniques from v8 (which IIUC has
>> had compressed pointers for some time now).
>>
>> --
>> 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/4b3e5bbb-134a-4483-9a1e-8e33fbc6f38en%40chromium.org
>> 
>> .
>>
> --
> 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/CABg10jxSdx3JzWvTC2j7RUEcw01P9gTRhT%3DnftwehY3br4qNWA%40mail.gmail.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/CABH6udYH6VGy8Ooz6ZLZWpWR_LjjQfu1xh-AMBvWoyAnArojbA%40mail.gmail.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/CABH6udZS_4iw6Vhb%3Dtf0J9qgV%3DbwbcWAu%2B--Xt9dYrDpqDecXw%40mail.gmail.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/CAJL3UpQ%2BiPOAMX6ONDxRm9UG0zFRkScw1%3DdALFGdKJOUiAUpEw%40mail.g

Re: [blink-dev] Debugging compressed pointers in Blink

[Ian Kilpatrick]

Is there a bug to follow regarding the debuggability of the pointers?

Ian

On Thu, Sep 22, 2022 at 11:10 AM Anton Bikineev 
wrote:

> There is "cppgc::internal::CompressedPointer::Decompress(void*)". I would,
> however, hide it behind a simpler name in .gdbinit.
>
> On Thu, Sep 22, 2022 at 5:51 PM Daniel Cheng  wrote:
>
>> Is there a callable C++ function that can turn a compressed pointer into
>> the actual pointer value?
>>
>> Daniel
>>
>> On Thu, 22 Sept 2022 at 08:43, Anton Bikineev 
>> wrote:
>>
>>> We have plans to provide more debugging tooling for Oilpan. I haven't
>>> had a need to examine compressed pointers myself, however I see that some
>>> simple gdb/windbg function that'd follow pointers would be useful.
>>>
>>> On Thu, Sep 22, 2022 at 1:14 AM Kentaro Hara 
>>> wrote:
>>>
 +Michael Lippautz 

 2022年9月22日(木) 4:01 'Daniel Libby' via blink-dev >>> >:

> https://crrev.com/c/3835682 enabled pointer compression for Blink
> Member<> pointers. How are folks handling these while debugging (either
> live or crash dumps)? Is there some tooling available that will look up 
> and
> apply the cage base?
>
> I didn't see anything mentioned in
> https://docs.google.com/document/d/1neGN8Jq-1JLrWK3cvwRIfrSjLgE0Srjv-uq7Ze38Iao/edit#
> but maybe there are better known tools/techniques from v8 (which IIUC has
> had compressed pointers for some time now).
>
> --
> 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/4b3e5bbb-134a-4483-9a1e-8e33fbc6f38en%40chromium.org
> 
> .
>
 --
 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/CABg10jxSdx3JzWvTC2j7RUEcw01P9gTRhT%3DnftwehY3br4qNWA%40mail.gmail.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/CABH6udYH6VGy8Ooz6ZLZWpWR_LjjQfu1xh-AMBvWoyAnArojbA%40mail.gmail.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/CABH6udZS_4iw6Vhb%3Dtf0J9qgV%3DbwbcWAu%2B--Xt9dYrDpqDecXw%40mail.gmail.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/CAJL3UpQ%2BiPOAMX6ONDxRm9UG0zFRkScw1%3DdALFGdKJOUiAUpEw%40mail.gmail.com.

Re: [blink-dev] Intent to Ship: CSS @supports : Always non-forgiving parsing

[Byungwoo Lee]

To continue this thread after getting the stable Chrome's use counter, I 
changed the estimated milestone of this feature from 109 to 111.
I'll share the use counter after the version 108 released.

Thank you!

2022년 9월 29일 목요일 오전 11시 52분 43초 UTC+9에 Byungwoo Lee님이 작성:

>
> On 9/27/22 10:07, Byungwoo Lee wrote:
>
>
> On 9/24/22 00:40, Yoav Weiss wrote:
>
>
>
> On Fri, Sep 23, 2022 at 5:25 PM Byungwoo Lee  wrote:
>
>> Hello Yoav and Mike,
>>
>> Thanks for the feedback! I replied inline.
>> On 9/23/22 22:18, Yoav Weiss wrote:
>>
>>
>>
>> On Fri, Sep 23, 2022 at 3:15 PM Mike Taylor  wrote:
>>
>>> Hi Byungwoo,
>>>
>>> On 9/23/22 4:34 AM, Byungwoo Lee wrote:
>>>
>>> Contact emails bl...@igalia.com
>>>
>>> Specification 
>>> https://drafts.csswg.org/css-conditional-4/#support-definition-ext
>>>
>>> Summary 
>>>
>>> Some functional selectors are parsed forgivingly. (e.g. :is(), :has()) 
>>> If an argument of the functional selectors is unknown or invalid, the 
>>> argument is dropped but the selector itself is not invalidated. To provide 
>>> a way of detecting the unknown or invalid arguments in those functional 
>>> selectors, this feature applies the CSS Working Group issue resolution: - 
>>> @supports uses non-forgiving parsing for all selectors (
>>> https://github.com/w3c/csswg-drafts/issues/7280#issuecomment-1143852187)
>>>
>>> Am I understanding correctly that content that now uses a functional 
>> selector argument that's invalid may break as a result of this?
>> If so, do we have usecounters to that effect?
>>
>> Yes it can change the previous behavior.
>>
>> This changes the selector parsing behavior only for the selectors inside 
>> @supports selector().
>>
>> So if authors expected true for '@supports 
>> selector(:is(:some-invalid-selector))', this feature will break it because 
>> the return value will be changed to false after this feature is enabled.
>>
>> I'm not sure that we have the usecounters of the case: counting drop of 
>> invalid selector inside @supports selector.
>>
>> If it doesn't exists but it is needed, I think we can add it. Will it be 
>> better to add it to get use counters before ship it?
>>
>
> Yeah, knowing the order of magnitude of potential breakage would be good.  
>
> I landed a CL to add the use counter:
>
> https://chromiumdash.appspot.com/commit/d060459d174c468a78d69d4e2a12925e0e7ab216
>  
>
> It counts the drop of invalid selector while forgiving selector parsing 
> inside @supports selector(). We can see the stats with 
> CSSAtSupportsDropInvalidWhileForgivingParsing(4361):
> https://chromestatus.com/metrics/feature/timeline/popularity/4361
>
> This will be in 108 version so hopefully we can get the use counter after 
> the version is released.
>
>- beta (Oct 27)
>- stable (Nov 29) 
>
> I'll share the stats when it released.
>
> Thanks!
>
>
>>>
>>> Blink component Blink 
>>> 
>>>
>>> TAG review 
>>>
>>> TAG review status Not applicable
>>>
>>> Can you expand on why you think a TAG review is not needed here?
>>>
>> I thought that we don't need TAG review and the reason was
>>
>> - This is already specified in the spec:
>> https://drafts.csswg.org/css-conditional-4/#support-definition-ext 
>> 
>>
>> - Firefox already landed it:
>>   https://bugzilla.mozilla.org/show_bug.cgi?id=1789248
>>
>> Will it be better to change the TAG review status to 'Pending'?
>>
>>
>>> Risks 
>>>
>>>
>>> Interoperability and Compatibility 
>>>
>>> *Gecko*: Shipped/Shipping 
>>> https://bugzilla.mozilla.org/show_bug.cgi?id=1789248
>>>
>>> *WebKit*: Positive
>>>
>>> *Web developers*: Positive
>>>
>>> Can you please link to these signals?
>>>
>>
>> WebKit:
>>
>> - Explained about this in a blog post:
>>   https://webkit.org/blog/13096/css-has-pseudo-class/
>>
>> Web developers:
>>
>> - Thumbs ups in the CSSWG issue:
>>https://github.com/w3c/csswg-drafts/issues/7280
>>
>> - jQuery applied the spec:
>>   https://github.com/jquery/jquery/pull/5107
>>
>>
>> Rego let me know what I missed (Thanks!), so I'm updating this.
>
> This specification change has been implemented in WebKit as well as 
> Firefox:
> https://bugs.webkit.org/show_bug.cgi?id=244808
>
> I updated the 'Safari views' and 'Tag review' in the chromestatus 
> accordingly.
>
>
> *WebKit:* Shipped/Shipping https://bugs.webkit.org/show_bug.cgi?id=244808
>
>
> *Tag review*
> No TAG review
>
>
> - This is already specified in the spec:
> https://drafts.csswg.org/css-conditional-4/#support-definition-ext
>
> - Firefox and WebKit already implemented it:
>   https://bugzilla.mozilla.org/show_bug.cgi?id=1789248
>   https://bugs.webkit.org/show_bug.cgi?id=244808
>
>
> *Tag review status*
> pending
>
>
> Could this update affect the shipping decisions?
>
> thanks,
>>> Mike
>>>
>>>
>>> -- 
>>> You received this message because you are subscribed to the Google 
>>> Groups "blink-dev" group.
>>> T