Uh oh!
There was an error while loading.Please reload this page.
- Notifications
You must be signed in to change notification settings - Fork9.7k
[Form] Fix custom formats deprecation with HTML5 widgets#37837
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 ourterms of service andprivacy statement. We’ll occasionally send you account related emails.
Already on GitHub?Sign in to your account
Uh oh!
There was an error while loading.Please reload this page.
Conversation
fancyweb commentedAug 14, 2020
Looking at the failing tests I just noticed I did not fix all cases yet. Before putting more efforts in, what do you think of the proposed solution@xabbuh? |
nicolas-grekas commentedAug 31, 2020
xabbuh commentedSep 1, 2020
@fancyweb Isn't the test just failing because of the bug you are fixing here? I mean the test does not set the |
fabpot commentedSep 19, 2020
@fancyweb Can you have a look at the last comment? |
f0b8d1c tod28182fComparefancyweb commentedSep 24, 2020
@xabbuh I finally took the time to look at this and you were right. I set the html5 option to false on the failing test. |
fabpot commentedSep 24, 2020
Thank you@fancyweb. |
html5option is enough to pass the logical condition of the callback.That means that only setting the
formatoption (like in the reproducer) does not trigger the deprecation while it should. I think we need a feature in the options resolver component to handle those kind of cases 🤷♂️Meanwhile, we can fix the issue by "deprecating" all the concerned options of the logical condition of the callback.