Bug 225354 – iOS 14.5 Regression CSS Variable updates are not rendered in Shadow DOM

• Status: RESOLVED
• Resolution: DUPLICATE
• Component: CSS

[Liam DeBeasi]

Created attachment 427663 [details]
Code Reproduction

When changing the value of a CSS Variable on a Web Component using Shadow DOM, WebKit does not always render this updated variable value.

Steps to reproduce:

1. Open attached code reproduction on Safari 14.1 (macOS or iOS 14.5 works).
2. On the left you should see a Web Component that says "My Button". On the right you should see a button that says "Toggle Disabled".
3. Tap the "Toggle Disabled" button. This will set the `disabled` attribute on the Web Component. Observe that the background color of the Web Component changes to gray, but the text color remains the same.

Repeat these steps on iOS 14.4 and you should notice that the text color becomes red when tapping the "Toggle Disabled" button.

Expected Behavior:

I would expect that the Web Component text color becomes red.

Actual Behavior:

The Web Component text color remains dark gray.

Other Information:

- iOS 14.4 and older are working as expected.
- This issue does not reproduce on Chrome 90 or Firefox 88.
- Removing "pointer-events" from the host styles causes the rendering to work as expected.
- When evaluating the value of `--color` in Safari Dev Tools on the `button` element inside of the shadow root, the value is correctly evaluated to "red", but the text color remains rendered as dark gray.

[Radar WebKit Bug Importer]

<rdar://problem/77511775>

[Antti Koivisto]

Hmm, works with trunk.

[Tobias Trumm]

I am also seeing this issue (color in button not updated correctly) without using shadow DOM. Here is an example: https://codepen.io/wistudent/pen/xxqKdMQ

I can see in the inspector that the color property of the element is changed, but the color change is not rendered. I am having this issue on iOS 14.5.1 and macOS Safari 14.1 (16611.1.21.161.3)

[Antti Koivisto]

This was fixed in https://commits.webkit.org/r275607

*** This bug has been marked as a duplicate of bug 224261 ***

[Antti Koivisto]

Right, Shadow DOM and variables are incidental here. The issue is with paint invalidation in presence of pointer-events property.

[Ryosuke Niwa]

Could you comment as to what kind of popular sites or frameworks are affected by this bug?

[Liam DeBeasi]

Currently this impacts our button component in Ionic Framework: https://github.com/ionic-team/ionic-framework/issues/23256.

I have not received reports of this impacting production Ionic Framework apps, though I imagine I will receive more reports as people upgrade to iOS 14.5.

[Ryosuke Niwa]

(In reply to Liam DeBeasi from comment #7)
> Currently this impacts our button component in Ionic Framework:
> https://github.com/ionic-team/ionic-framework/issues/23256.
> 
> I have not received reports of this impacting production Ionic Framework
> apps, though I imagine I will receive more reports as people upgrade to iOS
> 14.5.

Thanks for the clarification!

[Tobias Trumm]

Our app uses ionic's capacitor framework as a base and vue + vuetify as UI framework. We noticed this issue in our released app after updating to iOS 14.5. The hint about the pointer-events property helped us to find a css workaround that we will ship with our next app release.

[Manny Diera]

Just encountered this issue and tried setting the pointer events to unset. 

This worked for the CSS issue but affected the event handling. We are thinking about either leaving the pointer-events as unset and use event delegation to handle the events or go through and find the CSS variable that is getting passed into the button and affecting the style. 

@Tobias Trumm - Were these the css workarounds that worked for you or is there something else you could recommend?

[Manny Diera]

(In reply to Tobias Trumm from comment #9)
> Our app uses ionic's capacitor framework as a base and vue + vuetify as UI
> framework. We noticed this issue in our released app after updating to iOS
> 14.5. The hint about the pointer-events property helped us to find a css
> workaround that we will ship with our next app release.


Just encountered this issue and tried setting the pointer events to unset. 

This worked for the CSS issue but affected the event handling. We are thinking about either leaving the pointer-events as unset and use event delegation to handle the events or go through and find the CSS variable that is getting passed into the button and affecting the style. 

@Tobias Trumm - Were these the css workarounds that worked for you or is there something else you could recommend?

[Tobias Trumm]

(In reply to Manny Diera from comment #11)
> @Tobias Trumm - Were these the css workarounds that worked for you or is
> there something else you could recommend?

Vuetify's button implementation does set "pointer-event: none" but does not rely on it for its event handling internally, so in our case setting 

.v-btn--disabled {
  pointer-events: unset !important;
  cursor: default;
}

was enough to restore the original look and behaviour.


Seeing that iOS 14.6 RC was just released, it might also be worth to check if this bug is already fixed there and if so, wait for its final release, instead of implementing your own event handling.

[Ryosuke Niwa]

(In reply to Tobias Trumm from comment #12)
> (In reply to Manny Diera from comment #11)
> > @Tobias Trumm - Were these the css workarounds that worked for you or is
> > there something else you could recommend?
> 
> Vuetify's button implementation does set "pointer-event: none" but does not
> rely on it for its event handling internally, so in our case setting 
> 
> .v-btn--disabled {
>   pointer-events: unset !important;
>   cursor: default;
> }
> 
> was enough to restore the original look and behaviour.
> 
> 
> Seeing that iOS 14.6 RC was just released, it might also be worth to check
> if this bug is already fixed there and if so, wait for its final release,
> instead of implementing your own event handling.

It's not fixed in iOS 14.6 RC.

[Liam DeBeasi]

This appears to be fixed in iOS 14.7 beta 1. Thank you!

[Antti Koivisto]

Thanks for confirming, the fix should indeed be there.