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/CAL5BFfW-%3D1%3DDpMvX%2B4oj0QRgJQsT6uuwQS_%3DMrE_WD_tF3fRHA%40mail.gmail.com.
