182 bytes, text/html
User Agent: Mozilla/4.0 (compatible; MSIE 8.0; Windows NT 6.1; Trident/4.0; GTB7.5; CNS_UA; AD_LOGON=4C47452E4E4554; SLCC2; .NET CLR 2.0.50727; .NET CLR 3.5.30729; .NET CLR 3.0.30729; Media Center PC 6.0; .NET4.0C; Tablet PC 2.0; InfoPath.3; .NET4.0E; CNS_UA; AD_LOGON=4C47452E4E4554) Steps to reproduce: 1. At first boot, noti bar's wifi quick setting menu select for context menu 2. Wifi activity is searching ap lists and then select some ap with password 3. On wifi auth dialog, press back button Actual results: In this case, back button is not working or if it is working, it is not working to do in second time When back button is not working, ok button is also not working. Expected results: dialog should be closed
[Blocking Requested - why for this release]:
Looks like a settings app issue, switch the component to settings.
This issue is just occured in Wi-Fi Setting case by Quick settings menu. If entering directly to settings menu, normaly do.
QA Wanted to see if we can reproduce this on Flame.
I was able to repro this bug on Flame 2.0. Here are the repro steps: 1. Flash a Flame device with latest 2.0 2. During FTU, Ignore the wifi menu and finish the FTU. 3. Pull down the notification menu. 4. Tap the Wifi icon twice to turn it off and back on. 5. When the Wifi list appears, tap on a secure Wifi spot. 6. Tap the back button. Actual results: Back button is not functioning when accessing a wifi authentication screen through the Wifi button in the Notification window. Repro Rate: 5/5 Environmental Variables: Device: Flame 2.0 BuildID: 20140819175131 Gaia: 88db39a0826086024631049d83ae6aa397f0918d Gecko: 2092ac87eceb Version: 32.0 (2.0) Firmware Version: v123 ------------------------------------------------ ------------------------------------------------ This bug does NOT repro on: Flame 2.1, Flame 1.4 Actual Result: Back button for the Wifi authentication screen functions correctly. Repro Rate: 0/5 attempts Environmental Variables: Device: Flame Master BuildID: 20140819225026 Gaia: df39c463259d348396ef7f143c2c780eeb8f02d8 Gecko: ffdd1a398105 Version: 34.0a1 (Master) Firmware Version: v123 --------------------------------------------------- Environmental Variables: Device: Flame 1.4 BuildID: 20140818062816 Gaia: 21bec64497dc06a7f12071d573570ba8fea598ae Gecko: 07d78d0f9bef Version: 30.0 (1.4) Firmware Version: v123
This issue occurs on earliest b2g-32 branch build ID 20140718120320, and also occurs on earliest 2.0 Aurora branch build ID 20140609144129 - meaning that the whole 2.0 branch is affected with this bug. We attempted a reverse-regression window in Central to find out what fixed the issue, but the broken build's behavior is different than this original bug. Bug 1050402 describes the issue, where options in Settings cannot be accessed when Settings is invoked by another app (in other words can't execute Step 5 of Comment 5). Perhaps the fix for bug 1050402 could somehow also fix this bug but we're not sure. We then went further back in Central (before central branched into 2.0 Aurora), attempting to find the actual window where there's a last working and first broken with behaviors matching this bug, with no avail. In between last working and first broken, there is a bug lasting several weeks that a user cannot turn on Wifi in Settings if Wifi is invoked via notification bar. (another way of can't execute Step 5 of Comment 5) Therefore we decided a regression window is not possible in this situation.
QA Wanted for a video.
(In reply to Jason Smith [:jsmith] from comment #7) > QA Wanted for a video. Video demonstrating steps 3 to 6 of Comment 5's STR. Steps 1 & 2 were done without filming. http://youtu.be/URLj2Vs2MC8 Tested on: Device: Flame BuildID: 20140820203614 Gaia: 60cedd4aa6ba408174bcd20a7bf774e73f927674 Gecko: 45eca5871dd0 Version: 32.0 (2.0) Firmware: V123 User Agent: Mozilla/5.0 (Mobile; rv:32.0) Gecko/32.0 Firefox/32.0
Triage: blocking, but Arthur said it should be already fixed in 2.0. Assign to him to find the dup/patch for uplift.
(In reply to Tim Guan-tin Chien [:timdream] (MoCo-TPE) (please ni?) from comment #9) > Triage: blocking, but Arthur said it should be already fixed in 2.0. Assign > to him to find the dup/patch for uplift. Assigning and NI Arthur chen for above, please re-assign if needed.
The patches of bug 1052557 and bug 1054140 solve the problem. I would suggest to uplift the patches.
Arthur, please set approval flags on these bugs. Thanks!
They have been approved, thanks for reminding.
I tried to do by the patches, but also didn't work. Do you have the other patches?
I missed one patch. Could you try applying the patch of bug 1050402?
Created attachment 8480305 [details] link to https://github.com/mozilla-b2g/gaia/pull/23393 EJ, the patch is the same as the one in bug 1050402 but we need a separate patch here per https://bugzilla.mozilla.org/show_bug.cgi?id=1050402#c12. Would you mind check it? Thanks.
Comment on attachment 8480305 [details] link to https://github.com/mozilla-b2g/gaia/pull/23393 OK thanks Arthur ! r+
There are a lot of files on comments. I thinks the patches as page_transitions.js, settings_service.js. I verified to do by this patch. But On Quick setting > Wi-Fi menu, Settings main screen display and then w-fi settings display. It takes long time. Could you improve the time issue?
By this patches, back button is alived. But I found the other. When wi-fi window creats by Quick setting, if back button press, setting window closed. and then as setting menu, Wi-Fi window is focused.(not setting main window). In addition, through the window, if I tried to active tethering, tethering's dialog don't work ok button. repo step Quick setting -> wifi window -> back button setting menu -> back button to setting's main screen -> Internet sharing -> Wi-Fi hotspot on -> tethering dialog ok click
Still waiting for the result of gaia try: https://tbpl.mozilla.org/?rev=252f711bbf34ba1dc30e495dfc37fd67ff4f683d&tree=Gaia-Try Kim, could you file another bug tracking the issues you mentioned in the comments? Thanks.
Comment on attachment 8480305 [details] link to https://github.com/mozilla-b2g/gaia/pull/23393 NOTE: Please see https://wiki.mozilla.org/Release_Management/B2G_Landing to better understand the B2G approval process and landings. [Approval Request Comment] [Bug caused by] (feature/regressing bug #): N/A [User impact] if declined: Users are not able to navigate back to the previous panel. [Testing completed]: Yes [Risk to taking this patch] (and alternatives if risky): Low [String changes made]: N/A
I register hotspot ok button issue as the other issue. https://bugzilla.mozilla.org/show_bug.cgi?id=1062090 thanks
I think this bug was wrongly set as Invalid so I reopen it, we had tested flame v2.0 Gecko-be914f0.Gaia-449d8db And the back option is not working yet. Please land it in 2.0.
Comment on attachment 8480305 [details] link to https://github.com/mozilla-b2g/gaia/pull/23393 QA, please verify on 2.0 branch once this lands.
I have tested it and the back button works properly. When i have selected a ap with password, then is open a wifi auth dialog and pressing back button i can close it and return to the apn list. I have tested using flame 2.1 , Gecko f816f7e Gaia c7b55ed.
Also i tested it with flame 2.0 (Gecko fa59560, Gaia 59a670d) and the back button works properly too.
Thanks everyone. Verified it. * Build Information: - Gaia 7edd3b0b9f65c3dde235c732d270e43e055a1254 - Gecko https://hg.mozilla.org/releases/mozilla-b2g32_v2_0/rev/13e04ab68621 - BuildID 20140914162307 - Version 32.0 - Base image Flame KK - ro.build.version.incremental=27 - ro.build.date=Thu Sep 4 14:59:02 CST 2014