Uh oh!
There was an error while loading. Please reload this page.
Make XMLHttpRequest and XMLHttpRequest.upload proper EventTargets - #7017
Make XMLHttpRequest and XMLHttpRequest.upload proper EventTargets#7017philikon wants to merge 1 commit into
Conversation
facebook-github-bot
commented
Apr 17, 2016
By analyzing the blame information on this pull request, we identified @sreesharp, @nicklockwood and @grgmo to be potential reviewers. |
mkonicek
commented
Apr 19, 2016
Is this one good to go? Should I merge it? |
sreesharp
commented
Apr 19, 2016
Code looks good to me. Hope Flow is not complaining about the XHRBase static attributes. |
philikon
commented
Apr 19, 2016
Flow didn't complain. Should be good to go. |
grgmo
commented
Apr 20, 2016
looks good to me, good to merge |
mkonicek
commented
Apr 20, 2016
@facebook-github-bot shipit |
facebook-github-bot
commented
Apr 20, 2016
Thanks for importing. If you are an FB employee go to Phabricator to review. |
@philikon Looks like this breaks fetching QEs in one of our internal apps. Maybe @andreicoman11 knows what's wrong? |
philikon
commented
Apr 20, 2016
Weird. In an end-to-end test or in a unit test? If it's a unit test, I could imagine that the unit test uses some internal knowledge of XMLHttpRequestBase to stub out some stuff. Anyway, I'd love to help in whatever way I can to fix that. You guys know where to find me :) |
mkonicek
commented
Apr 21, 2016
Philipp I've just sent you a message :) |
philikon
commented
Apr 21, 2016
I've just looked over the diff again. There's very little behavioral change to XHR, so I'm surprised there's a new failure. The biggest change is obviously concerning the
The other change is that event handlers now get an event object rather than Wish I could be more helpful. If it's too difficult to track down the problem on your end, @mkonicek, we can also try to take this diff in steps and see which change creates the failure. Would be tedious, but perhaps in the end quicker? Your call. |
TanTan-TT
commented
Apr 23, 2016
@philikon I have a question after reading RN Android code. RN Android networking code did not handle upload progress event, so your change can not make uploading progress works. Am I right? |
philikon
commented
Apr 25, 2016
Correct, this doesn't change the supported functionality on either platform. |
mkonicek
commented
Apr 25, 2016
@philikon I'll try installing fb4a in my emulator and running the running the test locally to repro the timeout. |
ghost
commented
Apr 26, 2016
@philikon updated the pull request. |
There was a problem hiding this comment.
no-undef: 'EventListener' is not defined.
ghost
commented
Apr 26, 2016
@philikon updated the pull request. |
ghost
commented
Apr 27, 2016
@philikon updated the pull request. |
philikon
commented
Apr 27, 2016
(circleci failure unrelated) |
mkonicek
commented
Apr 27, 2016
@facebook-github-bot shipit |
ghost
commented
Apr 27, 2016
Thanks for importing. If you are an FB employee go to Phabricator to review. |
ghost
commented
Apr 28, 2016
@philikon updated the pull request. |
Rebased on top of D3229435 / d363b1f. Can somebody plz re-import kthxbai :) |
mkonicek
commented
Apr 29, 2016
#finallylanded 👍 |
mkonicek
commented
Apr 29, 2016
Thanks for the help Kevin! |
Summary:
So far, XHR only supports a few `onfoo` event handlers, not the entier `EventTarget` interface (`addEventListener`, `removeEventListener`). It also doesn't support the `upload` object on Android -- for no good reason. Even if we don't send any events there yet, there's no reason we have to break consuming code that wants to register an event handler there. This PR rectifies all that.
Fortunately, adding proper `EventTarget` support is very easy thanks to `event-target-shim`. We already use it in our WebSocket implementation. It transparently handles the `addEventListener('foo', ...)` as well as `onfoo` APIs, so when you dispatch an event on the event target, the right handlers will be invoked. The event object is wrapped so that `event.target` is set properly. Basically, it's a super easy way to make us conform to the spec.
Also added a bit of polish here and there, using ES2015 class property goodness to consolidate a lot of Flow property definitions with the corresponding property initializers.
**T
Closesreact#7017
Reviewed By: fkgozali
Differential Revision: D3202021
Pulled By: martinbigio
fb-gh-sync-id: 2b007682074356c75c774fab337672918b6c4355
fbshipit-source-id: 2b007682074356c75c774fab337672918b6c4355Summary:
So far, XHR only supports a few `onfoo` event handlers, not the entier `EventTarget` interface (`addEventListener`, `removeEventListener`). It also doesn't support the `upload` object on Android -- for no good reason. Even if we don't send any events there yet, there's no reason we have to break consuming code that wants to register an event handler there. This PR rectifies all that.
Fortunately, adding proper `EventTarget` support is very easy thanks to `event-target-shim`. We already use it in our WebSocket implementation. It transparently handles the `addEventListener('foo', ...)` as well as `onfoo` APIs, so when you dispatch an event on the event target, the right handlers will be invoked. The event object is wrapped so that `event.target` is set properly. Basically, it's a super easy way to make us conform to the spec.
Also added a bit of polish here and there, using ES2015 class property goodness to consolidate a lot of Flow property definitions with the corresponding property initializers.
**T
Closesreact#7017
Reviewed By: fkgozali
Differential Revision: D3202021
Pulled By: martinbigio
fb-gh-sync-id: 2b007682074356c75c774fab337672918b6c4355
fbshipit-source-id: 2b007682074356c75c774fab337672918b6c4355
So far, XHR only supports a few
onfooevent handlers, not the entierEventTargetinterface (addEventListener,removeEventListener). It also doesn't support theuploadobject on Android -- for no good reason. Even if we don't send any events there yet, there's no reason we have to break consuming code that wants to register an event handler there. This PR rectifies all that.Fortunately, adding proper
EventTargetsupport is very easy thanks toevent-target-shim. We already use it in our WebSocket implementation. It transparently handles theaddEventListener('foo', ...)as well asonfooAPIs, so when you dispatch an event on the event target, the right handlers will be invoked. The event object is wrapped so thatevent.targetis set properly. Basically, it's a super easy way to make us conform to the spec.Also added a bit of polish here and there, using ES2015 class property goodness to consolidate a lot of Flow property definitions with the corresponding property initializers.
Test Plan: Ran through the XHR Example in UIExplorer on both platforms. Made sure upload progress events still work on iOS and timeouts work.