Skip to content
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

[Android 0.13.0] Websockets throws exception 'No transports available' with Firebase #3645

Closed
yeso126 opened this issue Oct 23, 2015 · 18 comments
Labels
Resolution: Locked This issue was locked by the bot.

Comments

@yeso126
Copy link

yeso126 commented Oct 23, 2015

I'm using Firebase sdk which uses websocket, when I create a ref to my firebase I get the message.

@ide
Copy link
Contributor

ide commented Oct 23, 2015

Can you debug what's going on e.g. where the source of the error is?

@yeso126
Copy link
Author

yeso126 commented Oct 23, 2015

I'm on windows so debugging does not work. :( error

@mkonicek
Copy link
Contributor

Wait you don't even see line numbers? The source map is fetched asynchronously. Do the line numbers appear after a while. It's possible source maps are not supported yet on Windows.

@mkonicek
Copy link
Contributor

Would be good to know whether source maps work or not. If more people confirm we should add it here:
https://facebook.github.io/react-native/docs/linux-windows-support.html

@yeso126
Copy link
Author

yeso126 commented Oct 24, 2015

I've updated to 0.13.1
Looks like it has something to do with firebase
error

@satya164
Copy link
Contributor

I've been using WebSockets with socket.io for sometime now. I had to disable the jsonp transport for it to work.

@mkonicek
Copy link
Contributor

Interesting! Can you try using non-minified version of Firebase and reading it source at the place where it happens / Googling why Firebase throws this error?

@mkonicek
Copy link
Contributor

I'm glad the source maps are working for you!

@puf
Copy link
Contributor

puf commented Nov 13, 2015

@satya164 @ide
This problem seems to be caused by the loading order. If you use this order it works:

var React = require('react-native')
var Firebase = require('firebase');

But if you swap them around, you get the problem described:

var React = require('react-native')
var Firebase = require('firebase');

It seems like the WebSocket polyfill is being loaded as part of the react-native module, which unfortunately doesn't work.

So the work-around for the issue is to ensure you require react-native first, but it's still a bug. WebSockets are natively available on most browsers, so it's better to ensure they're available before module loading starts.

@yeso126
Copy link
Author

yeso126 commented Nov 13, 2015

omg, how didn't I think about that? thanks

@ide
Copy link
Contributor

ide commented Nov 13, 2015

@puf, yes this is a known issue. For the time being, always start your entry point off with requiring/importing react-native. Would appreciate a PR adding that to the troubleshooting docs.

@puf
Copy link
Contributor

puf commented Nov 13, 2015

#4108

@mkonicek mkonicek changed the title [Android 0.13.0] websockets throws exception 'No transports available' [Android 0.13.0] Websockets throws exception 'No transports available' with Firebase Nov 13, 2015
@mkonicek
Copy link
Contributor

Oh OK this is a tough one :) It would be amazing if you could send a PR to Firebase to make that error message more explanatory. Any other ideas to make this better?

@puf
Copy link
Contributor

puf commented Nov 13, 2015

The Firebase client tries to use WebSockets to connect to the server, but they are missing (because the polyfill is not loaded yet). It then tries to fall back to long-polling, which it also cannot do in the context of React Native. So it finally throws an error that it cannot find a suitable transport mechanism to connect to the server.

I think we'll have a better chance at people finding this issue (and the workaround of putting the require() statements in the right order) now that it's properly labeled/titled.

@mkonicek
Copy link
Contributor

Linked here: https://productpains.com/post/react-native/firebase-not-working-on-android/

Thanks so much for reporting and debugging this and adding the docs @puf!

I'll close this one as it looks like the issue is solved.

@puf
Copy link
Contributor

puf commented Nov 15, 2015

The cause of the problem is clear, there is a workaround, and we documented it to make it more findable.

But there is still an underlying problem in the loading order of dynamic modules vs polyfills for native functionality (such as WebSockets). @ide commented that this was a known issue, in which case this report should probably be linked to that known issue too.

@paramaggarwal
Copy link
Contributor

paramaggarwal commented Aug 16, 2016

@puf you mentioned:

It then tries to fall back to long-polling, which it also cannot do in the context of React Native.

Why so? I am looking to using socket.io in ['polling', 'websocket'] mode with jsonp: false. This is because unencrypted websockets won't work in certain client network proxies.

@puf
Copy link
Contributor

puf commented Aug 16, 2016

Hmm... I don't remember why I commented with that.
I think at the time it was related to requiring the window object (possibly
related to JSONP).
Sorry I can't be of more help.

On Tue, Aug 16, 2016 at 8:51 AM Param Aggarwal notifications@github.com
wrote:

@puf https://github.com/puf you mentioned:

It then tries to fall back to long-polling, which it also cannot do in the
context of React Native.

Why so? I am looking to using socket.io in ['polling', 'websocket'] mode
with jsonp: false. THis is because unencrypted websockets won't work in
certain client network proxies.


You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
#3645 (comment),
or mute the thread
https://github.com/notifications/unsubscribe-auth/AA3w31N__YxQzhtDfeaEvHgS427FXOQOks5qgdx5gaJpZM4GU2v6
.

@facebook facebook locked as resolved and limited conversation to collaborators Jul 21, 2018
@react-native-bot react-native-bot added the Resolution: Locked This issue was locked by the bot. label Jul 21, 2018
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Labels
Resolution: Locked This issue was locked by the bot.
Projects
None yet
Development

No branches or pull requests

8 participants
@mkonicek @ide @paramaggarwal @puf @satya164 @yeso126 @react-native-bot and others