Closed Bug 791380 Opened 12 years ago Closed 11 years ago

Need on-phone equivalent of about:crashes

Categories

(Firefox OS Graveyard :: General, defect, P4)

Product:
Firefox OS Graveyard
Component:
General
Type:
defect

Tracking

(blocking-b2g:koi+, blocking-basecamp:-, firefox26 fixed)

Status:
RESOLVED FIXED
Milestone:
B2G C2 (20nov-10dec)
Project Flags:
blocking-b2g koi+
blocking-basecamp -
Tracking Flags:
Tracking Status
firefox26 --- fixed

People

(Reporter: akeybl, Assigned: fabrice)

References

Details

(Whiteboard: [LOE:S])

Attachments

(2 files, 4 obsolete files)

patch
6.26 KB, patch
dhylands
: review+
Details | Diff | Splinter Review
application.zip
33.31 KB, application/zip
Details 
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.
blocking-basecamp: --- → ?
Blocks: b2g-crash-reporting
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.
Ben, can you take a look at what platform support is needed here?  Thanks.
Assignee: nobody → bent.mozilla
blocking-basecamp: ? → +
Re-noming - Gaia triage says this does not block since the crash reports seen automatically on the phone is already sufficient for dogfooding.
blocking-basecamp: + → ?
(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?
Chris Lee, is this something we need from a support perspective?
Whiteboard: [LOE:S] → [LOE:S][blocked-on-input Chris Lee]
(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).
The Gaia issue. https://github.com/mozilla-b2g/gaia/issues/4821

Going to block on both.
blocking-basecamp: ? → +
Yes, this should block given we need the debug info here to prioritize and make fixes.
(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?
Priority: -- → P1
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.
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...
Assignee: bent.mozilla → nobody
Assignee: nobody → schien
(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.
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?
(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.
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.
Window.location = about:crashes doesnt work?
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>.
(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.
(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.
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!
I guess we could have a new permission for that usage. Jonas?
bz, folks are trying to get chrome pages loaded in content.  Halp?
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.
Thanks for the assist, bz!
And in particular, see nsScriptSecurityManager::CheckLoadURIWithPrincipal
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.
(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.
> 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.
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.
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.
(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
Should we take customizability into account? Using chrome page will make it hard to change UI since the related code is in m-c.
I don't think that should be a goal. This is purely a dogfood/testing page.
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?
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.
Whiteboard: [LOE:S][blocked-on-input Chris Lee] → [LOE:S]
Drivers discussed, and this is not a release-blocking mandatory feature. Blocking1-.
blocking-basecamp: + → -
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.
blocking-basecamp: - → ?
(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?
Flags: needinfo?(dietrich)
(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.
(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.
(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.
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.
It shouldn't have that permission!  Can you show |adb shell ls -l| for the directory you're trying to read?
(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.
Flags: needinfo?(dietrich)
(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
Hey Doug, what permission guards enumerating internal gecko files?  This is, ah, not something to be treated lightly ;).
Sheila, do you want make the call here?
Flags: needinfo?(smooney)
(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.
(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).
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)
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
blocking-basecamp: ? → +
Flags: needinfo?(smooney)
Target Milestone: --- → B2G C1 (to 19nov)
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.
(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.
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.
Assignee: schien → fabrice
Attached patch wip (obsolete) — — Splinter Review 
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...
Attached image screenshot: Submitted crash list (obsolete) — 

    
    

    
  
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 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.

    
    

    
  
(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.

    
    

    
  
(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?

    
    

    
  
(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.

    
    

    
  
(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.

    
    

    
  
(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).

    
    

    
  
Moved to C2 according to a discussion with Faramarz.
Target Milestone: B2G C1 (to 19nov) → B2G C2 (20nov-10dec)

    
    

    
  


  
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.

        Attachment #679555 -
        Attachment is obsolete: true

        Attachment #679556 -
        Attachment is obsolete: true

        Attachment #679557 -
        Attachment is obsolete: true

    
    

    
  
(In reply to Fabrice Desré [:fabrice] from comment #67)
>in a firefox addon I'm working on.

I WANT THIS ADDON! :)

    
    

    
  
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.
blocking-basecamp: + → -
Priority: P1 → P4

    
    

    
  
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/

    
    

    
  
- 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.

    
    

    
  
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.)

    
    

    
  
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.

    
    

    
  
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" },

    
    

    
  
(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.

    
    

    
  
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).

    
    

    
  
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.

    
    

    
  
(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.

    
    

    
  
(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.

    
  
blocking-b2g: --- → koi?

    
    

    
  
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. ;-) ]

    
    

    
  
(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.

    
    

    
  
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.

    
  
blocking-b2g: koi? → koi+

    
    

    
  

      
      
      
      

        Attached patch
          
          
        patch
        — 
          — Splinter Review
      

    


  
This patch adds support for certified apps to use a device storage area called "crashes".

        Attachment #686158 -
        Attachment is obsolete: true

        Attachment #794298 -
        Flags: review?(dhylands)

    
    

    
  

      
      
      
      

        Attached file
          
        application.zip
        — 
      

    


  
Here's a very simple app that lists the files in the crash reports directory.

    
    

    
  
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)

        Attachment #794298 -
        Flags: review?(dhylands) → review+

    
    

    
  
https://hg.mozilla.org/mozilla-central/rev/a14c4a86f85f
Status: NEW → RESOLVED
Closed: 11 years ago
Resolution: --- → FIXED

    
    

    
  
Note that we need to file a separate bug here for the Gaia portion of the implementation needed here.

    
  
Depends on: 908896

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






  

    
  







  

    

      
Attachment

      

      
      
      
      
    

    

      

        

          

            
General

            

              Creator: 



            

            
Created: 

            
Updated: 

            
Size: