Last Comment Bug 791380 - Need on-phone equivalent of about:crashes
: Need on-phone equivalent of about:crashes
Status: RESOLVED FIXED
[LOE:S]
:
Product: Firefox OS
Classification: Client Software
Component: General (show other bugs)
: unspecified
: All All
: P4 normal (vote)
: B2G C2 (20nov-10dec)
Assigned To: [:fabrice] Fabrice Desré
:
Mentors:
: 801934 (view as bug list)
Depends on: 908896
Blocks: b2g-crash-reporting
  Show dependency treegraph
 
Reported: 2012-09-14 14:39 PDT by Alex Keybl [:akeybl]
Modified: 2013-09-16 07:08 PDT (History)
38 users (show)
See Also:
Crash Signature:
(edit)
QA Whiteboard:
Iteration: ---
Points: ---
koi+
-
fixed


Attachments
wip (4.01 KB, patch)
2012-11-07 23:05 PST, [:fabrice] Fabrice Desré
no flags Details | Diff | Splinter Review
screenshot: New "Data Crash" button in the "Improve Firefox" panel (47.59 KB, image/png)
2012-11-07 23:06 PST, [:fabrice] Fabrice Desré
no flags Details
screenshot: Submitted crash list (51.88 KB, image/png)
2012-11-07 23:07 PST, [:fabrice] Fabrice Desré
no flags Details
Remoting about:crashes from the device to firefox desktop (117.65 KB, image/png)
2012-11-28 09:58 PST, [:fabrice] Fabrice Desré
no flags Details
patch (6.26 KB, patch)
2013-08-22 15:08 PDT, [:fabrice] Fabrice Desré
dhylands: review+
Details | Diff | Splinter Review
application.zip (33.31 KB, application/zip)
2013-08-22 15:10 PDT, [:fabrice] Fabrice Desré
no flags Details

Description Alex Keybl [:akeybl] 2012-09-14 14:39:05 PDT
We need the on-phone equivalent of about:crashes so that users can file bugs against specific crashes, especially those that don't have obvious STR.

The use of logcat will not work for dogfood/external users.
Comment 1 Robert Kaiser 2012-09-15 05:26:42 PDT
So, I think that about:crashes actually exists in toolkit on the device, but calling it up in the browser causes a security error (as I found by looking at logcat):
E/GeckoConsole(  423): Security Error: Content at app://browser.thisdomaindoesnotexist.org/index.html may not load or link to about:crashes.

