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

RESOLVED FIXED in mozilla13

Status

()

RESOLVED FIXED
7 years ago
7 years ago

People

(Reporter: cjones, Assigned: mrbkap)

Tracking

Trunk
mozilla13
ARM
Gonk (Firefox OS)
Points:
---

Firefox Tracking Flags

(Not tracked)

Details

Attachments

(4 attachments)

Blake has a patch that works but needs a bit of cleanup.
Created attachment 597797 [details] [diff] [review]
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]".
Assignee: nobody → mrbkap
Status: NEW → ASSIGNED
Attachment #597797 - Flags: review?(jones.chris.g)
Created attachment 597800 [details] [diff] [review]
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.
Attachment #597800 - Flags: review?(jones.chris.g)
Created attachment 597802 [details] [diff] [review]
Force a connection to Mozilla Guest

This is basically the patch from last night, but a little cleaned up.
Attachment #597802 - Flags: review?(jones.chris.g)
Created attachment 597903 [details] [diff] [review]
Fix another race

It turns out the INACTIVE notification races with the scan results. This is a diff -w.
Attachment #597903 - Flags: review?(jones.chris.g)
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
Attachment #597797 - Flags: review?(jones.chris.g) → review+
Attachment #597800 - Flags: review?(jones.chris.g) → review+
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?
Attachment #597802 - Flags: review?(jones.chris.g) → review+
Attachment #597903 - Flags: review?(jones.chris.g) → review+
(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.
(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.
You need to log in before you can comment on or make changes to this bug.