[Stingray] Cannot open websocket with offline

RESOLVED DUPLICATE of bug 967792

Status

RESOLVED DUPLICATE of bug 967792
4 years ago
4 years ago

People

(Reporter: kiwata.moz, Assigned: mcmanus)

Tracking

Firefox Tracking Flags

(Not tracked)

Details

(Whiteboard: [Stingray-Branch])

Attachments

(1 attachment)

(Reporter)

Description

4 years ago
We use websocket between Some app and backend process.
This works OK when our device is connected to network, 
however if we disconnect from the network,
opening the websocket always failes, means 'error' event is invoked.

Here is our summarized source code.
------------------------------------------------------------------
  WebSocketManager.prototype._connect = function() {
    try {
      this._socket = new WebSocket('ws://localhost:XXXXX',
                                   'contents-req-protocol');
      this._socket.onopen = this._handleEvent.bind(this);
      this._socket.onclose = this._handleEvent.bind(this);
      this._socket.onerror = this._handleEvent.bind(this);
      this._socket.onmessage = this._handleEvent.bind(this);
    } catch (e) {
      console.error(e);
    }
  };

  WebSocketManager.prototype._handleEvent = function(evt) {
    switch (evt.type) {
      case 'open':
.....
------------------------------------------------------------------
  *) I masked port number as XXXXXX

  With connecting to network, 'open' event is handled and works OK.
  Without connecting to network, 'error' and then 'close' event is handled.
(Reporter)

Updated

4 years ago
Assignee: nobody → juhsu
Group: panasonic-confidential
Whiteboard: [Stingray-Branch]
I think the bug should be taken by him/her self after anyone understand the whole picture of the bug.
So please allow me to remove the name first.
And needinfo flag can be used to notify people about "please help to have a action on ???"
Assignee: juhsu → nobody

Updated

4 years ago
Flags: needinfo?(juhsu)

Updated

4 years ago
Flags: needinfo?(juhsu)
Hi Junior,

Could you help this issue? Thanks.
Flags: needinfo?(juhsu)
Hi kiwata-san,

I found this similar bug [1].
And it shows that "localhost" is not working but "127.0.0.1" works.

This might be the workaround first.
Could you help to confirm this?

[1] Bug 967792 - Firefox unable to connect to WebSocket on localhost
(Reporter)

Comment 4

4 years ago
Hello Marco-san,

Thank you for your information.
As you indicated, we confirmed that Websocket works OK if we use "127.0.0.1" instead of "localhost".
Let us discuss we should use this workaround or make an effort to fix the root cause.
I asked Toiyama-san to talk about this with you.

Thanks.

Comment 5

4 years ago
I can reproduce for firefox in linux 12.4 (rv.35 release and nightly).

STR:
1. "File"->"Work Offline"
2. connect to localhost by websocket as description

I'll try to figure out what happened.
Flags: needinfo?(juhsu)

Comment 6

4 years ago
In Gecko, if the host is IP literal, it needn't to resolved by DNS.
https://dxr.mozilla.org/mozilla-central/source/netwerk/dns/nsHostResolver.cpp#805
Otherwise, if the system is offline, gecko will not continue for DNS resloving.
https://dxr.mozilla.org/mozilla-central/source/netwerk/dns/nsHostResolver.cpp#827

Therefore, localhost can not be resolved to 127.0.0.1 no matter what protocol is used.
The design is with reference to [1].

(FWIW, sometimes the resolving localhost seems work owing to dns/content cache.)

Hello Patrick,
We have encountered the case that ws://localhost doesn't work in offline mode.
And it seems by design[1].
It's known that it can be workaround the design by using ws://127.0.0.1
However, we're wondering if there's any risk for issueing a local lookup for offline mode.

Thanks.

[1] https://bugzilla.mozilla.org/show_bug.cgi?id=87717#c47
Flags: needinfo?(mcmanus)
(Assignee)

Comment 7

4 years ago
please try setting network.dns.localDomains to be localhost in about:config

(it might be "hidden" and you need to create it.)

If that works, I would accept a patch to set that to be the default value of the pref.
Flags: needinfo?(mcmanus)
(Assignee)

Comment 8

4 years ago
nevermind - that won't work.
(Assignee)

Comment 9

4 years ago
if you're offline, you really can't safely go to the resolver as it might be off the machine. We don't have insight into whether or not that's true for any particular installation.

but I think its safe to just map localhost to 127.0.0.1 _only_ when you're offline.. that means you won't get ipv6 over localhost when offline, but we can probably live with that for now.

Comment 10

4 years ago
Thank you, Patrick.
I put a patch to bug 967792 to make things more public.

Hi kiwata-san,
Could you try the patch in bug 967792, please?
Flags: needinfo?(kiwata.moz)
(Assignee)

Comment 11

4 years ago
Created attachment 8565012 [details] [diff] [review]
make localhost resolve offline
Attachment #8565012 - Flags: review?(dd.mozilla)
(Assignee)

Updated

4 years ago
Assignee: nobody → mcmanus
Status: NEW → ASSIGNED
(Assignee)

Comment 12

4 years ago
I'll move this patch to 967792.

I don't understand why this is not an open bug.
(Assignee)

Updated

4 years ago
Attachment #8565012 - Flags: review?(dd.mozilla)
(Reporter)

Comment 13

4 years ago
Hi Junior-san and Patrick-san,

I'm sorry to check your patch with our environment.
We're still investigating because sometimes it works and sometimes not. This behavior seems to be the same as the situation when we use "127.0.0.1" instead of "localhost". But not sure now.
Please give us some time to clear the condition.

P.S.
Sorry, I opened this bug.

Thanks.
Group: panasonic-confidential

Updated

4 years ago
Status: ASSIGNED → RESOLVED
Last Resolved: 4 years ago
Resolution: --- → DUPLICATE
Duplicate of bug: 967792
(Reporter)

Comment 15

4 years ago
Junior-san,
As we informed to you through Toiyama-san, currently this gecko patch doesn't work with our device in any case.
(Reporter)

Updated

4 years ago
Flags: needinfo?(kiwata.moz)

Comment 16

4 years ago
Hello Iwata-san,

We know sometimes 127.0.0.1 doesn't work offline. 
We guess only if |GetIsLinkUp| returning false and enabling the preference "network.manage-offline-status" would make |Shutdown| in DNSService happened.

Here's something needs your help.

* We still need some log to analysis if our inference is correct or not. We need to know:
 1. Is the DNSService shutdown here?
       https://dxr.mozilla.org/mozilla-central/source/netwerk/base/nsIOService.cpp#961
     And the shutdown force the failure of |AsyncResolve| here?
       https://dxr.mozilla.org/mozilla-central/source/netwerk/dns/nsDNSService2.cpp#758
 2. If yes, what triggered this |SetOffline|? When is the |SetOffline| triggered?

* Could we know the reason to turn on the preference "network.manage-offline-status"?

* Would those hacky ways break your usage such as |navigator.onLine|?
Flags: needinfo?(kiwata.moz)
(Reporter)

Comment 17

4 years ago
Junior-san,

You already reproduced this issue, and fixed in bug1140284, I reply some questions.

> * Could we know the reason to turn on the preference "network.manage-offline-status"?
We need to set offline status to satisfy application specification, therefore we needed to activate this line by enabling "network.manage-offline-status" pref.
https://dxr.mozilla.org/mozilla-central/source/netwerk/base/nsIOService.cpp#1022

> * Would those hacky ways break your usage such as |navigator.onLine|?
Yes I think so. We think online and offline status is impossible for our system.
(Reporter)

Comment 18

4 years ago
Junior-san,

You already reproduced this issue, and fixed in bug1140284, I reply some questions.

> * Could we know the reason to turn on the preference "network.manage-offline-status"?
We need to set offline status to satisfy application specification, therefore we needed to activate this line by enabling "network.manage-offline-status" pref.
https://dxr.mozilla.org/mozilla-central/source/netwerk/base/nsIOService.cpp#1022

> * Would those hacky ways break your usage such as |navigator.onLine|?
Yes I think so. We think online and offline status is impossible for our system.
(Reporter)

Updated

4 years ago
Flags: needinfo?(kiwata.moz)

Comment 19

4 years ago
Fortunately the problem is solved quickly,
and we should appreciate your contribution :)
You need to log in before you can comment on or make changes to this bug.