Bug 259188 – "-webkit-box-decoration-break: clone" with left and right padding causes unexpected wrapping of inline content

• Status: RESOLVED
• Resolution: FIXED
• Component: Layout and Rendering

[Pavel Antolík]

Created attachment 467032 [details]
photo demonstrating the issue on a physical device with iOS 16.5.1

When using "-webkit-box-decoration-break: clone" in combination with left and right padding, Safari 16 seems to incorrectly determine the inline element's width resulting in unnecessary / unwanted line breaks (even though there is more than enough space for the element). If I set paddings to 0, everything works as expected.

Problem appears to be somewhat tied to the Safari version on physical devices - tried multiple devices but only those with Safari 16 were affected. Funnily enough, in the Simulator the bug didn't manifest at all.

iPhone XR, OS 16.5.1. - issue present
iPhone 6, OS 12.5.7. - everything okay
iPad mini 2, OS 12.5. - everything okay
iPad 7, OS 16.4.1. - issue present

For a visual demonstration, please see the attached photo. It's clearly visible that even though there is enough space on both sides of the inline element, it still gets wrapped in a very unpleasant way.

P.S.: I noticed some other bugreports regarding "webkit-box-decoration-break: clone" but all of them are supposedly fixed already, while this problem I am reporting still persists.

[zalan]

Thank for filing this bug report! Could you attach either a sample test case or the full url to wordbreak.w2.d.webnodev.com where this bug reproduces, please?

[Pavel Antolík]

Hi Zalan, what a ligtning fast response, respect!

As much as I'd love to include the URL with the initial bug spotting, I cannot as it's behind a VPN and inaccessible from the outside.

HOWEVER, I just managed to replicate the issue in codepen, here is the link: https://codepen.io/29pixels/pen/MWzQjXp (I also updated it in the URL field).

[zalan]

(In reply to Pavel Antolík from comment #2)
> Hi Zalan, what a ligtning fast response, respect!
:)

> 
> As much as I'd love to include the URL with the initial bug spotting, I
> cannot as it's behind a VPN and inaccessible from the outside.
> 
> HOWEVER, I just managed to replicate the issue in codepen, here is the link:
> https://codepen.io/29pixels/pen/MWzQjXp (I also updated it in the URL field).
very cool, thanks! let me take a look.

[Pavel Antolík]

(In reply to zalan from comment #3)
> (In reply to Pavel Antolík from comment #2)
> > Hi Zalan, what a ligtning fast response, respect!
> :)
> 
> > 
> > As much as I'd love to include the URL with the initial bug spotting, I
> > cannot as it's behind a VPN and inaccessible from the outside.
> > 
> > HOWEVER, I just managed to replicate the issue in codepen, here is the link:
> > https://codepen.io/29pixels/pen/MWzQjXp (I also updated it in the URL field).
> very cool, thanks! let me take a look.

Thanks! Hopefully we'll get to the bottom of this - fingers crossed! ^^

Btw, the codepen example felt a bit crude and out of context, so I'm also including also URL for a "full project" I just made in our production environment to further demonstrate the issue with all the bells and whistles.

Here it goes - https://bugdemo.webnode.cz/

[zalan]

Created attachment 467033 [details]
Test reduction

This looks to be a "shrink to fit" bug where the intrinsic width computation does not take the padding (border) value into account when decoration clone is present. (e.g. we measure the content (as part of the preferred width computation) and we think it is going to fit in 100px and later when we run the actual inline layout, we notice the content is 110px wide (extra 10px comes from padding) and we need to wrap some part of it to the subsequent line.)

[Radar WebKit Bug Importer]

<rdar://problem/112197978>

[zalan]

(In reply to Pavel Antolík from comment #4)
> (In reply to zalan from comment #3)
> > (In reply to Pavel Antolík from comment #2)
> > > Hi Zalan, what a ligtning fast response, respect!
> > :)
> > 
> > > 
> > > As much as I'd love to include the URL with the initial bug spotting, I
> > > cannot as it's behind a VPN and inaccessible from the outside.
> > > 
> > > HOWEVER, I just managed to replicate the issue in codepen, here is the link:
> > > https://codepen.io/29pixels/pen/MWzQjXp (I also updated it in the URL field).
> > very cool, thanks! let me take a look.
> 
> Thanks! Hopefully we'll get to the bottom of this - fingers crossed! ^^
> 
> Btw, the codepen example felt a bit crude and out of context, so I'm also
> including also URL for a "full project" I just made in our production
> environment to further demonstrate the issue with all the bells and whistles.
> 
> Here it goes - https://bugdemo.webnode.cz/
Yeah, it does not look optimal. :/ will make sure the fix gets tested against it.

[Pavel Antolík]

(In reply to zalan from comment #5)
> Created attachment 467033 [details]
> Test reduction
> 
> This looks to be a "shrink to fit" bug where the intrinsic width computation
> does not take the padding (border) value into account when decoration clone
> is present. (e.g. we measure the content (as part of the preferred width
> computation) and we think it is going to fit in 100px and later when we run
> the actual inline layout, we notice the content is 110px wide (extra 10px
> comes from padding) and we need to wrap some part of it to the subsequent
> line.)

Thanks for the heads-up - and for looking into it so quickly! I'll sleep way better now, knowing it's been officially confirmed as a browser bug. I hope fixing it won't be too much of a slog.

[zalan]

Created attachment 467035 [details]
[fast-cq]Patch

[zalan]

Created attachment 467036 [details]
Screenshot with patch applied

[Pavel Antolík]

(In reply to zalan from comment #10)
> Created attachment 467036 [details]
> Screenshot with patch applied

Looking spectacular! Tbh, this is my first bugreport I filed here and just WOW. I really didn't expect what happened today :) Big ups to you Alan! Can't wait for this fix to go live.

[Pavel Antolík]

(In reply to zalan from comment #10)
> Created attachment 467036 [details]
> Screenshot with patch applied

Just one thing I awkwardly realized way too late - the desktop-sized screenshot of a fixed state I was praising in my last comment isn't really the most telling given the fact that the bug occurs on mobile devices .)

[zalan]

(In reply to Pavel Antolík from comment #12)
> (In reply to zalan from comment #10)
> > Created attachment 467036 [details]
> > Screenshot with patch applied
> 
> Just one thing I awkwardly realized way too late - the desktop-sized
> screenshot of a fixed state I was praising in my last comment isn't really
> the most telling given the fact that the bug occurs on mobile devices .)
It's shrink-to-fit content so I wouldn't expect anything different there, but good point. will make sure it passes on iOS.

[zalan]

Created attachment 467037 [details]
(iOS screenshot)

[EWS]

Committed 266051@main (e05c6e3339f4): <https://commits.webkit.org/266051@main>

All reviewed patches have been landed. Closing bug and clearing flags on attachment 467035 [details].

[Pavel Antolík]

(In reply to zalan from comment #14)
> Created attachment 467037 [details]
> (iOS screenshot)

Absolutely beautiful, thank you! One last question just out of curiosity if I may - how / when do Safari users recieve this patch? Is it in form of an automatic update, or something different?

[zalan]

(In reply to Pavel Antolík from comment #16)
> (In reply to zalan from comment #14)
> > Created attachment 467037 [details]
> > (iOS screenshot)
> 
> Absolutely beautiful, thank you! One last question just out of curiosity if
> I may - how / when do Safari users recieve this patch? Is it in form of an
> automatic update, or something different?
Unfortunately I can't comment on future releases (and even if I could, I am not sure if I actually know the correct answer to your question)