727680 - Wifi worker can't connect to networks that don't broadcast their SSID

Status: RESOLVED FIXED

(Core :: DOM: Device Interfaces, defect)

Description

[Chris Jones [:cjones] inactive; ni?/f?/r? if you need me]

Blake has a patch that works but needs a bit of cleanup.

Comment 1

[Blake Kaplan (:mrbkap) (inactive)]

Attachment: Make networks objects

This is mostly cleanup (and some preparation for the eventual API) but it's nice to have real objects so we can say "net.flags" instead of "net[1]".

Comment 2

[Blake Kaplan (:mrbkap) (inactive)]

Attachment: Wait to connect until we have scan results

This is what was missing last night: we don't want to force anything until we know that the network doesn't actually exist.

Comment 3

[Blake Kaplan (:mrbkap) (inactive)]

Attachment: Force a connection to Mozilla Guest

This is basically the patch from last night, but a little cleaned up.

Comment 4

[Blake Kaplan (:mrbkap) (inactive)]

Attachment: Fix another race

It turns out the INACTIVE notification races with the scan results. This is a diff -w.

Comment 5

[Chris Jones [:cjones] inactive; ni?/f?/r? if you need me]

Comment on attachment 597797 [details] [diff] [review]
Make networks objects

>diff --git a/dom/wifi/nsIWifi.idl b/dom/wifi/nsIWifi.idl

>+[scriptable, uuid(14c815f0-e9db-41d4-a15e-f3e69140f83b)]
>+interface nsIWifiNetwork : nsISupports {
>+    readonly attribute DOMString ssid; // can be null
>+    readonly attribute DOMString bssid; // can be null
>+    readonly attribute DOMString flags; // TODO make this be real flags instead of a string
>+    readonly attribute long signal;
>+};
>+

Do these need to be exposed through XPCOM?  It doesn't seem to be used
in your patches.  Is there another reason for doing this?

r=me pending xpcom question

Comment 6

[Chris Jones [:cjones] inactive; ni?/f?/r? if you need me]

Comment on attachment 597802 [details] [diff] [review]
Force a connection to Mozilla Guest

>diff --git a/dom/wifi/nsWifiWorker.js b/dom/wifi/nsWifiWorker.js
>index e1d48d2..be83da2 100644

>+      var config = Object.create(null);

let?

Comment 7

[Blake Kaplan (:mrbkap) (inactive)]

(In reply to Chris Jones [:cjones] [:warhammer] from comment #5)
> Do these need to be exposed through XPCOM?  It doesn't seem to be used
> in your patches.  Is there another reason for doing this?

It's not used yet. However, when we want to expose Wifi state in order to write, e.g. the UI for selecting a network, we're going to need information like this in the DOM, which means exposing it through XPCOM.

Comment 8

[Blake Kaplan (:mrbkap) (inactive)]

(In reply to Chris Jones [:cjones] [:warhammer] from comment #6)
> >+      var config = Object.create(null);
> 
> let?

let at the top level is equivalent to var (in the parser, we actually change the token) and given that I've used var basically everywhere else in the file, I'd prefer to keep this as-is.

Comment 9

[Blake Kaplan (:mrbkap) (inactive)]

Comment on attachment 597797 [details] [diff] [review]
Make networks objects

https://hg.mozilla.org/integration/mozilla-inbound/rev/c9f5f7c81b48

Comment 10

[Blake Kaplan (:mrbkap) (inactive)]

Comment on attachment 597800 [details] [diff] [review]
Wait to connect until we have scan results

https://hg.mozilla.org/integration/mozilla-inbound/rev/337bf2beee17

Comment 11

[Blake Kaplan (:mrbkap) (inactive)]

Comment on attachment 597802 [details] [diff] [review]
Force a connection to Mozilla Guest

https://hg.mozilla.org/integration/mozilla-inbound/rev/a93f5dd0dd57

Comment 12

[Blake Kaplan (:mrbkap) (inactive)]

Comment on attachment 597903 [details] [diff] [review]
Fix another race

https://hg.mozilla.org/integration/mozilla-inbound/rev/7d8ae4b53ead

Comment 13

[Ed Morley [:emorley]]

https://hg.mozilla.org/mozilla-central/rev/c9f5f7c81b48
https://hg.mozilla.org/mozilla-central/rev/337bf2beee17
https://hg.mozilla.org/mozilla-central/rev/a93f5dd0dd57
https://hg.mozilla.org/mozilla-central/rev/7d8ae4b53ead