Closed Bug 1020867 Opened 10 years ago Closed 10 years ago

Don't allow user to turn on wifi hotspot when airplane mode is enabled

Categories

(Firefox OS Graveyard :: Gaia::Settings, defect)

ARM
Gonk (Firefox OS)
defect
Not set
normal

Tracking

(blocking-b2g:2.0+, b2g-v2.0 verified, b2g-v2.1 verified)

VERIFIED FIXED
blocking-b2g 2.0+
Tracking Status
b2g-v2.0 --- verified
b2g-v2.1 --- verified

People

(Reporter: vasanth, Assigned: eragonj)

References

Details

(Whiteboard: [caf priority: p2][CR 673099][p=1])

Attachments

(3 files)

Wifi hotspot is disabled when airplane is turned on.
However after Airplane mode on, still able to turn on wifi hotspot and able to connect from other devices.
Agree that even though it is on, we need data connection to do something useful.

Question here is why we allow user to turn on wifi hotspot (softap) when airplane is on?
Whiteboard: [CR 673099] → [caf priority: p2][CR 673099]
blocking-b2g: --- → 1.4?
Ken

Can you please help with a response here?
blocking-b2g: 1.4? → ---
Flags: needinfo?(kchang)
(In reply to Preeti Raghunath(:Preeti) from comment #1)
> Ken
> 
> Can you please help with a response here?

Evenly, this is controlled by Gaia. Maybe, you know the reason.
Flags: needinfo?(kchang) → needinfo?(ehung)
It was per UX design, so we don't lock UI when airplane mode on. However, from bug description, I suppose Gecko will reject this operation because when we are in airplane mode, radio connection is off, and I was told it should perform as sim card absence, so why it's still "be able to connect from other devices"? (maybe I'm misunderstanding on Gecko behavior.)

Another question comes into my mind is: what connections can a user resume manually when the device is in airplane mode? If there is any connection can't be resumed, we should lock the UI.
Flags: needinfo?(ehung) → needinfo?(kchang)
(In reply to Evelyn Hung [:evelyn] from comment #3)
> It was per UX design, so we don't lock UI when airplane mode on. However,
> from bug description, I suppose Gecko will reject this operation because
> when we are in airplane mode, radio connection is off, and I was told it
> should perform as sim card absence, so why it's still "be able to connect
> from other devices"? (maybe I'm misunderstanding on Gecko behavior.)
I wonder if the following function check this in gaia.
https://github.com/mozilla-b2g/gaia/blob/master/apps/system/js/internet_sharing.js#L150

> 
> Another question comes into my mind is: what connections can a user resume
> manually when the device is in airplane mode? If there is any connection
> can't be resumed, we should lock the UI.
It depends on UX. Indeed, we need to define this well.
Flags: needinfo?(kchang)
(In reply to Ken Chang[:ken] from comment #4)
> (In reply to Evelyn Hung [:evelyn] from comment #3)
> > It was per UX design, so we don't lock UI when airplane mode on. However,
> > from bug description, I suppose Gecko will reject this operation because
> > when we are in airplane mode, radio connection is off, and I was told it
> > should perform as sim card absence, so why it's still "be able to connect
> > from other devices"? (maybe I'm misunderstanding on Gecko behavior.)
> I wonder if the following function check this in gaia.
> https://github.com/mozilla-b2g/gaia/blob/master/apps/system/js/
> internet_sharing.js#L150

Yes the code does the check in Gaia to prompt a warning UI, but please note the condition is:
  if ('wifi' === type && 'absent' === cardId && true === evt.settingValue)

where the cardId is a cached result form navigator.mozIccManager. So my question was:
in airplane mode case, will API give us an 'absent' state?
1.4? which got dropped off by accident.
blocking-b2g: --- → 1.4?
Ken

Can you please help us understand next steps?
Flags: needinfo?(kchang)
(In reply to Preeti Raghunath(:Preeti) from comment #7)
> Ken
> 
> Can you please help us understand next steps?
Hi Preeti,
  I don't think this is a blocker. Android has the same scenario and our carrier partner also asks us
to enable wifi ap mode when phone is in flight mode. But UX team should tell us what the exact UX is.

Hi Omega,
  Need your comments.
Flags: needinfo?(kchang) → needinfo?(ofeng)
(In reply to Evelyn Hung [:evelyn] from comment #5)
> where the cardId is a cached result form navigator.mozIccManager. So my
> question was:
> in airplane mode case, will API give us an 'absent' state?
Hmm...I think it depends on platform and requirement. For example, in the other platform, we can/should read phonebooks from SIM when flight mode is on, which means SIM status can not be "absent" when flight mode is on.
Therefore, I wonder if we could directly check the status of setting of flight mode for this case. But let's see what UX team input. Maybe, we don't need to modify anything then..:-)
I tried the master and found that actually the Wi-Fi Hotspot switch will go back to Off if airplane mode is on.
However, we can still add a dialog to inform user the reason just like the solution of bug 946025.
@Jenny, what do you think? :)
Flags: needinfo?(ofeng) → needinfo?(jelee)
Agree with Omega. It'd be nice if we add a dialogue box saying:
-----------------------------
Airplane mode activated (Title)
Turn off airplane mode to use Wi-Fi hotspot. (detail description)
[ok]
-----------------------------
when user tries to turn on Wi-Fi hotspot with airplane mode on.
Flags: needinfo?(jelee)
Backlog for now as this seems to be a new feature for 1.4
blocking-b2g: 1.4? → backlog
Can we try to fix it in 2.0
blocking-b2g: backlog → 2.0?
Vincent, Let's see what is happened in 1.4 branch. The scenario is different from Master, according to comment 10. Thanks
Flags: needinfo?(vchang)
The hotspot function itself in gecko doesn't know anything about airplane mode or status of SIM... What it cares about is existence of physical network interfaces and its interface name, such as rmnet0, wifi0 ... If there is not a active interface at the time user turn on the hotspot. It uses the default interface name. The default name is updated once upstream interface is changed. The behavior is consistence between different branches.
Flags: needinfo?(vchang)
Hi Arthur, can you help on string change based on UX comment 11 ? Please investigate if it can be completed before June 20, thank you.
Flags: needinfo?(arthur.chen)
Assign to EJ for Gaia dialogue, ni UX for the style.
Assignee: nobody → ejchen
Flags: needinfo?(ofeng)
Flags: needinfo?(jelee)
Flags: needinfo?(arthur.chen)
Attached image sample.png (deleted) —
Hello Howie, please refer to the attachment for current UI style. Tks!
Flags: needinfo?(ofeng)
Flags: needinfo?(jelee)
Attached file patch on master (deleted) —
Hi Alive, 

I added one more dialog for this ux change in internet_sharing (tests are included !) Can you help me review them ? THanks :]
Attachment #8441835 - Flags: review?(alive)
Whiteboard: [caf priority: p2][CR 673099] → [caf priority: p2][CR 673099][p=1]
BTW, after offline discussions with Jenny, we will use system default dialog instead of the one from sms app.
Attachment #8441835 - Flags: review?(alive) → review+
blocking-b2g: 2.0? → 2.0+
THanks all, I just merged them into

Gaia/master: 9f19c22447af4abbd0d8e2ca881f9664861c4dc7
Gaia/v2.0: 0eb22a1d4ce276fc7f3cbd0e785cc6f5902147e5

Thanks
Status: NEW → RESOLVED
Closed: 10 years ago
Resolution: --- → FIXED
Depends on: 1028101
Flags: in-moztrap?(bzumwalt)
New test case needs to be written.
QA Whiteboard: [QAnalyst-Triage?]
Flags: needinfo?(ktucker)
Test case has been added to moztrap:

https://moztrap.mozilla.org/manage/case/14278/
QA Whiteboard: [QAnalyst-Triage?] → [QAnalyst-Triage+]
Flags: needinfo?(ktucker)
Flags: in-moztrap?(bzumwalt)
Flags: in-moztrap+
Attached video Verify_Video_Flame.MP4 (deleted) —
This issue has been verified successfully on Flame 2.0 & 2.1.
See attachment: Verify_Video_Flame.MP4
Reproducing rate: 0/10

Flame v2.0 version:
Gaia-Rev        8d1e868864c8a8f1e037685f0656d1da70d08c06
Gecko-Rev       https://hg.mozilla.org/releases/mozilla-b2g32_v2_0/rev/ff1100ba2ab8
Build-ID        20141204000228
Version         32.0

Flame v2.1 version:
Gaia-Rev        5655269098c7e82254e56933f1af05b4abe2a2f3
Gecko-Rev       https://hg.mozilla.org/releases/mozilla-b2g34_v2_1/rev/86608c9389b5
Build-ID        20141204001201
Version         34.0
Status: RESOLVED → VERIFIED
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Creator:
Created:
Updated:
Size: