-
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
Rely on bubbling for submit and reset events #13358
Rely on bubbling for submit and reset events #13358
Conversation
I found a test that was written more than 5 years ago and probably never run until now. The behavior still works, although the API changed quite a bit over the years. Seems like this was part of the initial public release already: facebook@75897c2#diff-1bf5126edab96f3b7fea034cd3b0c742R31
Oh and FYI I have a background (#12877) in breaking |
Whoopsie.
6c51055
to
425738e
Compare
ReactDOM: size: -0.1%, gzip: -0.1% Details of bundled changes.Comparing: be4533a...425738e react-dom
Generated by 🚫 dangerJS |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
This looks right to me, and I'd like to get this change in. It safely removes another special case, which slowly makes it easier to work on event system code.
As far as I can tell, this existed to support IE8. I wasn't able to track this down in the source, but it is referenced in Meteor's article about their event system:
https://blog.meteor.com/browser-events-bubbling-capturing-and-delegation-14db28e924ae
I have faith in @philipp-spiess, but I can also do some extra testing tomorrow morning for good measure.
Separately: Should we just publish the browser list somewhere? It doesn't have to be official support, I'd just like to make it easier for contributors to stumble upon.
@@ -361,7 +361,6 @@ describe('ReactDOMEventListener', () => { | |||
<audio {...mediaEvents}> | |||
<source {...mediaEvents} /> | |||
</audio> | |||
<form onReset={() => {}} onSubmit={() => {}} /> |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
For other reviewers: I was curious about this removal, but it's a part of a general test that asserts how listeners are attached:
react/packages/react-dom/src/__tests__/ReactDOMEventListener-test.js
Lines 355 to 378 in 425738e
try { | |
// We expect that mounting this tree will | |
// *not* attach handlers for any top-level events. | |
ReactDOM.render( | |
<div> | |
<video ref={videoRef} {...mediaEvents} onPlay={handleVideoPlay} /> | |
<audio {...mediaEvents}> | |
<source {...mediaEvents} /> | |
</audio> | |
</div>, | |
container, | |
); | |
// Also verify dispatching one of them works | |
videoRef.current.dispatchEvent( | |
new Event('play', { | |
bubbles: false, | |
}), | |
); | |
expect(handleVideoPlay).toHaveBeenCalledTimes(1); | |
} finally { | |
document.addEventListener = originalAddEventListener; | |
document.body.removeChild(container); | |
} |
👍
🙂 I've rebuild everything locally (including an additional
👍 I came across that by total accident today. Maybe we can mention some browsers to test in the contribution documentation? |
This looks great on my end. Feel free to merge! |
@nhunzaker covered iOS and Android as well (we should probably add versions there to the browser list as well). Let's give it a shot?! 😱 🎉 |
This reverts commit 725e499.
Fixes #12251
We can get rid of some special cases by relying on bubbling for
submit
andreset
events instead of adding the events to the individual<form>
elements. After reading #12251 I was curious and had to try that out. Here are my manual testing results:Modern
✅ Chrome 67
✅ Firefox 61
✅ Edge 17
✅ Safari 12
Legacy
✅ Chromium 41
✅ Firefox ESR 52
✅ Safari 6
✅ Internet Explorer 9
(The browser list is inspired by #9301 (comment))
Note: This does not fix any bug and also only has minimal impact on the bundle size. I'm not sure if we really want it.
I used a custom fixture to test that if you want to reproduce. I don't think we want to add this though since I hardly believe that this behavior will ever change again and it would only make manual testing even more time consuming. Let me know if you think I should add it.
While looking in the repository for occurrences of the term
submit
, I also found a lonely test that that was written more than 5 years ago and probably never run until now. The behavior still works, although the API changed quite a bit over the years. Seems like this test was part of the initial public release already: 75897c2#diff-1bf5126edab96f3b7fea034cd3b0c742R31In addition to all that, I also found out that the yarn lockfile for the DOM fixtures was outdated.