If the browser would be able to call up about pages that have chrome privs (like this one), I guess that would be helpful for multiple things in terms of support and dev features like that - and we could make responsible designs of them in the usual toolkit place.
Comment 2 Andrew Overholt [:overholt] (back Aug 31) 2012-09-17 10:18:44 PDT
Ben, can you take a look at what platform support is needed here?  Thanks.
Comment 3 Jason Smith [:jsmith] 2012-09-24 08:43:39 PDT
Re-noming - Gaia triage says this does not block since the crash reports seen automatically on the phone is already sufficient for dogfooding.
Comment 4 Alex Keybl [:akeybl] 2012-09-24 12:06:08 PDT
(In reply to Jason Smith [:jsmith] from comment #3)
> Re-noming - Gaia triage says this does not block since the crash reports
> seen automatically on the phone is already sufficient for dogfooding.

A user can go back and grab recent crashes after the fact?
Comment 5 Andrew Overholt [:overholt] (back Aug 31) 2012-09-24 12:32:49 PDT
Chris Lee, is this something we need from a support perspective?
Comment 6 Alex Keybl [:akeybl] 2012-09-24 12:52:34 PDT
(In reply to Andrew Overholt [:overholt] from comment #5)
> Chris Lee, is this something we need from a support perspective?

This is necessary from a release perspective (filing bugs, for instance). Whether or not this is necessary for ongoing support seems tangential (although it is).
Comment 7 Dietrich Ayala (:dietrich) 2012-09-24 13:12:20 PDT
The Gaia issue. https://github.com/mozilla-b2g/gaia/issues/4821

Going to block on both.
Comment 8 Chris Lee [:clee] 2012-09-24 14:51:08 PDT
Yes, this should block given we need the debug info here to prioritize and make fixes.
Comment 9 Alex Keybl [:akeybl] 2012-10-02 12:56:33 PDT
(In reply to Dietrich Ayala (:dietrich) from comment #7)
> The Gaia issue. https://github.com/mozilla-b2g/gaia/issues/4821
> 
> Going to block on both.

Until the Gaia issue is resolved, I think it would make a lot of sense to expose the about:crashes page we already use on Firefox for Android. 

This is a high priority issue for QA. bent - can you prioritize this if you don't have unlanded feature work?
Comment 10 Robert Kaiser 2012-10-02 13:22:47 PDT
I think exposing about:crashes and probably applying some CSS rules for small screen on that page is even the final solution for this. Right now, the biggest obstacle to getting anything is the security error I mentioned in comment #1.
Comment 11 Ben Turner (not reading bugmail, use the needinfo flag!) 2012-10-04 10:06:59 PDT
I've got a bunch of other stuff going on at the moment and this isn't really code I'm familiar with. It can be reassigned to me but I bet others can get to it and figure it out faster...
Comment 12 Shian-Yow Wu [:swu] 2012-10-11 02:51:10 PDT
(In reply to ben turner [:bent] from comment #11)
> I've got a bunch of other stuff going on at the moment and this isn't really
> code I'm familiar with. It can be reassigned to me but I bet others can get
> to it and figure it out faster...

TPE team will handle this bug.
Comment 13 Shih-Chiang Chien [:schien] (UTC+8) (use ni? plz) 2012-10-18 03:18:20 PDT
about:crashes will be redirect to chrome://global/content/crashes.xhtml, IIRC, settings app cannot access it directly. I'm thinking of creating a CrashReport.jsm that can populate report in JSON format, then expose the report to Gaia via settings or mozChromeEvent.
Does any one have suggestion about how to implement this bug?
Comment 14 Robert Kaiser 2012-10-18 05:23:21 PDT
(In reply to Shih-Chiang Chien [:schien] from comment #13)
> about:crashes will be redirect to chrome://global/content/crashes.xhtml,
> IIRC, settings app cannot access it directly.

We should change that.

> I'm thinking of creating a
> CrashReport.jsm that can populate report in JSON format, then expose the
> report to Gaia via settings or mozChromeEvent.

That's surely far more work, and still needs to go through chrome. Also, that is unable to trigger sending pending crashes on demand when clicking on them, which is one important feature of about:crashes that we'd really like to have as well.
Comment 15 Ted Mielczarek [:ted.mielczarek] 2012-10-18 05:24:13 PDT
If we simply want to display the list of crashes, then something like what you described sounds reasonable: factor the "build the list of crashes" part out of crashes.xhtml, and get that data to the unprivileged page somehow. about:crashes also supports submitting crashes that were not previously submitted (due to network errors or whatever), but perhaps we can live without that for a v1 on B2G.

I don't really know much about how the chrome/content interaction in Gaia works, so I can't offer concrete suggestions beyond that.
Comment 16 Andreas Gal :gal 2012-10-18 07:56:57 PDT
Window.location = about:crashes doesnt work?
Comment 17 Chris Jones [:cjones] inactive; ni?/f?/r? if you need me 2012-10-18 09:31:22 PDT
We can't load chrome code in content.  Please don't even attempt to write a patch to allow that.

I would be interested to hear of product requirements for this feature, vs. dogfooding/testing needs which are high.  If there's none of the former, I suggest we hack this in by having some throwaway UI trigger shell.js to load about:memory in a <xul:browser>.
Comment 18 Robert Kaiser 2012-10-18 11:16:52 PDT
(In reply to Chris Jones [:cjones] [:warhammer] from comment #17)
> We can't load chrome code in content.  Please don't even attempt to write a
> patch to allow that.

If that means we cannot load chrome-privileged about: pages in Gaia, then I suggest we just forget about getting users/testers getting any useful debug information about their device right on the device, or us getting any help from users when solving their problems (that includes links to their crashes, or about:support-type troubleshooting information, or even about:memory-type info). This means we have way fewer ways to help Firefox OS users with their problems than Firefox desktop or mobile users, but perhaps that's just OK. Also, this bug would be WONTFIX, as there's no way we can have users trigger submission of pending crash reports or view info about the crashes (s)he has experienced.
Comment 19 Robert Kaiser 2012-10-18 11:31:48 PDT
(In reply to Chris Jones [:cjones] [:warhammer] from comment #17)
> I
> suggest we hack this in by having some throwaway UI trigger shell.js to load
> about:memory in a <xul:browser>.

Erm, I guess I should really read comments in depth before replying. It's about:crashes here but there's probably multiple about: pages, including about:memory, that could need something like this. I think what could be done in line what you are saying, is to have some way to trigger a certain set of about:* pages to be shown from a very narrow definition of caller(s). My original thought was if we could have our, and only our, browser, enabled to load those about:* pages and we could have Settings, etc. just load it there. The question is - of course - what that means in terms of security.
Comment 20 Chris Jones [:cjones] inactive; ni?/f?/r? if you need me 2012-10-18 11:40:45 PDT
Our, and only our, browser is still "content" in the gecko sense.  Attempting to do that will be a security nightmare, please let's not!
Comment 21 [:fabrice] Fabrice Desré 2012-10-18 11:42:07 PDT
I guess we could have a new permission for that usage. Jonas?
Comment 22 Chris Jones [:cjones] inactive; ni?/f?/r? if you need me 2012-10-18 11:51:38 PDT
bz, folks are trying to get chrome pages loaded in content.  Halp?
Comment 23 :Margaret Leibovic 2012-10-18 12:05:13 PDT
*** Bug 801934 has been marked as a duplicate of this bug. ***
Comment 24 Boris Zbarsky [:bz] 2012-10-18 12:19:04 PDT
More precisely, people are trying to load a chrome:// URI from a document that does not have a system principal.

That's not allowed, sorry.

We could loosen that check, perhaps, but then I need to know exactly how I'm supposed to tell that your particular unprivileged principal is supposed to be allowed to load things that might give it system privileges once it's done loading them.
Comment 25 Chris Jones [:cjones] inactive; ni?/f?/r? if you need me 2012-10-18 12:23:52 PDT
Thanks for the assist, bz!
Comment 26 Boris Zbarsky [:bz] 2012-10-18 12:26:12 PDT
And in particular, see nsScriptSecurityManager::CheckLoadURIWithPrincipal
Comment 27 Jonas Sicking (:sicking) No longer reading bugmail consistently 2012-10-18 14:15:24 PDT
Yeah, trying to create a generic mechanism for loading chrome pages in the Firefox OS browser is a dramatic change to our security model. I don't think we have the time to get that working. Much less get it working in a safe way.

Firefox in B2G is *very* different from how Firefox on Desktop/Android works. That's intentional and is not going to change for the simple reason that we want other people to be able to write browsers for B2G.

If it works, having shell.xul open a xul:browser containing about:crashes sounds like a workable solution to me.

Another alternative is to create a simple API which allows getting all the crash information as a giant JSON object which then the settings app could use to display whatever UI we want.
Comment 28 Robert Kaiser 2012-10-18 15:03:02 PDT
(In reply to Jonas Sicking (:sicking) from comment #27)
> If it works, having shell.xul open a xul:browser containing about:crashes
> sounds like a workable solution to me.

I think I prefer this to going through the JSON stuff, using the existing about:crashes and just applying some small-screen styling (via CSS media queries, probably) to it is probably the fastest way if we can make it work in a secure way.
Comment 29 Jonas Sicking (:sicking) No longer reading bugmail consistently 2012-10-18 15:20:05 PDT
> I think I prefer this to going through the JSON stuff, using the existing
> about:crashes

I don't know what you mean by that. "The JSON stuff" and "using the existing about:crashes" were alternative proposals.
Comment 30 Robert Kaiser 2012-10-18 15:39:54 PDT
Yes. I meant I prefer "using the existing about:crashes" to "the JSON stuff", if possible, due to reusing existing code probably being less work than writing entirely new code, which is preferable at least for v1. Apart from that, I prefer having the additional functionality present in bout:crashes as well.
Comment 31 Jonas Sicking (:sicking) No longer reading bugmail consistently 2012-10-18 16:04:59 PDT
Like I said, I don't think simply reusing about:crashes is going to work within the security model we have without doing major changes. So I'm not at all convinced that it's at all simpler.

I'm also not convinced that it'd work, security stuff aside, since I'm not sure that the backend for about:crashes works when run in a child process.
Comment 32 [:fabrice] Fabrice Desré 2012-10-18 16:31:02 PDT
(In reply to Jonas Sicking (:sicking) from comment #31)
> 
> I'm also not convinced that it'd work, security stuff aside, since I'm not
> sure that the backend for about:crashes works when run in a child process.

We did check that with Margaret, and that indeed fails in the child process (using the patch at http://pastebin.mozilla.org/1870279).

One issue with doing it as a chrome/xul window in shell.js is that only the system app can send events to shell.js. The settings app could call an activity (with a returnValue == false) that is served by the system app which in turn sends an event to shell.js
Comment 33 Shih-Chiang Chien [:schien] (UTC+8) (use ni? plz) 2012-10-19 04:55:58 PDT
Should we take customizability into account? Using chrome page will make it hard to change UI since the related code is in m-c.
Comment 34 Ted Mielczarek [:ted.mielczarek] 2012-10-19 05:56:56 PDT
I don't think that should be a goal. This is purely a dogfood/testing page.
Comment 35 Vivien Nicolas (:vingtetun) (:21) - (NOT reading bugmails, needinfo? please) 2012-10-19 06:56:45 PDT
Jumping in the discussion and I can have missed some points here. Will it not be possible to give the Settings application device-storage:apps permissions. store crashes somewhere here as text files, and rewrite a simpler http://mxr.mozilla.org/mozilla-central/source/toolkit/crashreporter/content/crashes.js that use system XHR to send reports?
Comment 36 Ted Mielczarek [:ted.mielczarek] 2012-10-19 08:17:53 PDT
We already store the files on-disk, we really only use the file name and modification date:
http://mxr.mozilla.org/mozilla-central/source/toolkit/crashreporter/content/crashes.js#95

We already use XHR to send reports, that's:
http://mxr.mozilla.org/mozilla-central/source/toolkit/crashreporter/CrashSubmit.jsm

I'd rather not maintain two implementations of about:crashes if we can help it.
Comment 37 Dietrich Ayala (:dietrich) 2012-10-21 11:01:16 PDT
Drivers discussed, and this is not a release-blocking mandatory feature. Blocking1-.
Comment 38 Sheila Mooney 2012-10-22 11:27:01 PDT
I realize this was minused but this would seriously impact our ability to diagnose and fix crashes. This enables crash reporters to link up the crash that happened with one in crash stats. It's also needed by QA and others to help reproduce crashes.
Comment 39 Jason Smith [:jsmith] 2012-10-22 11:33:51 PDT
(In reply to Dietrich Ayala (:dietrich) from comment #37)
> Drivers discussed, and this is not a release-blocking mandatory feature.
> Blocking1-.

Can you give a rationale in the bug?
Comment 40 David Bolter [:davidb] 2012-10-22 13:00:34 PDT
(In reply to Fabrice Desré [:fabrice] from comment #32)
> (In reply to Jonas Sicking (:sicking) from comment #31)

> One issue with doing it as a chrome/xul window in shell.js is that only the
> system app can send events to shell.js. The settings app could call an
> activity (with a returnValue == false) that is served by the system app
> which in turn sends an event to shell.js

It sounds like you have a potential workaround here? (Not sure I read it correctly)

(In reply to Jonas Sicking (:sicking) from comment #27)

> Another alternative is to create a simple API which allows getting all the
> crash information as a giant JSON object which then the settings app could
> use to display whatever UI we want.

I'm not sure I've followed everything clearly in this bug but is it sounds like this (or something similar) is the way foreward?

If we get this fixed and landed the blocking status is less important.
Comment 41 Vivien Nicolas (:vingtetun) (:21) - (NOT reading bugmails, needinfo? please) 2012-10-23 09:33:05 PDT
(In reply to Ted Mielczarek [:ted.mielczarek] from comment #36)
> We already store the files on-disk, we really only use the file name and
> modification date:
> http://mxr.mozilla.org/mozilla-central/source/toolkit/crashreporter/content/
> crashes.js#95
>

Yes I spent time reading crashes.js but I was proposing to store them on /data/ (a location made readable by the devicestorage:apps permission). Maybe they already live here?
 
> We already use XHR to send reports, that's:
> http://mxr.mozilla.org/mozilla-central/source/toolkit/crashreporter/
> CrashSubmit.jsm

Not saying the contrary.
> 
> I'd rather not maintain two implementations of about:crashes if we can help
> it.

I understand but this is exactly what I proposed in order to solve the permission issue. Giving devicestorage:apps and system XHR permissions would let the settings apps be able to display a UI for them without the need for any extra chrome privileges.
Comment 42 Robert Kaiser 2012-10-23 10:20:23 PDT
(In reply to Vivien Nicolas (:vingtetun) from comment #41)
> (In reply to Ted Mielczarek [:ted.mielczarek] from comment #36)
> Yes I spent time reading crashes.js but I was proposing to store them on
> /data/ (a location made readable by the devicestorage:apps permission).
> Maybe they already live here?

The profile base is /data/b2g/mozilla, so they should already be in there.
Comment 43 Shih-Chiang Chien [:schien] (UTC+8) (use ni? plz) 2012-10-24 04:32:44 PDT
I tried what Vivien suggested in comment 41, and yes, settings app have the permission to access /data/b2g/mozilla. If we just want to list all the submitted/pending crash reports, we can copy the logic of populate report list from toolkit/crashreporter/content/crashes.js.
If we want to generate the hyperlink for each report, hard code "http://crash-stats.mozilla.com/report/index/" + report id might be the easiest way for this temporary page.
Comment 44 Chris Jones [:cjones] inactive; ni?/f?/r? if you need me 2012-10-24 09:21:37 PDT
It shouldn't have that permission!  Can you show |adb shell ls -l| for the directory you're trying to read?
Comment 45 Dietrich Ayala (:dietrich) 2012-10-24 16:47:37 PDT
(In reply to Jason Smith [:jsmith] from comment #39)
> (In reply to Dietrich Ayala (:dietrich) from comment #37)
> > Drivers discussed, and this is not a release-blocking mandatory feature.
> > Blocking1-.
> 
> Can you give a rationale in the bug?

Andreas said to minus this, since we'd ship the phone regardless if this was completed or not. Ping him if you'd like more info.
Comment 46 Shih-Chiang Chien [:schien] (UTC+8) (use ni? plz) 2012-10-24 20:57:38 PDT
(In reply to Chris Jones [:cjones] [:warhammer] from comment #44)
> It shouldn't have that permission!  Can you show |adb shell ls -l| for the
> directory you're trying to read?

here is the result of |adb shell ls -l data/b2g/mozilla| on my otoro
drwx------ root     root              2012-10-25 10:46 4wooqq87.default
-rw-r----- root     root           94 2012-10-24 18:20 profiles.ini

What I do is list all the files under data/b2g/mozilla via device storage API, and here is code.
http://pastebin.mozilla.org/1879095
Comment 47 Chris Jones [:cjones] inactive; ni?/f?/r? if you need me 2012-10-25 02:03:57 PDT
Hey Doug, what permission guards enumerating internal gecko files?  This is, ah, not something to be treated lightly ;).
Comment 48 Andrew Overholt [:overholt] (back Aug 31) 2012-10-25 10:35:41 PDT
Sheila, do you want make the call here?
Comment 49 Alex Keybl [:akeybl] 2012-10-25 12:30:33 PDT
(In reply to Dietrich Ayala (:dietrich) from comment #45)
> Andreas said to minus this, since we'd ship the phone regardless if this was
> completed or not. Ping him if you'd like more info.

Let's say we have no known critical crashes at release, so having about:crashes on the phone isn't considered necessary - fine. What happens if we have major crash issues after release? How will a user let us know which particular crash they're running into (without logcat)? That would hurt our ability to diagnose issues without clear STR.

Sounds like Sheila/Andreas will help make the final call here, but I did want to note my objection nonetheless.
Comment 50 Philipp von Weitershausen [:philikon] 2012-10-25 15:35:13 PDT
(In reply to Shih-Chiang Chien [:schien] from comment #43)
> I tried what Vivien suggested in comment 41, and yes, settings app have the
> permission to access /data/b2g/mozilla.

I hope not! No app should have the permission to read the file system directly like that. But this isn't just a permission problem. I'm not even aware of a WebAPI in Gecko that would let you do this.

> If we just want to list all the
> submitted/pending crash reports, we can copy the logic of populate report
> list from toolkit/crashreporter/content/crashes.js.

Nope. But here's what you *could* do as a work-around: use mozContent/mozChrome events to communicate a list of chrash IDs between shell.js and the app. That's the only solution I see short of creating a WebAPI for this or giving the System app some way to read the file system (which again would involve the creation of a WebAPI).
Comment 51 [:fabrice] Fabrice Desré 2012-10-25 15:39:37 PDT
Actually, the device storage api gives you access to all of /data when using the device-storage:apps permission (https://mxr.mozilla.org/mozilla-central/source/dom/devicestorage/nsDeviceStorage.cpp#670)
Comment 52 Alex Keybl [:akeybl] 2012-11-06 06:43:39 PST
Marking with blocking-basecamp+ since we've now heard from Stability/QA/RelMan that this is a requirement for shipping v1. We have not heard a good counter-argument.

Additionally, I'm marking this bug with the C1 milestone since it follows the criteria of "Crash feedback must be coming in and actionable from dogfooders" and "unfinished feature work" (see [1]). 

If this work is not finished by Nov19, this bug will need an exception and will be called out at the upcoming Exec Review.

[1] https://etherpad.mozilla.org/b2g-convergence-schedule
Comment 53 Shih-Chiang Chien [:schien] (UTC+8) (use ni? plz) 2012-11-07 14:07:56 PST
Since this bug is bb+ again, I'll put it in my working list again. 

Here is the latest UI spec I found in gaia mailing group.
http://people.mozilla.com/~lco/Crash_Reporting_B2G/R1_Crash%20Reports%20v1.pdf
In this spec, the must-have requirement is to display the crash data but not to manually send pending crash reports. So, I'm going to focus on the report-generating part.

After discussing with Timdream and Evelyn, there is not direct way that allows settings app retrieving data on-demand from Gecko. If we don't like the idea of using device storage api, then we need to use settings api to either update the crash data on changed (JSON approach) or notify shell.js for showing about:crashes (shell.xul approach).

I personally prefer the JSON approach.
Comment 54 Shih-Chiang Chien [:schien] (UTC+8) (use ni? plz) 2012-11-07 14:17:44 PST
(In reply to Shih-Chiang Chien [:schien] from comment #53)
> After discussing with Timdream and Evelyn, there is not direct way that
> allows settings app retrieving data on-demand from Gecko. If we don't like
> the idea of using device storage api, then we need to use settings api to
> either update the crash data on changed (JSON approach) or notify shell.js
> for showing about:crashes (shell.xul approach).
One thing I forgot to mention is that we don't need trick in comment 53 if we provide web api for crash data.
Comment 55 Jonas Sicking (:sicking) No longer reading bugmail consistently 2012-11-07 14:47:10 PST
If we already can read the crash data using DeviceStorage and the permissions that the settings app already has, then I think that's a totally fine solution to use for now.

Another alternative is to add a new DeviceStorage area specifically for crash information. Adding support for a new storage area is just a few lines of code.
Comment 56 [:fabrice] Fabrice Desré 2012-11-07 23:05:12 PST
Created attachment 679555 [details] [diff] [review]
wip

This patch uses the media storage API to list the submitted crash files and turn their names into urls.

I'm not displaying the date because accessing the lastModifiedDate property on the blob throws a NS_ERROR_FILE_ACCESS_DENIED exception.

Tapping on a report item opens the full crash report in the browser app, and this is quite unreadable...
Comment 57 [:fabrice] Fabrice Desré 2012-11-07 23:06:24 PST
Created attachment 679556 [details]
screenshot: New "Data Crash" button in the "Improve Firefox" panel
Comment 58 [:fabrice] Fabrice Desré 2012-11-07 23:07:05 PST
Created attachment 679557 [details]
screenshot: Submitted crash list
Comment 59 Robert Kaiser 2012-11-08 05:01:39 PST
Comment on attachment 679557 [details]
screenshot: Submitted crash list

This shows the most unimportant part of the data, unfortunately. The end of the ID tells us if it was submitted correctly (i.e. it ends with 6 digits that look like a date), and the crash date is the only bit of data we can show the user that (s)he understands to tell which crash is which.
Comment 60 Ted Mielczarek [:ted.mielczarek] 2012-11-08 06:15:13 PST
Comment on attachment 679555 [details] [diff] [review]
wip

I'm not wild about having the crash report URL hardcoded in here, nor having all this code essentially duplicated from crashes.js.

Also, re: comment 47 / comment 50: it seems horribly bad that webapps (even with a permission grant) can read the contents of /data/b2g/mozilla, since that contains all the profile data. That seems like a terrible terrible security hole waiting to happen.
Comment 61 [:fabrice] Fabrice Desré 2012-11-08 07:58:50 PST
(In reply to Robert Kaiser (:kairo@mozilla.com) from comment #59)
> 
> This shows the most unimportant part of the data, unfortunately. The end of
> the ID tells us if it was submitted correctly (i.e. it ends with 6 digits
> that look like a date), and the crash date is the only bit of data we can
> show the user that (s)he understands to tell which crash is which.

Full IDs look like bp-5803837e-3f95-4a8c-8f2e-20c942121108, so I', not sure which date-like part you're referring to.
Comment 62 [:fabrice] Fabrice Desré 2012-11-08 08:10:32 PST
(In reply to Ted Mielczarek [:ted.mielczarek] from comment #60)
> Comment on attachment 679555 [details] [diff] [review]
> wip
> 
> I'm not wild about having the crash report URL hardcoded in here, nor having
> all this code essentially duplicated from crashes.js.

We can move the crash report URL to a setting. For the code duplication, the code here is so minimal I don't think this is really an issue.

> Also, re: comment 47 / comment 50: it seems horribly bad that webapps (even
> with a permission grant) can read the contents of /data/b2g/mozilla, since
> that contains all the profile data. That seems like a terrible terrible
> security hole waiting to happen.

My biggest concern at this point is that I don't think this can be useful at all for users. Which UX workflow are we expecting them to use on a device?
Comment 63 Robert Kaiser 2012-11-08 08:14:47 PST
(In reply to Fabrice Desré [:fabrice] from comment #61)
> Full IDs look like bp-5803837e-3f95-4a8c-8f2e-20c942121108, so I', not sure
> which date-like part you're referring to.

The 6 digits at the end of the ID, in this case 121108, which tells us it was submitted successfully. The actual crash date is what is the only thing that really counts for a user, though, and you need to look at crashes.js how the real about:crashes page gets those.

I'm still not in favor of duplicating what the existing about:crashes does instead of reusing it, but it's you guys who need to do the work and know the problems.
Comment 64 Larissa Co [:lco] 2012-11-08 08:20:50 PST
(In reply to Robert Kaiser (:kairo@mozilla.com) from comment #59)
> Comment on attachment 679557 [details]
> screenshot: Submitted crash list
> 
> This shows the most unimportant part of the data, unfortunately. The end of
> the ID tells us if it was submitted correctly (i.e. it ends with 6 digits
> that look like a date), and the crash date is the only bit of data we can
> show the user that (s)he understands to tell which crash is which.

I don't know if this is the information you guys are planning as the final thing to display (or if more work needs to be done), but it's pretty intimidating to the user. Besides the crash date, is there a timestamp that we can get? Also, can we convert the code that says whether a report was sent or not into a label that says "Sent" if it is?

Additionally, if Support needs to troubleshoot the crash, what information would be relevant to them? The full string?

I just need to understand the requirements so that I can give you guys UI support.
Comment 65 Robert Kaiser 2012-11-08 08:31:09 PST
(In reply to Larissa Co from comment #64)
> I don't know if this is the information you guys are planning as the final
> thing to display (or if more work needs to be done), but it's pretty
> intimidating to the user.

The current screenshot is both intimidating and unhelpful, yes. ;-)

> Besides the crash date, is there a timestamp that
> we can get? Also, can we convert the code that says whether a report was
> sent or not into a label that says "Sent" if it is?

On the original about:crashes (check on a desktop or Android build), we display the crash date (plus time) along with the crash ID - and that date/time is usually the part that's really useful to the user.
That "sent" is something I have though about a lot in terms of making that more obvious on desktop as well - the change to replace the last 6 digits with the submission date when the server receives the report correctly was introduced for a different purpose than detecting if it was sent successfully, but we decided to keep it for this purpose, even if the original reason went away at some point. I'd love to expose that info in some way, and your idea is nice. Maybe B2G will be the first step to exposing this more generally. ;-)

> Additionally, if Support needs to troubleshoot the crash, what information
> would be relevant to them? The full string?

Yes, QA need the full crash ID - or the URL it links to (which contains that full ID).
Comment 66 [:fabrice] Fabrice Desré 2012-11-19 09:29:50 PST
Moved to C2 according to a discussion with Faramarz.
Comment 67 [:fabrice] Fabrice Desré 2012-11-28 09:58:24 PST
Created attachment 686158 [details]
Remoting about:crashes from the device to firefox desktop

Here's a screenshot of the about:crashes functionnality in a firefox addon I'm working on.
It gathers the crash report list (submitted and pending) on the device and display everything where we have more screen real estate.
Comment 68 Ben Turner (not reading bugmail, use the needinfo flag!) 2012-11-28 12:34:51 PST
(In reply to Fabrice Desré [:fabrice] from comment #67)
>in a firefox addon I'm working on.

I WANT THIS ADDON! :)
Comment 69 JP Rosevear [:jpr] 2012-11-29 08:16:12 PST
Moving to soft blocker, I know its useful, but it would be primarily for test drivers and if we get an add on we can deliver it out of band.

Please re-nom if you disagree.
Comment 70 Robert Kaiser 2012-11-29 09:16:53 PST
FYI, a poor man's way to get the submitted crashes right now, if you have a computer with adb and can connect it to your device:
adb shell ls -l /data/b2g/mozilla/Crash\ Reports/submitted/
Comment 71 Naoki Hirata :nhirata (please use needinfo instead of cc) 2013-01-30 13:01:30 PST
- about:Crashes used to work for a little while in an earlier release.  
- Chrome about: stuff was disabled.

:schien the directory is : /data/b2g/mozilla/Crash\ Reports/

The Crash Reports are stored in a directory outside of the profile.
Also to note this will show the pending reports (the reports not sent).
In the directory you should see at least 2 folders, and 2 files:  
pending
submitted
LastCrash
InstallTime*

You might not see them if you didn't have any pending or submitted crashes.
Comment 72 Robert Kaiser 2013-01-30 13:56:21 PST
We should at least have some app that interested people can install that just takes the data off the profile directory via the device storage (yes, that might not be good long-term, but that's what we have right now) and displays it or makes it available in some form. I guess access to that data might need a certified app, so if someone can teach me how to create and test such an app, I might even look into getting something crude to work as a POC to build on.

On comment #71, we mostly care about the submitted ones from the so-named directory, as those are actually available on the server side. If we made pending ones available in the UI, we'd need to hook that up to submitting them as well, and that needs chrome code to be called, so out of reach for the moment. (LastCrash and InstallTime are files that this UI shouldn't be concerned with.)
Comment 73 Robert Kaiser 2013-07-09 07:27:07 PDT
I tried to start off an app for doing that in https://github.com/KaiRo-at/aboutcrashes but I failed in getting a hosted app pushed to a device with privileges to open the "app" DeviceStorage. My current idea would be mostly to display with crash dates of submitted crashes, possibly offer opening the crash report in a browser, and offer a share action to be able to at least send the crash ID or URL to a device with a better screen and on which one can copy/paste the ID into e.g. a bug report.
Comment 74 Dave Hylands [:dhylands] 2013-07-22 09:33:12 PDT
Would it make sense to add a new "type" to device storage which gives access to the crash-report directory?

This would, in turn, create a new permission that could be assigned to apps, and the app wouldn't need to know the actual directory containing the crash data.

Something like a type of 'crash-reports' which maps to /data/b2g/mozilla/Crash\ Reports/ ?

Then the device storage permission would look like:

    "device-storage:crash-reports":{ "access": "readonly" },
Comment 75 Jason Smith [:jsmith] 2013-07-22 09:55:21 PDT
(In reply to Dave Hylands [:dhylands] from comment #74)
> Would it make sense to add a new "type" to device storage which gives access
> to the crash-report directory?
> 
> This would, in turn, create a new permission that could be assigned to apps,
> and the app wouldn't need to know the actual directory containing the crash
> data.
> 
> Something like a type of 'crash-reports' which maps to
> /data/b2g/mozilla/Crash\ Reports/ ?
> 
> Then the device storage permission would look like:
> 
>     "device-storage:crash-reports":{ "access": "readonly" },

+1 on this proposal. Could we allow privileged apps to access this permission? If so, that would unblock the ability to allow us to build a third-party app in the short term we could distribute out for grabbing crash report URLs easier (e.g.
Comment 76 Jason Smith [:jsmith] 2013-07-22 09:56:12 PDT
Was going to say in addition to comment 75 (e.g. someone from QA or Stability could build a simple packaged app we could put on marketplace).
Comment 77 Dave Hylands [:dhylands] 2013-07-22 10:44:38 PDT
If we do decide to add a new device storage type, we would need to change the permissions on the crash-report directory.

Currently, I don't believe that child processes have access to the crash report directory.

I seem to recall that we'd like to have the parent process open the file handle and then pass that to the child. Once this lands, then we wouldn't need any file permissions in the child.
Comment 78 [:fabrice] Fabrice Desré 2013-07-22 11:22:29 PDT
(In reply to Dave Hylands [:dhylands] from comment #77)
> If we do decide to add a new device storage type, we would need to change
> the permissions on the crash-report directory.
> 
> Currently, I don't believe that child processes have access to the crash
> report directory.
> 
> I seem to recall that we'd like to have the parent process open the file
> handle and then pass that to the child. Once this lands, then we wouldn't
> need any file permissions in the child.

device-storage:apps accesses also files that are not directly readable from the child so we should be good for the crash reports also.
Comment 79 Dave Hylands [:dhylands] 2013-07-22 11:55:36 PDT
(In reply to Fabrice Desré [:fabrice] from comment #78)
> (In reply to Dave Hylands [:dhylands] from comment #77)
> device-storage:apps accesses also files that are not directly readable from
> the child so we should be good for the crash reports also.

Silly me. Device Storage handles all of the I/O in the parent, which is why this all works.
Comment 80 Robert Kaiser 2013-07-22 12:50:56 PDT
FYI, I have blogged my ideas for this in http://home.kairo.at/blog/2013-07/wanted_apps_about_crashes - including some thoughts about possible UI.

[Not sure if that's what triggered Dave's commenting here, but it coincides nicely. ;-) ]
Comment 81 Dave Hylands [:dhylands] 2013-07-22 13:09:42 PDT
(In reply to Robert Kaiser (:kairo@mozilla.com) from comment #80)
> FYI, I have blogged my ideas for this in
> http://home.kairo.at/blog/2013-07/wanted_apps_about_crashes - including some
> thoughts about possible UI.
> 
> [Not sure if that's what triggered Dave's commenting here, but it coincides
> nicely. ;-) ]

Yeah - it was your blog post (through Planet Mozilla) that prompted comment 74.
Comment 82 Ted Mielczarek [:ted.mielczarek] 2013-07-29 08:17:07 PDT
If we implemented this same API in desktop Firefox (accessible from chrome pages, at least), then we could basically just rewrite the about:crashes page to use it and ship that as a packaged app.
Comment 83 [:fabrice] Fabrice Desré 2013-08-22 15:08:14 PDT
Created attachment 794298 [details] [diff] [review]
patch

This patch adds support for certified apps to use a device storage area called "crashes".
Comment 84 [:fabrice] Fabrice Desré 2013-08-22 15:10:10 PDT
Created attachment 794299 [details]
application.zip

Here's a very simple app that lists the files in the crash reports directory.
Comment 85 Dave Hylands [:dhylands] 2013-08-22 16:05:11 PDT
Comment on attachment 794298 [details] [diff] [review]
patch

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

r=me if you move the crash directory determination into the InitDirs function.

::: dom/devicestorage/nsDeviceStorage.cpp
@@ +751,5 @@
> +                                        getter_AddRefs(f));
> +#endif
> +    }
> +  }
> +

I think that this belongs in InitDirs? I don't think I documented it well enough :(

So InitDirs should initialize any directories which don't change based on the volume. This function should only calculate the volume path if it's somehow volume dependant.

That way we don't need to keep recalculating the root directory for each DeviceStorageFile which gets created.

It looks like apps should be also be done in InitDirs (but I can put that in a separate bug)
Comment 86 [:fabrice] Fabrice Desré 2013-08-23 08:01:17 PDT
 https://hg.mozilla.org/integration/b2g-inbound/rev/a14c4a86f85f
Comment 87 Ryan VanderMeulen [:RyanVM] 2013-08-23 14:00:53 PDT
https://hg.mozilla.org/mozilla-central/rev/a14c4a86f85f
Comment 88 Jason Smith [:jsmith] 2013-08-23 14:29:40 PDT
Note that we need to file a separate bug here for the Gaia portion of the implementation needed here.

Note You need to log in before you can comment on or make changes to this bug.