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)

ARM
Gonk (Firefox OS)
defect
Not set
normal

Tracking

(blocking-b2g:2.5+, b2g-v2.2 affected, b2g-master fixed)

RESOLVED FIXED
2.2 S13 (29may)
blocking-b2g 2.5+
Tracking Status
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
Attached file logcat.txt
Attached video 1.mp4
[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)
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]
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
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
QA Whiteboard: [QAnalyst-Triage?]
Flags: needinfo?(ktucker)
Keywords: qawanted
QA Whiteboard: [QAnalyst-Triage?] → [QAnalyst-Triage+]
Flags: needinfo?(ktucker)
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 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)
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 on attachment 8610619 [details] [review]
[gaia] daleharvey:1165260-small > mozilla-b2g:master

LGTM!
Attachment #8610619 - Flags: review?(kgrandon) → review+
Status: NEW → RESOLVED
Closed: 9 years ago
Resolution: --- → FIXED
blocking-b2g: 3.0? → 3.0+
Target Milestone: --- → 2.2 S13 (29may)
Attached file logcat_0452.txt
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
Attached video 0452.mp4
Hi William,
  Could you help and confirm it in Comment 12?
Flags: needinfo?(whsu)
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
(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)
(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)
> 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)
See Also: → 1034497
(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.
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.:)
Flags: needinfo?(fdjabri)
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Creator:
Created:
Updated:
Size: