-
Notifications
You must be signed in to change notification settings - Fork 47k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Wrapper-type fix for <progress> element not returning to an indeterminate state (#1431) #1443
Wrapper-type fix for <progress> element not returning to an indeterminate state (#1431) #1443
Conversation
…nsitions from being set to being null, the progress component does not return to the "indeterminate" state (barbershop pole).
…mponent's value is set to null or undefined, the progress element returns to the indeterminate state (barbershop pole).
I ran into the same problem when the tests ran on Android. Perhaps verifying that node.value == null is sufficient in determining we have achieved success. |
Interesting. Those tests fail on Android, because they target Android 4.0. Android didn't introduce support for the edbaa9e skips the |
Hmm, I'm curious if a separate wrapper is really needed, after thinking a bit more on it it seems to me like In my mind at least, I'd say the preferred order of potential solutions would be: @zpao @spicyj Side-note, is there a reason why |
Agree that fixing DOMPropertyConfig is preferable to a wrapper. @syranide Not quite sure what you mean about shouldIgnoreValue, sorry? |
After talking on IRC, keeping this declarative in some way sounds like the best option (maybe making https://gist.github.com/zpao/11268735 or similar work). But in the short term this might be acceptable. |
I would be happy to work on the property override solution; just let me know. |
Thank you for signing our Contributor License Agreement. We can now accept your code for this (and any) Facebook open source project. Thanks! |
I don't think we're going to do it this way, so I'm closing this out. Hopefully one of the other solutions will make it in soon. |
Here's a wrapper solution to #1431, in case it is decided that a wrapper is the way to go, rather than a mutation method.