Wifi: Report when a scan attempt fails.

RESOLVED FIXED

Status

()

defect
P1
normal
RESOLVED FIXED
7 years ago
7 years ago

People

(Reporter: mrbkap, Assigned: mrbkap)

Tracking

unspecified
ARM
Android
Points:
---
Dependency tree / graph

Firefox Tracking Flags

(blocking-kilimanjaro:+, blocking-basecamp:+)

Details

Attachments

(2 attachments)

Right now, if scanning fails (e.g. because the user requested a scan while we were associating) the wifi manager doesn't inform the DOM that the scan request didn't work, leading to a situation where we're waiting for a scan that wasn't scheduled. We could reschedule the scan request in the backend, but kaze said that he'd prefer doing so in the frontend, which makes sense to me.
Posted patch FixSplinter Review
Attachment #656004 - Flags: review?(vchang)
Oops, there were a couple of dumb bugs in the previous patch.
Attachment #656162 - Flags: review?(vchang)
Comment on attachment 656162 [details] [diff] [review]
Additonal fixes on otp of attachment 656004 [details] [diff] [review]

Review of attachment 656162 [details] [diff] [review]:
-----------------------------------------------------------------

It looks really good.
Attachment #656162 - Flags: review?(vchang) → review+
Attachment #656004 - Flags: review?(vchang) → review+
Actually, wpa_supplicant is totally broken -- it doesn't respond at all to scan requests.
Resolution: FIXED → INVALID
Oops, so, wpa_supplicant isn't totally broken, the old version was, but we don't use it anymore. I was seeing a gaia bug.
Status: RESOLVED → REOPENED
Resolution: INVALID → ---
https://hg.mozilla.org/mozilla-central/rev/b6a1295da486
Status: REOPENED → RESOLVED
Closed: 7 years ago7 years ago
Resolution: --- → FIXED
You need to log in before you can comment on or make changes to this bug.