This site will have limited functionality while we undergo maintenance to improve your experience. If an article doesn't solve your issue and you want to ask a question, we have our support community waiting to help you at @FirefoxSupport on Twitter and/r/firefox on Reddit.

Search Support

Avoid support scams. We will never ask you to call or text a phone number or share personal information. Please report suspicious activity using the “Report Abuse” option.

Learn More

(Dis)connecting WIFI after a web socket has been established with local host, sends next message but clsoes on response

  • 1 reply
  • 0 have this problem
  • 8 views
  • Last reply by Gary

more options

When using FF connected to local host by HTTP and web-socket connections, am experiencing an issue when WIFI is newly disconnected or connected.

When the page is first loaded (whether WIFI is connected or not), both HTTP and web sockets work as expected. When the WIFI connection is then changed from its current state, initially no errors are thrown. However, although the very next web-socket request from the browser to the local server reaches the server, the response is rejected by the browser and the socket is closed, firing the onerror and onclose events of the socket. The HTTP requests are still processed in both directions (can fetch without issue) and can request another new web socket connection without error. The error thrown is `The connection to ws://127.0.0.1/34215... was interrupted while the page was loading.`

This takes place when the port is anything other than 8000; all works as expected when the port number is 8000. The local server was set to choose a random unused port number to avoid conflicts with any other running applications.

If the socket would throw an error before sending the new request, then it would be less of an issue; but, when that request was to save data passed in the XOR frame, the browser has no way of knowing whether or not it was successful because it rejects the response, such that the UI and database could become out-of-sync.

This is run under a separate profile that is set to work offline (removing offline does not resolve this). Are there any `about:config settings` that might stop the browser from rejecting the responses? Perhaps it is a security measure.

This was tested on chrome-based browsers and WIFI can be connected and disconnected multiple times and the web socket is never closed regardless of the port number.

Thank you for any guidance you may be able to provide.

When using FF connected to local host by HTTP and web-socket connections, am experiencing an issue when WIFI is newly disconnected or connected. When the page is first loaded (whether WIFI is connected or not), both HTTP and web sockets work as expected. When the WIFI connection is then changed from its current state, initially no errors are thrown. However, although the very next web-socket request from the browser to the local server reaches the server, the response is rejected by the browser and the socket is closed, firing the onerror and onclose events of the socket. The HTTP requests are still processed in both directions (can fetch without issue) and can request another new web socket connection without error. The error thrown is `The connection to ws://127.0.0.1/34215... was interrupted while the page was loading.` This takes place when the port is anything other than 8000; all works as expected when the port number is 8000. The local server was set to choose a random unused port number to avoid conflicts with any other running applications. If the socket would throw an error before sending the new request, then it would be less of an issue; but, when that request was to save data passed in the XOR frame, the browser has no way of knowing whether or not it was successful because it rejects the response, such that the UI and database could become out-of-sync. This is run under a separate profile that is set to work offline (removing offline does not resolve this). Are there any `about:config settings` that might stop the browser from rejecting the responses? Perhaps it is a security measure. This was tested on chrome-based browsers and WIFI can be connected and disconnected multiple times and the web socket is never closed regardless of the port number. Thank you for any guidance you may be able to provide.

All Replies (1)

more options

If it matters, Firefox is opened programmatically from Tcl using:

exec firefox -P "ToolTest" -no-remote -new-instance -offline \

   -private -url http://${addr}:${port}/login &