Closed Bug 1119917 Opened 10 years ago Closed 10 years ago

[Windows Management] [Settings] Pulling down the notification menu and tapping the wifi icon (when not previously connected) does not take you to the WiFi settings page when user is located anywhere else in settings.

Categories

(Firefox OS Graveyard :: Gaia::System::Window Mgmt, defect)

ARM
Gonk (Firefox OS)
defect
Not set
normal

Tracking

(blocking-b2g:2.2+, b2g-v2.1 unaffected, b2g-v2.2 verified, b2g-master verified)

VERIFIED FIXED
2.2 S5 (6feb)
blocking-b2g 2.2+
Tracking Status
b2g-v2.1 --- unaffected
b2g-v2.2 --- verified
b2g-master --- verified

People

(Reporter: jmitchell, Assigned: mancas)

Details

(Keywords: regression, Whiteboard: [2.2-Daily-Testing])

Attachments

(2 files)

Description: The normal functionality of the wifi icon on the notification menu is to toggle wifi off and on. If you have not yet connected to a wifi network or previously connected networks are not available then you will be taken to the wifi settings page. This does not occur if you are already anywhere in settings. An example where this might be inconvenient to the user is as follows: Setting up a firefox account you can get several screens deep and have already entered your email before being prompted to enable an Internet connection; the user, in an attempt to not have to undo their progress, might try to access the wifi page in this manner. They would expect to be taken to a subset of the internet connection settings option similar to when trying to connect to a webpage without internet connection. Repro Prerequisite: No internet / data enabled; no internet connection information stored Repro Steps: 1) Update a Flame to 20150109010206 2) Proceed to anywhere in the Settings app (Example: Firefox Accounts) 3) Pull down the notification menu 4) Tap the wifi icon (twice if it is already blue) Actual: Nothing occurs, user is not taken to wifi settings page Expected: User will be taken to the wifi settings page (possibly a nested version so when they back out they will return to their previous location). <OR> there might be some type of indication that selecting the wifi icon from being already in settings somewhere is not a valid option - as it stands - the user will select it with expected functionality that will not occur and it will feel broken. Environmental Variables: Device: Flame Master (KK - Nightly - Full Flashed) Build ID: 20150109010206 Gaia: 5f0dd37917c4a6d8fa8724715d4d3797419f9013 Gecko: b3f84cf78dc2 Gonk: a814b2e2dfdda7140cb3a357617dc4fbb1435e76 Version: 37.0a1 (Master) Firmware Version: V18D User Agent: Mozilla/5.0 (Mobile; rv:37.0) Gecko/37.0 Firefox/37.0 Repro frequency: 6/6 See attached: Logcat --------------------------------------------------------------------------- This issue does NOT reproduce in 2.1 Actual Results: The user is taken to the wifi page from anywhere in other settings pages Device: Flame 2.1 (KK - Nightly - Full Flashed) Build ID: 20150108001214 Gaia: ed2e278753e8c9301ba322dcf2c3591f5928408d Gecko: 127a0ead5f83 Gonk: a814b2e2dfdda7140cb3a357617dc4fbb1435e76 Version: 34.0 (2.1) Firmware Version: V18D User Agent: Mozilla/5.0 (Mobile; rv:34.0) Gecko/34.0 Firefox/34.0
Flags: needinfo?(pbylenga)
QA Whiteboard: [QAnalyst-Triage?]
Functional regression of a core feature. Requesting a window.
blocking-b2g: --- → 2.2?
QA Whiteboard: [QAnalyst-Triage?]
Flags: needinfo?(pbylenga)
QA Contact: pcheng
b2g-inbound regression window: Last Working Environmental Variables: Device: Flame BuildID: 20141020205719 Gaia: e09e1734ad523cf63351a28f6f84454319349fbe Gecko: 4da1f6a151d6 Version: 36.0a1 (2.2 Master) Firmware: V18D-1 User Agent: Mozilla/5.0 (Mobile; rv:36.0) Gecko/36.0 Firefox/36.0 First Broken Environmental Variables: Device: Flame BuildID: 20141020214218 Gaia: ba10744d64411a8a12ae68f7cf1ec3e3ac897d21 Gecko: bcc5df613d83 Version: 36.0a1 (2.2 Master) Firmware: V18D-1 User Agent: Mozilla/5.0 (Mobile; rv:36.0) Gecko/36.0 Firefox/36.0 First Broken Gaia & Last Working Gecko - issue DOES repro Gaia: ba10744d64411a8a12ae68f7cf1ec3e3ac897d21 Gecko: 4da1f6a151d6 First Broken Gecko & Last Working Gaia - issue does NOT repro Gaia: e09e1734ad523cf63351a28f6f84454319349fbe Gecko: bcc5df613d83 Gaia pushlog: https://github.com/mozilla-b2g/gaia/compare/e09e1734ad523cf63351a28f6f84454319349fbe...ba10744d64411a8a12ae68f7cf1ec3e3ac897d21 Caused by Bug 1007600.
QA Whiteboard: [QAnalyst-Triage?]
Flags: needinfo?(ktucker)
Arthur, could you take a look at this please? Looks like the landing to bug 1007600 may have caused this to occur.
QA Whiteboard: [QAnalyst-Triage?] → [QAnalyst-Triage+]
Flags: needinfo?(ktucker) → needinfo?(arthur.chen)
This is the same issue that is happening there: bug 1118669 Settings app is not handling the mozActivities if the app is open.
Triage: regression blocking
Assignee: nobody → arthur.chen
blocking-b2g: 2.2? → 2.2+
The root cause was the activity would not be opened if the app handling the activity is exactly the app currently in foreground [1]. Alive, triggering an activity handled by settings app when settings app is in foreground sounds a valid case to me, any ideas? [1]: https://github.com/mozilla-b2g/gaia/blob/master/apps/system/js/child_window_factory.js#L253
Flags: needinfo?(arthur.chen) → needinfo?(alive)
Hey Arthur, I've been working in bug 1118669. I think we could detect that the app is open and then we should save the current state of the application in order to restore it when the user completes the required task.
Had an offline discussion with Arthur. We will try to use different hash for settings activity at first to resolve this one; I don't look into the bug 1118669 since it's settings only patch; waiting arthur feedback.
Flags: needinfo?(alive)
Attached file Proposed patch
Hey Arthur, I not sure if this is what you talked with Alive. Take a look and let me know if we should change something Thanks!
Attachment #8554476 - Flags: review?(arthur.chen)
Comment on attachment 8554476 [details] [review] Proposed patch This looks good to me. But I'm going to reopen bug 1118669 because after this is fixed, the activity window will be under the system dialog. Let's use bug 1118669 tracking the issue.
Attachment #8554476 - Flags: review?(arthur.chen) → review+
Assignee: arthur.chen → b.mcb
Manuel, could you help rebase to master and run gaia-try again? Thanks.
Flags: needinfo?(b.mcb)
Flags: needinfo?(b.mcb)
Keywords: checkin-needed
Autolander could not locate a review from a user within the suggested reviewer list. Either the patch author or the reviewer should be in the suggested reviewer list.
Keywords: checkin-needed
Autolander could not locate a review from a user within the suggested reviewer list. Either the patch author or the reviewer should be in the suggested reviewer list.
Manuel, the commit message should explain what you did in the patch instead of the bug title. Could you help update it? Since gaia-try has already passed, I'll merge the PR for you once you done the update. Thanks.
Flags: needinfo?(b.mcb)
master: 192295d20cc1ee4ea1cce9920ee9ad4520e8f8ca
Status: NEW → RESOLVED
Closed: 10 years ago
Flags: needinfo?(b.mcb)
Resolution: --- → FIXED
Thanks Arthur!
Comment on attachment 8554476 [details] [review] Proposed patch [Approval Request Comment] [Bug caused by] (feature/regressing bug #): N/A [User impact] if declined: Users are not able to open activities of settings app when settings app is in foreground. This happens when users are using settings app and try to toggle connection settings from the utility tray or the rocket bar. [Testing completed]: Testing on the device. [Risk to taking this patch] (and alternatives if risky): Low as it does not make changes to the code. [String changes made]: None
Attachment #8554476 - Flags: approval-gaia-v2.2?
Attachment #8554476 - Flags: approval-gaia-v2.2? → approval-gaia-v2.2+
This issue is verified fixed on Flame 3.0 and on Flame 2.2. Observed behavior: Without previously connected to internet, tapping on the wifi icon of utility tray while inside a Settings page correctly goes to the Wifi settings page, and user is able to back out to previous page after setting wifi. The flow matches original reporter's first expected behavior. Device: Flame 3.0 (nightly user, full flash, 319MB mem) BuildID: 20150206010204 Gaia: 94af4b42d2ace6c9f38f31de77240604fac68af1 Gecko: 7c5f187b65bf Gonk: e7c90613521145db090dd24147afd5ceb5703190 Version: 38.0a1 (3.0 Master) Firmware Version: v18D-1 User Agent: Mozilla/5.0 (Mobile; rv:38.0) Gecko/38.0 Firefox/38.0 Device: Flame 2.2 (tinderbox eng, full flash, 319MB mem) BuildID: 20150206141725 Gaia: e827781324cbde91d2434b388f5dead3303a85ee Gecko: 0552759956d3 Gonk: e7c90613521145db090dd24147afd5ceb5703190 Version: 37.0a2 (2.2) Firmware Version: v18D-1 User Agent: Mozilla/5.0 (Mobile; rv:37.0) Gecko/37.0 Firefox/37.0
Status: RESOLVED → VERIFIED
QA Whiteboard: [QAnalyst-Triage+] → [QAnalyst-Triage?]
Flags: needinfo?(ktucker)
QA Whiteboard: [QAnalyst-Triage?] → [QAnalyst-Triage+]
Flags: needinfo?(ktucker)
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Created:
Updated:
Size: