Closed Bug 811778 Opened 7 years ago Closed 7 years ago

Make sure we only send crashes over wifi and queue them up otherwise for that case

Categories

(Firefox OS Graveyard :: General, defect, P1, critical)

ARM
Gonk (Firefox OS)
defect

Tracking

(blocking-basecamp:+, firefox18 fixed, firefox19 fixed, firefox20 fixed)

RESOLVED FIXED
B2G C2 (20nov-10dec)
blocking-basecamp +
Tracking Status
firefox18 --- fixed
firefox19 --- fixed
firefox20 --- fixed

People

(Reporter: kairo, Assigned: hub)

References

Details

Attachments

(1 file)

The spec (and UI) for B2G crash reporting calls for only sending crash reports over wifi, so we need to be sure that we don't send them via mobile data.
We also should queue them up when we can't send them, and submit once wifi becomes available. I wonder if we also should implement something to limit the length of this queue so people who never get on wifi don't fill up space endlessly.
blocking-basecamp: --- → ?
The queuing is probably already existing btw, as we have the unsent reports in /data/b2g/mozilla/Crash\ Reports/pending/
Implementing the wifi restriction means that there is some set of devices for which we are unlikely to receive any crash reports. (The set of devices that never connect via wifi.)

Chris - Can you please comment on whether we want to restrict crash reports to wifi? Do we have any alternatives to using expensive data connections to transmit this data?
Flags: needinfo?(clee)
Lawrence are you concerned about the dogfooding case or the actual release/distribution case?
(In reply to Lawrence Mandel [:lmandel] from comment #2)
> Implementing the wifi restriction means that there is some set of devices
> for which we are unlikely to receive any crash reports. (The set of devices
> that never connect via wifi.)

Yes, but doing so is already in the specs and UI for crash reporting (i.e. a change of that stance would also needs us to change UI strings at least), because from what I heard we absolutely cannot cause users to have mobile data traffic that they need to pay for.
We are fully aware that this causes a lot of people in Brazil to never send reports to us (AFAIK the same rule exists for telemetry), but causing them unrequested cost for mobile data would be worse.
davidb - actual release.

kairo - Thanks for the additional information. The question that I posed was one from today's triage as we simply do not have the background to make this call without additional information. From comment 4, it sounds like we're going to need to plus this function.

From the description, there are three bugs here:
1. Ensure that B2G doesn't send crash reports via mobile data connection. Do we know that this is a problem?
2. Queue up crash reports to submit in bulk once wifi becomes available.
3. Limit the length of the queue in #2 so that we do not endlessly consume disk space.
Lawrence, that's right. I filed this as only one bug for now because we don't have good QA on the current state, esp. as bug 811341 seems to prevent us from sending crash reports in many cases anyhow.
Also, what I hinted at in comment #1 is that we seem to be already queuing up reports in our current infrastructure, what we don't do of what you mention in #2 is send them once wifi becomes available.
kairo - Do we need QA help here? Should we add qawanted?
Lawrence, we either need devs to tell us if we are sending only over wifi already, or have QA assess that after bug 811341 lands in builds they can test.

I think Hub probably knows the current state without us needing to test.
Currntly it should send over Cell Data as well, even though I can't really verify that. So we need to address that.

When this is actually fixed we can ask help from QA :-)
From Hub's response it sounds like we need to do 1-3 in c5 and from Kairo's description, it sounds like all should block.

Kairo - Can you morph this bug into the issue described in 1 and open bugs for 2 and 3?
Flags: needinfo?(clee)
Assignee: nobody → kairo
Kairo, can we break this up into three bugs and nom those as appropriate?
I have the "send over wifi" part almost working.
(In reply to Hub Figuiere [:hub] from comment #12)
> I have the "send over wifi" part almost working.

Hubert, what's the bug #? can you add this to the dep chain?

Chris Lee, this it bug I couldn't find yesterday - do you want to make a product call here?
If we fix this, we need to make sure that it can be configured through a setting or pref and that the dogfood phones have that setting/pref set to submit over non-wifi as well.
(In reply to JP Rosevear [:jpr] from comment #13)
> (In reply to Hub Figuiere [:hub] from comment #12)
> > I have the "send over wifi" part almost working.
> 
> Hubert, what's the bug #? can you add this to the dep chain?

It is THIS bug right now.

(In reply to Jonas Sicking (:sicking) from comment #14)
> If we fix this, we need to make sure that it can be configured through a
> setting or pref and that the dogfood phones have that setting/pref set to
> submit over non-wifi as well.

FWIW submit over cell data does not work here on the carrier I use for dogfooding. You might want to keep that in mind. See bug 807659
Blocks: 813837
(In reply to Jonas Sicking (:sicking) from comment #14)
> If we fix this, we need to make sure that it can be configured through a
> setting or pref and that the dogfood phones have that setting/pref set to
> submit over non-wifi as well.

I think this creates an additional feature requirement, not sure if that fits into the schedule at this point (as much as I'd like to see it).

(In reply to Hub Figuiere [:hub] from comment #15)
> (In reply to JP Rosevear [:jpr] from comment #13)
> > (In reply to Hub Figuiere [:hub] from comment #12)
> > > I have the "send over wifi" part almost working.
> > 
> > Hubert, what's the bug #? can you add this to the dep chain?
> 
> It is THIS bug right now.

Yes, this should stay the bug for that. I have filed bug 814078 and bug 814086 for the further steps I have mentioned in comment #5.
Assignee: kairo → hub
blocking-basecamp: ? → +
Attachment #684483 - Flags: review?(fabrice)
Bumping severity and assigning to C2 timeline.  We need this data asap and will have our B2G Test Drivers' crash data to help get ahead on crashing bugs before ship.
Severity: normal → critical
Priority: -- → P1
Target Milestone: --- → B2G C2 (20nov-10dec)
Comment on attachment 684483 [details] [diff] [review]
Bug 811778 - Only send crash reports on wifi.

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

r=me with nit addressed.

::: b2g/chrome/content/shell.js
@@ +82,5 @@
>    },
>  
> +  onlineForCrashReport: function shell_onlineForCrashReport() {
> +    var wifiManager = navigator.mozWifiManager;
> +    var onWifi = (wifiManager &&

nit: use |let| instead of |var|
Attachment #684483 - Flags: review?(fabrice) → review+
Comment on attachment 684483 [details] [diff] [review]
Bug 811778 - Only send crash reports on wifi.

[Approval Request Comment]
blocking basecamp. b2g only
Attachment #684483 - Flags: approval-mozilla-beta?
Attachment #684483 - Flags: approval-mozilla-aurora?
Attachment #684483 - Flags: approval-mozilla-beta?
Attachment #684483 - Flags: approval-mozilla-beta+
Attachment #684483 - Flags: approval-mozilla-aurora?
Attachment #684483 - Flags: approval-mozilla-aurora+
https://hg.mozilla.org/mozilla-central/rev/7d18627ba3d2
Status: NEW → RESOLVED
Closed: 7 years ago
Resolution: --- → FIXED
You need to log in before you can comment on or make changes to this bug.