Support wifi hotspot status APIs

NEW
Unassigned

Status

Firefox OS
Wifi
4 years ago
9 months ago

People

(Reporter: vchang, Unassigned)

Tracking

(Blocks: 1 bug)

unspecified
ARM
Gonk (Firefox OS)
Dependency tree / graph

Firefox Tracking Flags

(tracking-b2g:backlog)

Details

Attachments

(2 attachments, 3 obsolete attachments)

Currently, we use settings to indicate the enabling or disabling status of wifi hotspot. We need at least below APIs to indicate the status of wifi hotspot to gaia.  

   interface nsIDOMWifiManager : nsISupports
   {
     attribute nsIDOMEventListener onwifitetheringenabled;
     attribute nsIDOMEventListener onwifitetheringdisabled;
   }
(Reporter)

Updated

4 years ago
Blocks: 917097

Comment 1

4 years ago
Hi Vincent,

Any updates?

Updated

4 years ago
Assignee: nobody → kchang

Updated

4 years ago
Assignee: kchang → dlee
Created attachment 829150 [details] [diff] [review]
bug-927298-fix.patch

Updated

4 years ago
Attachment #829150 - Attachment is obsolete: true
Created attachment 829153 [details] [diff] [review]
bug-927298-fix.patch

Updated

4 years ago
Attachment #829153 - Flags: review?(vchang)

Updated

4 years ago
Attachment #829153 - Attachment is obsolete: true
Attachment #829153 - Flags: review?(vchang)

Updated

4 years ago
Depends on: 936367

Updated

4 years ago
Status: NEW → ASSIGNED
(Reporter)

Updated

4 years ago
Blocks: 947174
(Reporter)

Updated

4 years ago
Depends on: 886110

Updated

4 years ago
blocking-b2g: --- → backlog
Created attachment 8479686 [details] [diff] [review]
Part1. wifi hotspot status webidl
Attachment #8479686 - Flags: review?(vchang)
Created attachment 8479687 [details] [diff] [review]
Part2. DOM and WifiWorker implementation
Attachment #8477319 - Attachment is obsolete: true
Attachment #8479687 - Flags: review?(vchang)
Perfect! We finally can have an API to verify the tethering enable/disable result
in the test cases!
(Reporter)

Comment 8

3 years ago
Comment on attachment 8479687 [details] [diff] [review]
Part2. DOM and WifiWorker implementation

Review of attachment 8479687 [details] [diff] [review]:
-----------------------------------------------------------------

::: dom/tethering/TetheringManager.js
@@ +41,3 @@
>      this.initDOMRequestHelper(aWindow, messages);
> +
> +    cpmm.sendSyncMessage("WifiManager:getState");

Do we need this for Tethering?

::: dom/wifi/WifiWorker.js
@@ +3444,5 @@
>      this.setWifiApEnabled(enabled, function() {
>        if ((enabled && WifiManager.tetheringState == "COMPLETED") ||
>            (!enabled && WifiManager.tetheringState == "UNINITIALIZED")) {
>          self._sendMessage(message, true, msg.data, msg);
> +        self._fireEvent("wifitetheringstateupdate", { state: enabled });

Do we still need the APIs? It seems that setTetheringEnabled() API has enough information to react tethering status.
Attachment #8479687 - Flags: review?(vchang)
(Reporter)

Updated

3 years ago
Attachment #8479686 - Flags: review?(vchang)
(In reply to Vincent Chang[:vchang] from comment #8)
> Comment on attachment 8479687 [details] [diff] [review]
> Part2. DOM and WifiWorker implementation
> 
> Review of attachment 8479687 [details] [diff] [review]:
> -----------------------------------------------------------------
> 
> ::: dom/tethering/TetheringManager.js
> @@ +41,3 @@
> >      this.initDOMRequestHelper(aWindow, messages);
> > +
> > +    cpmm.sendSyncMessage("WifiManager:getState");
> 
> Do we need this for Tethering?
> 
In WifiWorker's implementation, getState will register domManager so if there is any event fired from WifiWorker, DOM layer can receive the message. For this patch, the required message is wifitetheringstateupdate.

> ::: dom/wifi/WifiWorker.js
> @@ +3444,5 @@
> >      this.setWifiApEnabled(enabled, function() {
> >        if ((enabled && WifiManager.tetheringState == "COMPLETED") ||
> >            (!enabled && WifiManager.tetheringState == "UNINITIALIZED")) {
> >          self._sendMessage(message, true, msg.data, msg);
> > +        self._fireEvent("wifitetheringstateupdate", { state: enabled });
> 
> Do we still need the APIs? It seems that setTetheringEnabled() API has
> enough information to react tethering status.

If a webpage only interested in knowing tethering state change , he can listen to this event to know if any other webpage change the tethering status by using setTetheringEnabled API.
Hi Vincent,
Could you help check if comment 9 is reasonable. thanks
Flags: needinfo?(vchang)
(Reporter)

Comment 11

3 years ago
(In reply to Dimi Lee[:dimi][:dlee] from comment #9)
> (In reply to Vincent Chang[:vchang] from comment #8)
> > Comment on attachment 8479687 [details] [diff] [review]
> > Part2. DOM and WifiWorker implementation
> > 
> > Review of attachment 8479687 [details] [diff] [review]:
> > -----------------------------------------------------------------
> > 
> > ::: dom/tethering/TetheringManager.js
> > @@ +41,3 @@
> > >      this.initDOMRequestHelper(aWindow, messages);
> > > +
> > > +    cpmm.sendSyncMessage("WifiManager:getState");
> > 
> > Do we need this for Tethering?
> > 
> In WifiWorker's implementation, getState will register domManager so if
> there is any event fired from WifiWorker, DOM layer can receive the message.
> For this patch, the required message is wifitetheringstateupdate.

Yeah, you are right. So we should prevent _fireEvent() sending message to wrong dommanager?   
 
> > ::: dom/wifi/WifiWorker.js
> > @@ +3444,5 @@
> > >      this.setWifiApEnabled(enabled, function() {
> > >        if ((enabled && WifiManager.tetheringState == "COMPLETED") ||
> > >            (!enabled && WifiManager.tetheringState == "UNINITIALIZED")) {
> > >          self._sendMessage(message, true, msg.data, msg);
> > > +        self._fireEvent("wifitetheringstateupdate", { state: enabled });
> > 
> > Do we still need the APIs? It seems that setTetheringEnabled() API has
> > enough information to react tethering status.
> 
> If a webpage only interested in knowing tethering state change , he can
> listen to this event to know if any other webpage change the tethering
> status by using setTetheringEnabled API.

Make sense.
Flags: needinfo?(vchang)
(Assignee)

Updated

3 years ago
blocking-b2g: backlog → ---
tracking-b2g: --- → backlog
Not actively working on this, if anyone is interested in this please feel free to take it.
Assignee: dlee → nobody
Status: ASSIGNED → NEW
You need to log in before you can comment on or make changes to this bug.