Generated by 🚫 dangerJS against 1e77b3f

The changes should solve two structural issues: 1. the JavaScript change event was fired before we listen to it. 2. The input value is hidden for security reasons. What browser issues do you have in mind?

What browser issues do you have in mind?

That was my question. It is not obvious what issue is solved here. Only theoretical issues that have no confirmed reproduction.

Only theoretical issues that have no confirmed reproduction.

We have a couple of root issues:

1. A user writes in an input before we listen to the event. This can be reproduced on the /examples/ssr/ example with a set timeout in the hydration logic.
2. Chrome autofill the input before React hydrates the from. This can be reproduced with [TextField] Handle Chrome autofill #14427 (comment).
3. Chrome doesn't fire a change event. This can be reproduced in reproduced [TextField] Handle Chrome autofill #14427 (comment) with BrowserStack Windows 10, Chrome latest

To be clear: A reproduction is code + environment.

A user writes in an input before we listen to the event. This can be reproduced on the /examples/ssr/ example with a set timeout in the hydration logic.

What is the use case for hydrating after a timeout? Seems like a strawman to me.

Chrome autofill the input before React hydrates the from. This can be reproduced with #14427 (comment).

As I said no example in that issue has a confirmable reproduction. It might reproduce for you but without knowing the environment you cannot know if this is a library or environment issue.

Chrome doesn't fire a change event. This can be reproduced in reproduced #14427 (comment) with BrowserStack Windows 10, Chrome latest

BrowserStack is not a reliable source for reproduction. If it was we would not have tabable buttons in safari.

What is the use case for hydrating after a timeout?

For instance, you might want to wait for an optional polyfill to be loaded, over the network, before hydrating your DOM. I had the very use case at Onepixel, I was frustrated Next.js has no support for it.

As I said no example in that issue has a confirmable reproduction.

Then we can call it a nice side effect of fixing the previous issue.

BrowserStack is not a reliable source for the reproduction

Don't worry, we have enough users to report if these fixes don't cut it. I don't think that we should wait to get the perfect reproduction, we might never have it. I think that we should move fast (type 2, reversible changes) by sacrificing the scope of the problems we solve and the information we collect, without sacrificing the code quality so we can learn from "production". In this case, we have an opportunity to try these changes. Worse case 1. we still have this bug, people provide a better reproduction, worse case 2. we solved the bug, but we remove the logic in the future, for some reason, people report the regression or they don't. In any case, the changes are direct application of people reported solution to the problem we can find on GitHub issues, commit, blog post or StackOverflow. @croraf and I have seen a positive impact with them. Things are imperfect and will always be :).

Well thanks for adding technical debt that we need to refactor.

@eps1lon I'm sorry you feel this way. I understand that you have done great progress in the past simplifying the logic of this component and that you want to keep it in a great state. I will personally make sure this new logic only remains if proven valuable. Meaning:

• If React solves the related issues Provide a way to handle browser-autocompleted form values on controlled components react/react#1159, Fire change events for changes made to inputs before hydration react/react#12955, investigate if we can remove the patch (as far as I know, these issues have been present since the first version of React).
• If we still get autocomplete issue report, investigate if these changes are really relevant, look for better solutions.

But yes, the more problems we solve, the more complex the codebase is and the more inertia we have. Sometimes, it's better not to solve problems reported by our users. I don't think it's one of these cases.
Assuming that we want to solve the problem. I don't think that we went down a quick patch road. It should be resilient.

this update makes me change something to still have my transparent background for my input:

Separate css

/* Chrome hack for auto set password ;) */
@-webkit-keyframes autofill {
    to {
        color: white;
        background: transparent;
    }
}

Adaptation in theming, to still have this transparent background and not a grey-blue one

MuiInputBase: {
            input: {
                '&:-webkit-autofill': {
                    animationName: 'autofill',
                    animationFillMode: 'both',
                    animationDuration: '0s'
                  },
            }
        }  

@jkeruzec Do you have a reproduction?