1131006 - [Stingray] Cannot open websocket with offline

Status: RESOLVED DUPLICATE of bug 967792

(Firefox OS Graveyard :: Gaia::TV::System, defect)

Description

[kiwata.moz]

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.

Comment 1

[Marco Chen [:mchen]]

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 ???"

Comment 2

[Marco Chen [:mchen]]

Hi Junior,

Could you help this issue? Thanks.

Comment 3

[Marco Chen [:mchen]]

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

Comment 4

[kiwata.moz]

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

[Junior [inactive]]

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.

Comment 6

[Junior [inactive]]

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

Comment 7

[Patrick McManus [:mcmanus]]

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.

Comment 8

[Patrick McManus [:mcmanus]]

nevermind - that won't work.

Comment 9

[Patrick McManus [:mcmanus]]

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

[Junior [inactive]]

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?

Comment 11

[Patrick McManus [:mcmanus]]

Attachment: make localhost resolve offline

Comment 12

[Patrick McManus [:mcmanus]]

I'll move this patch to 967792.

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

Comment 13

[kiwata.moz]

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.

Comment 15

[kiwata.moz]

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

Comment 16

[Junior [inactive]]

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|?

Comment 17

[kiwata.moz]

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.

Comment 18

[kiwata.moz]

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.

Comment 19

[Junior [inactive]]

Fortunately the problem is solved quickly,
and we should appreciate your contribution :)