Heads up, shipping this feature has been moved to M108 (targeted for a
stable release on Nov 29). The plan is still to have a finch based rollout:
1% -> 10% -> 25% -> 50% -> 100% with a week before each progression.
On Tue, Oct 4, 2022 at 8:57 AM Yoav Weiss <yoavwe...@chromium.org> wrote:
> Thanks for the details, Nic! :)
>
> Should we be worried about the numbers of deprecation reports you're
> seeing for this specific intent?
>
> On Mon, Oct 3, 2022 at 8:37 PM Nic Jansma <nicjan...@gmail.com> wrote:
>
>> Thank for updating the message!
>>
>> Yoav - For our RUM product, we have a limited set of customers that have
>> enabled various Reporting-API-based reports, including these deprecation
>> messages.
>>
>> We aggregate these reports and present them a summary based on the
>> id/anticipatedRemoval/message. Customers can look at their top
>> deprecations or recent new ones. For the above reports, the only
>> interesting fields were the numeric IDs (4302/4201), so the reports we were
>> presenting were a bit confusing (basically, just a the number "4302" as the
>> deprecation message).
>>
>> Other deprecations have come in with a better string-based id, like
>> ChromeLoadTimesConnectionInfo or WebFeature::kEventPath. Searching on
>> those strings leads to quick answers on Google, which I expect many of our
>> customers/developers to do to triage the reports.
>>
>> To be honest, I think one of the most useful things that could be
>> included in the report is a URL "landing page" for that deprecation, that
>> would describe the issue and how the developer may fix it. Tools like ours
>> would then just direct link to that URL.
>>
>> On Wednesday, September 28, 2022 at 4:03:12 PM UTC-4
>> khusha...@chromium.org wrote:
>>
>>> On Tue, Sep 27, 2022 at 12:40 PM Yoav Weiss <yoav...@chromium.org>
>>> wrote:
>>>
>>>> Thanks so much for reporting this, Nic! :) (pun not intended)
>>>>
>>>> A few generic questions:
>>>>
>>>> - Do you have outreach channels to your customers where those
>>>> deprecations are being reported? Are they presented as e.g. warnings in
>>>> their dashboards?
>>>> - What information would you find useful in the reports that would
>>>> make it easier to communicate the issue and potential solutions to your
>>>> customers?
>>>>
>>>> And finally, a more specific question: can you share numbers regarding
>>>> the rough number of customer origins that are hitting this? Even an order
>>>> of magnitude would be helpful.
>>>>
>>>> Cheers,
>>>> Yoav
>>>>
>>>> On Tue, Sep 27, 2022 at 5:55 PM Nic Jansma <nicj...@gmail.com> wrote:
>>>>
>>>>> Hi everyone!
>>>>>
>>>>> I've started seeing this deprecation being reported via Reporting API
>>>>> (through a ReportingObserver and Reporting API pings) on a few sites that
>>>>> are being measured for RUM.
>>>>>
>>>>> The actual deprecation report was very hard to decode, as all that was
>>>>> included was the ID (4201) and a confusing message (which looks like an
>>>>> internal error message). e.g.:
>>>>>
>>>>> {
>>>>> "body": {
>>>>> "anticipatedRemoval": null,
>>>>> "columnNumber": 12345,
>>>>> "id": "4201",
>>>>> "lineNumber": 1,
>>>>> "message": "Deprecation messages are stored in the
>>>>> devtools-frontend repo at
>>>>> front_end/models/issues_manager/DeprecationIssue.ts",
>>>>> "sourceFile": null
>>>>> },
>>>>> "type": "deprecation",
>>>>> "url": "https://example.com";
>>>>> }
>>>>>
>>>>> It took some help from Yoav to understand 4201 is this specific issue
>>>>> (I think). With the details here, I can begin to understand (as a
>>>>> developer) how to address the reports.
>>>>>
>>>>> I filed a Chromium bug to ask for more details in the deprecation
>>>>> report:
>>>>>
>>>>> https://bugs.chromium.org/p/chromium/issues/detail?id=1368607
>>>>>
>>>>
>>> Apologies for missing the message here. I have a change
>>> <https://chromium-review.googlesource.com/c/devtools/devtools-frontend/+/3923677>
>>> up to add a debug message which points here
>>> <https://github.com/WICG/shared-element-transitions/blob/main/overflow-on-replaced-elements.md>
>>> for
>>> guidance on how to fix the deprecation. Please let me know if any other
>>> information would be helpful.
>>>
>>>
>>>>
>>>>>
>>>>> On Monday, September 12, 2022 at 8:26:29 PM UTC-4 andr...@google.com
>>>>> wrote:
>>>>>
>>>>>> CC @Cheney Tsai, @Una Kravets, @Kadir Topal
>>>>>>
>>>>>> From a DevRel perspective, the three questions in my mind are:
>>>>>>
>>>>>> - Are affected developers aware of the change?
>>>>>> - I understand they were notified via a console warning /
>>>>>> deprecation warning. It'd be great to get a sense of how effective
>>>>>> the
>>>>>> communication was (ie: has usage significantly decreased since the
>>>>>> warnings?).
>>>>>>
>>>>>>
>>>>>> - Have we given them enough time for developers to react to the
>>>>>> change?
>>>>>> - This is less about how complex a change is and more about
>>>>>> ensuring developers can fit the change into their planning cycle
>>>>>> (eg:
>>>>>> quarterly OKRs) and avoiding generating unplanned/urgent work, if
>>>>>> possible.
>>>>>> It does seem to me the timelines described are short.
>>>>>>
>>>>>>
>>>>>> - Are developers somehow blocked in implementing the change?
>>>>>> - The change seems quite straightforward, but sometimes
>>>>>> developers are blocked in surprising ways. Is there a channel
>>>>>> developers
>>>>>> can provide feedback on?
>>>>>>
>>>>>>
>>>>>>
>>>>>> Andre
>>>>>>
>>>>>> On Mon, 12 Sept 2022 at 01:54, Mike Taylor <mike...@chromium.org>
>>>>>> wrote:
>>>>>>
>>>>>>> LGTM2
>>>>>>>
>>>>>>> On 9/9/22 12:16 PM, Khushal Sagar wrote:
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>> On Fri, Sep 9, 2022 at 11:37 AM Yoav Weiss <yoav...@chromium.org>
>>>>>>> wrote:
>>>>>>>
>>>>>>>> Thanks for meticulously gathering that data!!
>>>>>>>>
>>>>>>>> Just to give a rough idea - 5K pixels would be 50x100 pixels, which
>>>>>>>> is noticeable breakage but not necessarily an insurmountable one.
>>>>>>>> The numbers are a bit higher than I'd like, but at the same time,
>>>>>>>> this enables new capabilities and we're not walking this path alone
>>>>>>>> <https://github.com/mozilla/standards-positions/issues/659#issuecomment-1182596173>
>>>>>>>> .
>>>>>>>>
>>>>>>>> Given the above, *LGTM1* for a careful and monitored rollout,
>>>>>>>> accompanied with DevRel folks supporting y'all in communicating this
>>>>>>>> change
>>>>>>>> to developers.
>>>>>>>> What are the timelines you have in mind? Is there some way to use
>>>>>>>> Deprecation Reporting to help us here?
>>>>>>>>
>>>>>>>
>>>>>>> I would target a gradual roll out: 1% -> 10% -> 25% -> 50% -> 100%
>>>>>>> with a week before each progression in M107. The release will go to
>>>>>>> stable
>>>>>>> ~October 25th (schedule <https://chromiumdash.appspot.com/schedule>
>>>>>>> ).
>>>>>>>
>>>>>>> In terms of outreach a console warning
>>>>>>> <https://chromiumdash.appspot.com/commit/97b80f4e3b9b742a8c44fa5cb96b6c753b29f3d2>
>>>>>>> and a deprecation warning
>>>>>>> <https://chromiumdash.appspot.com/commit/0d0d8e0a1862e689690a702a5c5295531d9a3a27>
>>>>>>> was
>>>>>>> added in M105 for cases where the element's computed style can cause
>>>>>>> this
>>>>>>> behaviour change. I've also reached out to the dev rel folks for a
>>>>>>> targeted
>>>>>>> email to affected sites that came up through our CT analysis.
>>>>>>>
>>>>>>>
>>>>>>>>
>>>>>>>> On Fri, Sep 9, 2022 at 5:27 PM Khushal Sagar <
>>>>>>>> khusha...@chromium.org> wrote:
>>>>>>>>
>>>>>>>>> We have UseCounter data from M105 stable to quantify the large
>>>>>>>>> breakage for this feature. Large is a page load where any image,
>>>>>>>>> video or
>>>>>>>>> canvas drawn on the page paints over 5k CSS pixels outside its
>>>>>>>>> content-box.
>>>>>>>>> The precise numbers (with page load count) are here
>>>>>>>>> <https://docs.google.com/document/d/1GC2wanCPtoboSujQVr5xoCDlpzzhspr0PHA-OBgGbEY/edit>
>>>>>>>>> (sorry
>>>>>>>>> can't share the details externally).
>>>>>>>>>
>>>>>>>>> In terms of percentage, Windows/Mac had ~0.006% page loads fall in
>>>>>>>>> the large breakage category and Android had ~0.007%.
>>>>>>>>>
>>>>>>>>> On Tue, Aug 2, 2022 at 3:14 PM Khushal Sagar <
>>>>>>>>> khusha...@chromium.org> wrote:
>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>> On Mon, Aug 1, 2022 at 12:11 PM Yoav Weiss <yoav...@chromium.org>
>>>>>>>>>> wrote:
>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>> On Mon, Jul 25, 2022 at 7:44 PM Khushal Sagar <
>>>>>>>>>>> khusha...@chromium.org> wrote:
>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>> On Wed, Jul 20, 2022 at 5:17 AM Yoav Weiss <
>>>>>>>>>>>> yoav...@chromium.org> wrote:
>>>>>>>>>>>>
>>>>>>>>>>>>> Thanks Khushal! :)
>>>>>>>>>>>>>
>>>>>>>>>>>>> The breakage seems potentially significant (at worst, makes
>>>>>>>>>>>>> the site visually broken and unusable), and the percentage of
>>>>>>>>>>>>> breakage
>>>>>>>>>>>>> seems above the threshold we typically consider safe.
>>>>>>>>>>>>> At the same time this seems like a positive change, and our
>>>>>>>>>>>>> friends at Mozilla consider it "worth prototyping".
>>>>>>>>>>>>>
>>>>>>>>>>>>> Would it be possible to consider this as a deprecation of the
>>>>>>>>>>>>> old behavior, and run the console issue (+deprecation warnings
>>>>>>>>>>>>> and outreach
>>>>>>>>>>>>> to affected sites) for a few milestones, to try and drive the
>>>>>>>>>>>>> usage down
>>>>>>>>>>>>> before flipping this change to be on by default? Maybe also get
>>>>>>>>>>>>> some
>>>>>>>>>>>>> documentation out there and work with devrel folks to make sure
>>>>>>>>>>>>> folks are
>>>>>>>>>>>>> aware of this coming change?
>>>>>>>>>>>>>
>>>>>>>>>>>>> Does that sound reasonable?
>>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>> Thanks for the suggestion Yoav. This sounds reasonable. I've
>>>>>>>>>>>> reached out to the devrel folks to do more outreach about this
>>>>>>>>>>>> change. I'll
>>>>>>>>>>>> update this thread with the plan for it. The console issue and
>>>>>>>>>>>> deprecation
>>>>>>>>>>>> warnings have been added in M105.
>>>>>>>>>>>>
>>>>>>>>>>>> I looked into adding a use counter for sites which have real
>>>>>>>>>>>> breakage, since the current metric tracks whether the computed
>>>>>>>>>>>> style
>>>>>>>>>>>> *could* permit allow but not whether there is actual overflow at
>>>>>>>>>>>> paint
>>>>>>>>>>>> time. And unfortunately computing potential overflow is not easy
>>>>>>>>>>>> to add.
>>>>>>>>>>>> The CT analysis I ran earlier did this by turning the feature on
>>>>>>>>>>>> and
>>>>>>>>>>>> tracking actual overflow generated by the element. So a couple of
>>>>>>>>>>>> questions
>>>>>>>>>>>> for moving forward:
>>>>>>>>>>>>
>>>>>>>>>>>> - Would it be okay to turn the feature on in beta and 1% stable
>>>>>>>>>>>> (in M105) to collect metrics for the sites with real breakage and
>>>>>>>>>>>> the
>>>>>>>>>>>> extent of this breakage (how many pixels of overflow do we see).
>>>>>>>>>>>> This
>>>>>>>>>>>> should be lower than the counter of 0.017%.
>>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>> That sounds like a great way to gather data! (assuming the
>>>>>>>>>>> relevant Chrome processes are followed)
>>>>>>>>>>> Would be good to gather a histogram of overflowed pixels, to get
>>>>>>>>>>> a sense of "small breakage" vs. "large breakage".
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>> - What's the number (in terms of page loads affected) we should
>>>>>>>>>>>> be targeting before this would be safe?
>>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>> From my perspective, I'd be comfortable shipping this if we're
>>>>>>>>>>> seeing less than 0.003% of page loads in the "large breakage"
>>>>>>>>>>> bucket (say
>>>>>>>>>>> more than ~5000 overflowing pixels, assuming that number makes
>>>>>>>>>>> sense).
>>>>>>>>>>>
>>>>>>>>>>> +Andre Bandarra - for devrel opinions on this.
>>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>> Currently we're recording a UseCounter when any breakage would
>>>>>>>>>> happen, i.e, there is any pixel overflow. If it helps to have a
>>>>>>>>>> UseCounter
>>>>>>>>>> for overflow above a threshold, I'm happy to add that too.
>>>>>>>>>>
>>>>>>>>>> We do have an UMA metric which measures the number of overflowing
>>>>>>>>>> pixels when there is overflow but it's for all images rendered. I
>>>>>>>>>> can tie
>>>>>>>>>> it to the UseCounter so we can also know the number of affected page
>>>>>>>>>> loads
>>>>>>>>>> with large breakage. I'll wait till the end of the week for more
>>>>>>>>>> feedback,
>>>>>>>>>> otherwise assume 5k is a good threshold for large breakage.
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>>>
>>>>>>>>>>>>> Cheers,
>>>>>>>>>>>>> Yoav
>>>>>>>>>>>>>
>>>>>>>>>>>>> On Thursday, July 14, 2022 at 5:03:54 PM UTC+2 Khushal Sagar
>>>>>>>>>>>>> wrote:
>>>>>>>>>>>>>
>>>>>>>>>>>>>> Hey folks,
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> I'm summarizing the steps to mitigate the compat risk with
>>>>>>>>>>>>>> this feature based on the feedback:
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> - Add a warning to the console when a developer style
>>>>>>>>>>>>>> would permit replaced elements to overflow. The patch to add
>>>>>>>>>>>>>> that is
>>>>>>>>>>>>>> here
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> <https://chromium-review.googlesource.com/c/chromium/src/+/3763640>
>>>>>>>>>>>>>> and
>>>>>>>>>>>>>> documentation to help developers debug, which is referenced
>>>>>>>>>>>>>> in the console
>>>>>>>>>>>>>> warning, is here
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> <https://github.com/WICG/shared-element-transitions/pull/166/files>.
>>>>>>>>>>>>>> We can pre-emptively add this warning to M105 and ship the
>>>>>>>>>>>>>> feature in M106
>>>>>>>>>>>>>> to have a one release window before the behaviour changes.
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> - Send an email to the webmaster of sites surfaced in the
>>>>>>>>>>>>>> CT analysis which already have the styles that trigger the
>>>>>>>>>>>>>> warning above.
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> In addition to the above, the feature can be turned off with
>>>>>>>>>>>>>> a server-side config using finch if there is any severe breakage.
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> Please let me know if the above suffices.
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> Thanks.
>>>>>>>>>>>>>> Khushal
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> On Wed, Jul 13, 2022 at 4:11 PM Khushal Sagar <
>>>>>>>>>>>>>> khusha...@chromium.org> wrote:
>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> On Wed, Jul 13, 2022 at 3:44 PM Mike Taylor <
>>>>>>>>>>>>>>> mike...@chromium.org> wrote:
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>> On 7/13/22 3:04 PM, Khushal Sagar wrote:
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>> On Wed, Jul 13, 2022 at 6:12 AM Yoav Weiss <
>>>>>>>>>>>>>>>> yoav...@chromium.org> wrote:
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>> On Wednesday, July 13, 2022 at 3:54:28 AM UTC+2 Khushal
>>>>>>>>>>>>>>>>> Sagar wrote:
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>> On Mon, Jul 11, 2022 at 11:40 AM Yoav Weiss <
>>>>>>>>>>>>>>>>>> yoav...@chromium.org> wrote:
>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>> On Fri, Jul 8, 2022 at 7:22 PM Khushal Sagar <
>>>>>>>>>>>>>>>>>>> khusha...@chromium.org> wrote:
>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>> Contact emails khusha...@chromium.org,
>>>>>>>>>>>>>>>>>>>> vmp...@chromium.org
>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>> Explainer
>>>>>>>>>>>>>>>>>>>> https://github.com/WICG/shared-element-transitions/blob/main/overflow-on-replaced-elements.md
>>>>>>>>>>>>>>>>>>>> https://github.com/w3c/csswg-drafts/issues/7058
>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>> Specification
>>>>>>>>>>>>>>>>>>>> https://drafts.csswg.org/css-overflow/#overflow-properties
>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>> Summary
>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>> This change allows developers to use the existing
>>>>>>>>>>>>>>>>>>>> `overflow` property with replaced elements that paint
>>>>>>>>>>>>>>>>>>>> outside the
>>>>>>>>>>>>>>>>>>>> content-box. Paired with `object-view-box` this can be
>>>>>>>>>>>>>>>>>>>> used to create an
>>>>>>>>>>>>>>>>>>>> image with a custom glow or shadow applied, with proper
>>>>>>>>>>>>>>>>>>>> ink-overflow
>>>>>>>>>>>>>>>>>>>> behavior like a CSS shadow would have.
>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>> Blink component Blink>CSS
>>>>>>>>>>>>>>>>>>>> <https://bugs.chromium.org/p/chromium/issues/list?q=component:Blink%3ECSS>
>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>> TAG review
>>>>>>>>>>>>>>>>>>>> https://github.com/w3ctag/design-reviews/issues/750
>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>> TAG review status Pending
>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>> Risks
>>>>>>>>>>>>>>>>>>>> Interoperability and Compatibility
>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>> This feature changes the behaviour of the existing
>>>>>>>>>>>>>>>>>>>> overflow property on replaced elements (img, video,
>>>>>>>>>>>>>>>>>>>> canvas). Currently
>>>>>>>>>>>>>>>>>>>> `overflow:visible` in a developer stylesheet on such
>>>>>>>>>>>>>>>>>>>> elements is ignored
>>>>>>>>>>>>>>>>>>>> during paint and the content is clipped to the element's
>>>>>>>>>>>>>>>>>>>> content-box. With
>>>>>>>>>>>>>>>>>>>> this feature, `overflow:visible` will result in content
>>>>>>>>>>>>>>>>>>>> outside the
>>>>>>>>>>>>>>>>>>>> element's content-box to paint as ink overflow. We've
>>>>>>>>>>>>>>>>>>>> collected use counter
>>>>>>>>>>>>>>>>>>>> data to measure the number of sites which could be
>>>>>>>>>>>>>>>>>>>> affected by this. The
>>>>>>>>>>>>>>>>>>>> use counter data collected over 1 week of a stable release
>>>>>>>>>>>>>>>>>>>> (M102) is as
>>>>>>>>>>>>>>>>>>>> follows. We collected 2 different counters explained
>>>>>>>>>>>>>>>>>>>> below. * The first
>>>>>>>>>>>>>>>>>>>> measures any instance where overflow is explicitly set
>>>>>>>>>>>>>>>>>>>> from developer
>>>>>>>>>>>>>>>>>>>> styles to visible. The percentage of page loads with this
>>>>>>>>>>>>>>>>>>>> is 2.16%. * The
>>>>>>>>>>>>>>>>>>>> second measures the above instances but only includes the
>>>>>>>>>>>>>>>>>>>> cases with
>>>>>>>>>>>>>>>>>>>> object-fit set to cover or none or object-position set to
>>>>>>>>>>>>>>>>>>>> any value other
>>>>>>>>>>>>>>>>>>>> than the default (50% 50%). The rationale behind this
>>>>>>>>>>>>>>>>>>>> counter is to exclude
>>>>>>>>>>>>>>>>>>>> cases which can not cause overflow (such as
>>>>>>>>>>>>>>>>>>>> object-fit:contain), even if
>>>>>>>>>>>>>>>>>>>> overflow is set to visible. The percentage of page loads
>>>>>>>>>>>>>>>>>>>> with this is
>>>>>>>>>>>>>>>>>>>> 0.017%.
>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>> That's not nothing. Any idea what breakage may look like?
>>>>>>>>>>>>>>>>>>> Can we maybe collect histograms on *how much* overflow
>>>>>>>>>>>>>>>>>>> would occur in those cases? (maybe with ClusterTelemetry
>>>>>>>>>>>>>>>>>>> initially, to get
>>>>>>>>>>>>>>>>>>> a rough idea in the lab)
>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>> I ran an analysis on CT using top 100k sites for desktop
>>>>>>>>>>>>>>>>>> and top 10k sites on mobile. The raw numbers are here:
>>>>>>>>>>>>>>>>>> desktop
>>>>>>>>>>>>>>>>>> <https://docs.google.com/spreadsheets/d/1kKWq8kqZOfCXqiHaiamYNDdTs5x1_YJfDTnAgXOIwaE/edit#gid=0>
>>>>>>>>>>>>>>>>>> and mobile
>>>>>>>>>>>>>>>>>> <https://docs.google.com/spreadsheets/d/1SrNyrEe4yzCOIxqNOlNgCk8O58NqqoBlBTd4Wn_gKCc/edit#gid=0>,
>>>>>>>>>>>>>>>>>> and the rough patch
>>>>>>>>>>>>>>>>>> <https://chromium-review.googlesource.com/c/chromium/src/+/3749485>
>>>>>>>>>>>>>>>>>> to
>>>>>>>>>>>>>>>>>> collect this data. The highlights from the analysis are
>>>>>>>>>>>>>>>>>> below:
>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>> - The number of sites which override the default CSS
>>>>>>>>>>>>>>>>>> to allow overflow *and* also had overflow during painting
>>>>>>>>>>>>>>>>>> was 13 out of 10k
>>>>>>>>>>>>>>>>>> on mobile and 39 out of 63k on desktop (only 63k sites
>>>>>>>>>>>>>>>>>> yielded results out
>>>>>>>>>>>>>>>>>> of 100k).
>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>> - I measured the percentage of area painted outside
>>>>>>>>>>>>>>>>>> the content box out of the total painted area. The
>>>>>>>>>>>>>>>>>> highest was 88% on
>>>>>>>>>>>>>>>>>> desktop and 70% on mobile.
>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>> I'm not sure what that means in practice. Can you
>>>>>>>>>>>>>>>>> elaborate? Have you looked at extreme cases to see the impact
>>>>>>>>>>>>>>>>> there?
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>> Sorry, I should've added more details. :) I was looking for
>>>>>>>>>>>>>>>> breakages with 2 numbers: sites with the largest number of
>>>>>>>>>>>>>>>> overflowing
>>>>>>>>>>>>>>>> pixels (such that other content could be occluded); sites with
>>>>>>>>>>>>>>>> the largest
>>>>>>>>>>>>>>>> percentage of image content outside the content box. But I
>>>>>>>>>>>>>>>> realize the
>>>>>>>>>>>>>>>> former is probably better to identify breakages.
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>> Looking at the top 10 sites, the worst affected is
>>>>>>>>>>>>>>>> liveops.com. This has cases which use object-fit:cover so
>>>>>>>>>>>>>>>> the image scales to a size bigger than its content rect and
>>>>>>>>>>>>>>>> developer CSS
>>>>>>>>>>>>>>>> overrides overflow to visible. Unfortunately, interacting more
>>>>>>>>>>>>>>>> with this
>>>>>>>>>>>>>>>> site, I did see images which are drawing above other content
>>>>>>>>>>>>>>>> (screenshot
>>>>>>>>>>>>>>>> attached) as you scroll down. This pattern showed up on the
>>>>>>>>>>>>>>>> rest of the
>>>>>>>>>>>>>>>> sites with high overflow numbers too (another example with
>>>>>>>>>>>>>>>> screenshot
>>>>>>>>>>>>>>>> attached).
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>> This kind of breakage is expected with this change. I'm not
>>>>>>>>>>>>>>>> sure where to put the cutoff to identify sites with
>>>>>>>>>>>>>>>> significant breakage,
>>>>>>>>>>>>>>>> but there are at least 30 sites (out of 63k) that have images
>>>>>>>>>>>>>>>> with more
>>>>>>>>>>>>>>>> than 100px of overflow. The fix for the developer is to trace
>>>>>>>>>>>>>>>> down the
>>>>>>>>>>>>>>>> source of the overflow override and remove it.
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>> I'm not sure what's the recommended way to progress with a
>>>>>>>>>>>>>>>> behaviour change like this given these numbers, the instances
>>>>>>>>>>>>>>>> of affected
>>>>>>>>>>>>>>>> sites seems low. Since the fix is simple, but hard to
>>>>>>>>>>>>>>>> diagnose, one option
>>>>>>>>>>>>>>>> could be to add a warning to the console: "overflow:visible
>>>>>>>>>>>>>>>> now causes
>>>>>>>>>>>>>>>> images to draw outside their bounds. Please make sure this
>>>>>>>>>>>>>>>> style is
>>>>>>>>>>>>>>>> intentional" for a few releases (credits to @Vladimir Levin for
>>>>>>>>>>>>>>>> the idea). Would that suffice?
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>> This feels like a fairly challenging bug to diagnose out
>>>>>>>>>>>>>>>> without a DevTools issue
>>>>>>>>>>>>>>>> <https://developer.chrome.com/docs/devtools/issues/> (or
>>>>>>>>>>>>>>>> similar console message that links to some useful docs, as you
>>>>>>>>>>>>>>>> proposed).
>>>>>>>>>>>>>>>> Would we have the ability to conditionally create these for
>>>>>>>>>>>>>>>> some overflow
>>>>>>>>>>>>>>>> threshold value?
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> Sure, we can do this conditionally based on the area of
>>>>>>>>>>>>>>> overflow. I'd be inclined to always do it if the UA style is
>>>>>>>>>>>>>>> overridden to
>>>>>>>>>>>>>>> allow overflow for at least a few releases. Since it's likely
>>>>>>>>>>>>>>> that existing
>>>>>>>>>>>>>>> sites are not overriding this style intentionally (because
>>>>>>>>>>>>>>> currently it's a
>>>>>>>>>>>>>>> no-op). Just to catch cases which don't show up in local
>>>>>>>>>>>>>>> testing because
>>>>>>>>>>>>>>> scaling of the image (with properties like object-fit) can
>>>>>>>>>>>>>>> depend on the
>>>>>>>>>>>>>>> form factor of the device.
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>> I manually went through ~10 sites on both desktop and
>>>>>>>>>>>>>>>>>> mobile. For the ones which repro-ed, the breakage was losing
>>>>>>>>>>>>>>>>>> rounded
>>>>>>>>>>>>>>>>>> corners because border-radius doesn't clip the content if
>>>>>>>>>>>>>>>>>> 'overflow' is
>>>>>>>>>>>>>>>>>> 'visible'. In fact a few sites had the same code, likely
>>>>>>>>>>>>>>>>>> coming from
>>>>>>>>>>>>>>>>>> customerly <https://www.customerly.io/> based on class
>>>>>>>>>>>>>>>>>> names and the UX. There was one case where an image (used in
>>>>>>>>>>>>>>>>>> the
>>>>>>>>>>>>>>>>>> background) had object-fit:cover and overflowed outside the
>>>>>>>>>>>>>>>>>> content box
>>>>>>>>>>>>>>>>>> now. I've attached screenshots for both of these.
>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>> Overall I didn't see any case where the overflow occluded
>>>>>>>>>>>>>>>>>> any other content on the page.
>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>> That's reassuring! :)
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>> *Gecko*: No signal (
>>>>>>>>>>>>>>>>>>>> https://github.com/mozilla/standards-positions/issues/659
>>>>>>>>>>>>>>>>>>>> )
>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>> *WebKit*: No signal (
>>>>>>>>>>>>>>>>>>>> https://lists.webkit.org/pipermail/webkit-dev/2022-June/032317.html
>>>>>>>>>>>>>>>>>>>> )
>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>> *Web developers*: No signals
>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>> *Other signals*:
>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>> 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
>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>> This is a CSS property which can be debugged in the
>>>>>>>>>>>>>>>>>>>> devtools style panel similar to other CSS properties.
>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>> 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
>>>>>>>>>>>>>>>>>>>> <https://chromium.googlesource.com/chromium/src/+/main/docs/testing/web_platform_tests.md>
>>>>>>>>>>>>>>>>>>>> ? Yes
>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>> Flag name CSSOverflowForReplacedElements
>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>> *Note: Because of the compat risk with this feature,
>>>>>>>>>>>>>>>>>>>> this flag can be controlled via Finch. This will allow us
>>>>>>>>>>>>>>>>>>>> to rollback with
>>>>>>>>>>>>>>>>>>>> a server-side config change if needed.*
>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>> Requires code in //chrome? False
>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>> Tracking bug
>>>>>>>>>>>>>>>>>>>> https://bugs.chromium.org/p/chromium/issues/detail?id=1321217
>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>> Estimated milestones
>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>> M105
>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>> Anticipated spec changes
>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>> N/A
>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>> Link to entry on the Chrome Platform Status
>>>>>>>>>>>>>>>>>>>> https://chromestatus.com/feature/5137515594383360
>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>> Links to previous Intent discussions Intent to
>>>>>>>>>>>>>>>>>>>> prototype:
>>>>>>>>>>>>>>>>>>>> https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CAMLuWUykJWEAqVzcUy15fpBNdA68508Mny_1z--FCBKXRTZOFQ%40mail.gmail.com
>>>>>>>>>>>>>>>>>>>> <https://groups.google.com/a/chromium.org/d/msgid/blink-dev/camluwuykjweaqvzcuy15fpbnda68508mny_1z--fcbkxrtz...@mail.gmail.com>
>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>> This intent message was generated by Chrome Platform
>>>>>>>>>>>>>>>>>>>> Status <https://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+...@chromium.org.
>>>>>>>>>>>>>>>>>>>> To view this discussion on the web visit
>>>>>>>>>>>>>>>>>>>> https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CAMLuWUze8JV6twLfhPBwkXj_UBMGApU048OdY33hYQn_KDj2rA%40mail.gmail.com
>>>>>>>>>>>>>>>>>>>> <https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CAMLuWUze8JV6twLfhPBwkXj_UBMGApU048OdY33hYQn_KDj2rA%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+...@chromium.org.
>>>>>>>>>>>>>>>> To view this discussion on the web visit
>>>>>>>>>>>>>>>> https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CAMLuWUz9cutp%2BinEc3%2B7sdv%2B2TPoBbEeFCZjZFExBHSOL1p47A%40mail.gmail.com
>>>>>>>>>>>>>>>> <https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CAMLuWUz9cutp%2BinEc3%2B7sdv%2B2TPoBbEeFCZjZFExBHSOL1p47A%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+...@chromium.org.
>>>>>>>>>>>> To view this discussion on the web visit
>>>>>>>>>>>> https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CAMLuWUy5zyHePkt06pjbtAE_vu1VjbybK5VXURhuSETyR%2Bu54g%40mail.gmail.com
>>>>>>>>>>>> <https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CAMLuWUy5zyHePkt06pjbtAE_vu1VjbybK5VXURhuSETyR%2Bu54g%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/CAMLuWUxVzP0a%3D9dBFSGC6kZBfXbA9MCL3L9KpLiGq2khduc64g%40mail.gmail.com.
