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/e0d74fa2-f363-410d-83c0-5afa49a89362n%40chromium.org.
