Closed Bug 1266217 Opened 4 years ago Closed 4 years ago
Sockets are broken on Android
Maire reported to me that they were trying to use Web Sockets in some test, which was not working. She then realized the Web Socket tests are turned off for Android right now due to bug 1144079 (!). Testing manually on Nightly, they do indeed appear to be broken.
4 years ago
I manually tested with http://websocket.org/echo.html which works on Desktop (Mac), but not in Fennec.
Above I referenced bug 1144079 re: disabled tests, but it seems that's only for web sockets inside of workers. Normal web socket tests appear to be enabled, so this is puzzling.
The patches from bug 1231981 and bug 1231975 are how I tripped over this problem. I went looking for websocket mochitests, and the first one I found (dom/base/test/test_bug1081686.html) was disabled on android. When tested on android try, it fails in the same way that my websocket code does.
Dupe of bug 1255950?
daniel - regressions needs to be necko-active with an owner assigned. interestingly http://websocket.org/echo.html is also broken for me on linux nightly desktop (tho I'm neutral on whether that's the origin or firefox to blame as I haven't looked into it). I'll attach a log in a few minutes.
Assignee: nobody → michal.novotny
Whiteboard: [necko-backlog] → [necko-active]
ok - this is weird. necko is being asked to connect to ws://websocket.org/?encoding=text when the form that gets the uri is populated with ws://websocket.org so we get 404 when bootstrapping because that's the wrong uri. You can see the ?encoding=text in the console. Is there a reason to think websockets-the-protocol is broken other than this site? If not then we should probably move this on to dom or js or something because it definitely looks like a regression of some sort.
actually ws://websocket.org/ is returning 404 as well. this site fails in chrome too right now. So this might just be a site problem. (likely). http://websocketstest.com/ works fine in nightly desktop and android (45) which make me think the protocol concerns are invalid. please flag info to the contrary. I think some dom/js help about the uri is apropos though.
Assignee: michal.novotny → nobody
Component: Networking: WebSockets → DOM: Core & HTML
smaug, do you have a second to look at http://websocket.org/echo.html seems to be asking necko to connect to ws://websocket.org/?encoding=text when you hit the connect button.. the query string is unexpected. (the site's websockets server is down, so the test probably won't work regardless.. but you can see the ws:// uri in the console when you press connect).
I took the time to get a trace of chrome and it also uses ws://wesocket.org/?encoding=text .. I'm not clear on where that comes from, but as its the same its probably not worth answering the ni just to educate me :) so I'm going to mark this invalid based on comment 7.. reopen if I've missed something,
Status: NEW → RESOLVED
Closed: 4 years ago
Resolution: --- → INVALID
You need to log in before you can comment on or make changes to this bug.