Closed
Bug 1165260
Opened 9 years ago
Closed 9 years ago
[Search] Connect a captive portal wifi without account&PWD, then search some words using search bar on homescreen, it will be always loading.
Categories
(Firefox OS Graveyard :: Gaia::Search, defect)
Tracking
(blocking-b2g:2.5+, b2g-v2.2 affected, b2g-master fixed)
People
(Reporter: zikui.yang, Assigned: daleharvey)
References
Details
(Whiteboard: [systemsfe])
Attachments
(5 files)
[1.Description]: [Homescreen]Search something in search box under the captive portal wifi without account&pwd, it should not be loading, and should prompt some messages. Attachment: logcat.txt & 1.mp4 Found at: 18:08~18:15 [2.Testing Steps]: 1. Connect a captive portal wifi, but don't input account&pwd. 2. On home screen, tap search box 3. Input some words. 4. Wait 2~3 minutes [3.Expected Result]: 4. It should prompt some messages. [4.Actual Result]: 4. No pop-up prompt message, and it will always be loading. [5.Reproduction build]: Flame 2.2 version(Affected): Build ID 20150514002501 Gaia Revision aac58a063e3e6acae6ba77fe4cec224fb69450bc Gaia Date 2015-05-13 12:59:48 Gecko Revision https://hg.mozilla.org/releases/mozilla-b2g37_v2_2/rev/47f1ced9f1d6 Gecko Version 37.0 Device Name flame Firmware(Release) 4.4.2 Firmware(Incremental) eng.cltbld.20150514.040500 Firmware Date Thu May 14 04:05:11 EDT 2015 Bootloader L1TC000118D0 Flame 3.0(Affected) Build ID 20150514131323 Gaia Revision 338f66e6a96491d2f5854b188c6b141ceb690d97 Gaia Date 2015-05-13 14:08:45 Gecko Revision https://hg.mozilla.org/mozilla-central/rev/633684c4ebc4 Gecko Version 41.0a1 Device Name flame Firmware(Release) 4.4.2 Firmware(Incremental) eng.cltbld.20150514.165247 Firmware Date Thu May 14 16:53:00 EDT 2015 Bootloader L1TC000118D0 [6.Reproduction Frequency]: Always Recurrence,5/5 [7.TCID]: Free Test
status-b2g-v2.2:
--- → affected
status-b2g-master:
--- → affected
Comment 3•9 years ago
|
||
[Blocking Requested - why for this release]: In this test, user connects to a hotspot network without input any account & password, but this issue identifies that there is not timeout mechanism to tell user the network condition is bad. I think we need developer and UX input here.
blocking-b2g: --- → 3.0?
Flags: needinfo?(fdjabri)
Flags: needinfo?(dale)
Updated•9 years ago
|
Summary: [Homescreen]Connect a captive portal wifi without account&PWD, then search some words using search bar on homescreen, it will be always loading. → [Search] Connect a captive portal wifi without account&PWD, then search some words using search bar on homescreen, it will be always loading.
Whiteboard: [systemsfe]
Comment 4•9 years ago
|
||
We need a global strategy with captive portals. Whats the behavior when we open the browser or check emails? Do we have a notification in the utility tray? QA: Under what circumstances do we get the login-page and when don't we see it?
Keywords: qawanted
Comment 5•9 years ago
|
||
The user is immediately given a notification in utility tray when they connect to a captive portal wifi (as shown in the video). If they ignore that notification and continue to: - Tap on a website in browser that they've visited before - an error message about unable to connect is given on browser; no notification. - Open email app and try to open an email - no error message, no notification - Attempting to use the Rocketbar (showcased in video) - no error message, no notification - Actually executing a search on Rocketbar - see first bullet's result - Attempting to use smart collection - error message, no notification The only instance that I saw where a notification is given is when they first connect to that wifi network, so disabling wifi and re-enabling it prompts the notification to re-appear. Device: Flame (KK, full flashed, 319MB) BuildID: 20150520010202 Gaia: 600fd8249960b8256af9de67d9171025bb9a3ff3 Gecko: ac277e615f8f Gonk: 040bb1e9ac8a5b6dd756fdd696aa37a8868b5c67 Version: 41.0a1 (3.0 Master) Firmware Version: v18D-1 User Agent: Mozilla/5.0 (Mobile; rv:41.0) Gecko/41.0 Firefox/41.0
Updated•9 years ago
|
QA Whiteboard: [QAnalyst-Triage?] → [QAnalyst-Triage+]
Flags: needinfo?(ktucker)
Assignee | ||
Comment 6•9 years ago
|
||
We should likely show the offline notification when requests fail, will leave needinfo on Francis to double check but will take
Assignee: nobody → dale
Flags: needinfo?(dale)
Comment 7•9 years ago
|
||
Assignee | ||
Comment 8•9 years ago
|
||
Comment on attachment 8610619 [details] [review] [gaia] daleharvey:1165260-small > mozilla-b2g:master This prevents the spinner from showing once requests have failed
Attachment #8610619 -
Flags: review?(kgrandon)
Assignee | ||
Comment 9•9 years ago
|
||
Showing the offline notification is problematic, we dont know whether we are offline or certain requests re just failing etc. We can definitely do something but it requires a bit more thought, this patch to get rid of the loading spinner is an obvious first fix though
Comment 10•9 years ago
|
||
Comment on attachment 8610619 [details] [review] [gaia] daleharvey:1165260-small > mozilla-b2g:master LGTM!
Attachment #8610619 -
Flags: review?(kgrandon) → review+
Updated•9 years ago
|
Keywords: checkin-needed
Updated•9 years ago
|
Keywords: checkin-needed
Comment 11•9 years ago
|
||
Pull request has landed in master: https://github.com/mozilla-b2g/gaia/commit/291f018825d8745a77ccfff78f384c9dc711f7fe
Updated•9 years ago
|
Status: NEW → RESOLVED
Closed: 9 years ago
Resolution: --- → FIXED
Updated•9 years ago
|
blocking-b2g: 3.0? → 3.0+
Updated•9 years ago
|
Target Milestone: --- → 2.2 S13 (29may)
Comment 12•9 years ago
|
||
This bug has been verified as fail on latest build of Flame v3.0 by the STR in Comment 0. Actual results: When you connect a captive portal wifi but don't input account&pwd, there is no pop-up prompt message and it will always be loading in Rocketbar. See attachments: logcat_0452.txt and 0452.MP4 Occur Recurrence: 5/5 Device: Flame v3.0 build(Fail) Build ID 20150528160205 Gaia Revision e7d268074ee3c9eeb191c2205c0e35992fb3915d Gaia Date 2015-05-28 10:47:28 Gecko Revision https://hg.mozilla.org/mozilla-central/rev/f986e55c4e0b Gecko Version 41.0a1 Device Name flame Firmware(Release) 4.4.2 Firmware(Incremental) eng.cltbld.20150528.192335 Firmware Date Thu May 28 19:23:44 EDT 2015 Bootloader L1TC000118D0 Build ID 20150528160205 Gaia Revision e7d268074ee3c9eeb191c2205c0e35992fb3915d Gaia Date 2015-05-28 10:47:28 Gecko Revision https://hg.mozilla.org/mozilla-central/rev/f986e55c4e0b Gecko Version 41.0a1 Device Name flame Firmware(Release) 4.4.2 Firmware(Incremental) eng.cltbld.20150528.192335 Firmware Date Thu May 28 19:23:44 EDT 2015 Bootloader L1TC000118D0
Comment 13•9 years ago
|
||
Comment 14•9 years ago
|
||
Hi William, Could you help and confirm it in Comment 12?
Flags: needinfo?(whsu)
Updated•9 years ago
|
Updated•9 years ago
|
Flags: needinfo?(hcheng)
Attachment #8612723 -
Attachment is obsolete: true
Attachment #8612723 -
Attachment is obsolete: false
Attachment #8612723 -
Attachment is obsolete: true
Attachment #8612719 -
Attachment is obsolete: true
Attachment #8612719 -
Attachment is obsolete: false
Attachment #8612723 -
Attachment is obsolete: false
Comment 15•9 years ago
|
||
(In reply to Dale Harvey (:daleharvey) from comment #9) > Showing the offline notification is problematic, we dont know whether we are > offline or certain requests re just failing etc. We can definitely do > something but it requires a bit more thought, this patch to get rid of the > loading spinner is an obvious first fix though Hi Dale, do you know the timeout setting of the XMLHttpRequest? In comment 12, it still kept loading about 2 mins.
Flags: needinfo?(hcheng) → needinfo?(dale)
Comment 16•9 years ago
|
||
(In reply to Dale Harvey (:daleharvey) from comment #8) > Comment on attachment 8610619 [details] [review] > [gaia] daleharvey:1165260-small > mozilla-b2g:master > > This prevents the spinner from showing once requests have failed Thanks for the help. But, I cannot see the effect (comment 13) after patch landed on master. Did I misunderstand anything?
Flags: needinfo?(whsu)
Assignee | ||
Comment 17•9 years ago
|
||
> Thanks for the help. > But, I cannot see the effect (comment 13) after patch landed on master. > Did I misunderstand anything? The spinner may show for a long time, we only hide it once the request fails. I think this make take minutes in the situation where you are connected but not authenticated against a captive portal but in that situation we cant really know if a request is slow or never going to fail until it does. Not sure there is much more we can do here.
Flags: needinfo?(dale)
Comment 18•9 years ago
|
||
(In reply to Dale Harvey (:daleharvey) from comment #17) > > Thanks for the help. > > > But, I cannot see the effect (comment 13) after patch landed on master. > > Did I misunderstand anything? > > The spinner may show for a long time, we only hide it once the request > fails. I think this make take minutes in the situation where you are > connected but not authenticated against a captive portal but in that > situation we cant really know if a request is slow or never going to fail > until it does. Not sure there is much more we can do here. Thank you Dale. :) It seemed to be a known issue. Cheers.
Comment 19•9 years ago
|
||
Perhaps, the following events can help us identify network status and address this issue. FYI. - https://dxr.mozilla.org/mozilla-central/source/b2g/chrome/content/shell.js#910 Thank you.:)
Updated•9 years ago
|
status-b2g-v2.5:
--- → fixed
Updated•9 years ago
|
status-b2g-v2.5:
fixed → ---
Updated•8 years ago
|
Flags: needinfo?(fdjabri)
You need to log in
before you can comment on or make changes to this bug.
Description
•