Carbon: Checkbox and RadioButton do not respond to state change of disabled attribute in MS Edge

Created on 22 Jun 2018  路  16Comments  路  Source: carbon-design-system/carbon

Checkbox and RadioButton do not respond to disabled state change in MS Edge. State change works fine for the vanilla checkbox.

CodeSandbox repro here: https://codesandbox.io/s/wk215jw068

Detailed description

Describe in detail the issue you're having.

In MS Edge, when you have something like <Checkbox disabled={this.state.disabled} id="2" labelText="Carbon Checkbox" />, changing the disabled state does not update the style in the UI.

Is this a feature request (new component, new icon), a bug, or a general issue?

Bug

Is this issue related to a specific component?

Yes

What did you expect to happen? What happened instead? What would you like to see changed?

I expected that, when you do setState({ disabled: true }) that the cursor style would switch to disabled and the text would be grayed out.

Instead, the styles do not change immediately when setState() is called.

I would like the styles to change immediately when setState() is called.

What browser are you working in?

Microsoft Edge 42.17134.1.0
Microsoft EdgeHTML 17.17134

What version of the Carbon Design System are you using?

carbon-components 9.1.1
carbon-components-react 6.6.3
carbon-icons 7.0.7
react 16.3.2
react-dom 16.3.2

What offering/product do you work on? Any pressing ship or release dates we should be aware of?

Not really. We ship June 25 but this is not a priority for our release.

Steps to reproduce the issue

CodeSandbox repro here: https://codesandbox.io/s/wk215jw068

Here is a gif: ezgif-3-77773e76f0

Most helpful comment

I'm fine to reopen this, and I think it probably makes more sense to move to carbon-components given that it is primarily a CSS issue rather than React specific.

The point about browser issues/differences is a fair one. From a core Carbon contribution team, this might not be a current priority. But I think it's perfectly reasonable to leave this open for collaborative solutions and potential fixes by the community.

All 16 comments

@tw15egan just following up. Is there any plan to fix this bug?

Hey there @oliverodaa! It has been placed in the backlog, but there is currently no timetable for a fix. We would love any PR's that address this issue 馃憤

No worries at all. As long as it's on the backlog somewhere, I'm happy. Thanks for all the great work on this library!

Thank you! And thanks to our wonderful contributors that help make this library even more robust 馃挭

Been debugging this today and unfortunately, it seems like this is an issue with MS Edge and auto-refresh in general. Cause the component does not refresh when I try and change any other props either, it requires a hard refresh in the browser. I found more info about it here https://stackoverflow.com/questions/39737602/select-control-created-in-react-does-not-reset-on-browser-refresh-ie11-and-edge. So I don't think there's anything we can do on our end here, the component does update as soon as you interact with it or if you trigger a state change somewhere else in your application.

Closing this issue due to it not being resolvable, but please feel free to re-open if you disagree or if you have a suggestion for a fix!

@marijohannessen Thanks for taking the time to work on it!

To be honest I'm having trouble understanding why it's not resolvable.

this is an issue with MS Edge and auto-refresh in general

What is auto-refresh? I tried researching it but can't find anything on that topic.

Cause the component does not refresh when I try and change any other props either, it requires a hard refresh in the browser.

Right. The problem is that the component doesn't refresh. That's a problem with the component that should probably be fixed, right?

I found more info about it here https://stackoverflow.com/questions/39737602/select-control-created-in-react-does-not-reset-on-browser-refresh-ie11-and-edge.

I might be missing something here. How is that applicable to this case?

So I don't think there's anything we can do on our end here, the component does update as soon as you interact with it

Unfortunately for our specific usage we can't just hope that the user will interact with the component.

or if you trigger a state change somewhere else in your application.

What do you mean by that? Where would the state change have to be in the application for the checkbox to show the changes?


If it's okay with you, I'd really appreciate you taking another stab at it.

My reasoning is:

  • We can't claim that it's a problem with <input> tags in general, because as you can see in the CodeSandbox repro, the state change works perfectly fine for the plain <input> tag.
  • We can't claim that it's a problem with React or component props in general, because there are plenty of other components that do not have this problem in MS Edge.
  • Therefore, the problem must be specific to this Carbon component.

If the problem is specific to this Carbon component then it must be resolvable, right?

Hmm okay, I must have misunderstood the issue, sorry about that! I do see the issue now and how it works on the plain <input> but not our component, so let me take another look today or tomorrow and see if I can figure out what's going on.

Thank you! I really appreciate you re-opening the issue - fixing it will make a big difference for my product.

Hi @oliverodaa thank you for reporting the issue! (Also thanks @marijohannessen for taking the initial look!) Here鈥檚 what I saw when the problem reproduces in @oliverodaa鈥檚 CodePen: window.getComputedStyle(document.querySelector('label.bx--checkbox-label')).getPropertyValue('opacity') gets out-of-sync with document.querySelector('input.bx--checkbox').hasAttribute('disabled'). User-interaction with the check box makes those get back in sync. Those findings led me to a bug in Microsoft Edge: https://developer.microsoft.com/en-us/microsoft-edge/platform/issues/11295231

CC @alisonjoseph

@asudoh thank you so much for taking a look and narrowing down the problem to a bug in MS Edge.

Does Carbon Components React support MS Edge?

My team follows the IBM Cloud minimum standards so we need this to work in Edge: https://console.bluemix.net/docs/overview/prereqs.html#prereqs

It would be amazing if you could reopen the issue and find a workaround for MS Edge.

Hi @oliverodaa the finding where MSEdge does not work with simple standard styling (which it鈥檚 supposed to work) led me that we should let MSEdge fix the problem. Meanwhile, you may want to create a custom React component (starting with https://github.com/IBM/carbon-components-react/blob/7bee608/src/components/Checkbox/Checkbox.js) that does input > label structure seen at: http://www.carbondesignsystem.com/components/checkbox/code

we should let MSEdge fix the problem

Seems reasonable. Thanks for taking the time on the bug.

@asudoh @joshblack Can we please re-open this? I think it is unacceptable to punt this by saying that Edge should fix their issue -- much of web development is working around/through browser differences.

The Edge issue you point to explicitly references a workaround:

Known workaround
A known workaround is to have another CSS rule that uses the disabled attribute followed by a sibling combinator. This rule can be empty (no properties) and can even target a completely non-existant type of element. It just needs to be there.
A minimal sufficient rule to avoid the issue from occuring anywhere in the loaded document is:
[disabled] ~ _ {}

Seems like you can start there.

As it stands, we are forced to update our app to output standard checkboxes for Edge rather than Carbon checkboxes -- not a very good Carbon experience.

Hey @jhpedemonte! 馃憢

Definitely agreed that there could be a cleaner solution here, especially given that there is a workaround and it is minimal. Maybe we could re-open this, or move to carbon-components, and start investigating using the workaround?

I'm fine to reopen this, and I think it probably makes more sense to move to carbon-components given that it is primarily a CSS issue rather than React specific.

The point about browser issues/differences is a fair one. From a core Carbon contribution team, this might not be a current priority. But I think it's perfectly reasonable to leave this open for collaborative solutions and potential fixes by the community.

:tada: This issue has been resolved in version 9.60.1 :tada:

The release is available on:

Your semantic-release bot :package::rocket:

Was this page helpful?
0 / 5 - 0 ratings