Open Bug 811299 Opened 12 years ago Updated 2 years ago

JavaScript Crash Reports?

Categories

(Toolkit :: Crash Reporting, defect)

Product:
Toolkit
Component:
Crash Reporting
Type:
defect

Tracking

()

People

(Reporter: kairo, Unassigned)

References

Details

On MozFest this weekend, I came to talk to someone (Chris Lonnen maybe?) who pointed me to Popcorn Maker using JavaScript crash reports, and now this blog post is also mentioning those: https://hacks.mozilla.org/2012/11/popcorn-maker-1-0-released-how-it-works/ There seems to be some problem with getting stacks out of this with the exact way they're doing it, but maybe this can improved. Having something like that would probably be interesting for all our products, given how intensely we are using JS all over the place, esp. of course for Firefox OS and Gaia. We should think about that as a long-term project.
This has essentially nothing to do with Breakpad, it's just catching JS exceptions and producing a stack.
The current stuff in Popcorn Maker surely has nothing to do with Breakpad, and I wasn't sure which component to really file this under, but I'm looking for a more general approach here if possible. Not sure where this would be done, though.
There is a module containing the client-side crash reporter in butter (a popcorn-maker library) that is tightly coupled to their app. Some work will need to be done to make it generic, but its a good starting point for thinking about crash reporting from webapps when they don't break the underlying browser. The stack is tricky. When catching exceptions top level in window.onerror, the stack has unwound by the time you can access the exception. Messing with the prototype to make a copy of the stack in a new var when the error is created didn't work well, in part because interesting errors tend not to be defined to inherit from the Error object (ones thrown by spidermonkey). Going to chat more with the popcorn folk about this once they're back. At this point it is not intended as part of a particular tool, but for web developers in general. That said, receiving and processing errors this generates should require little modification to a Socorro back end, not sure about the front.
lonnen, thanks for that description. I think we can even think in a broader sense as we might be able to get the JS engine to help us there if we want a higher-level mechanism to report in such "crashes".
And here's a blog post about what Popcorn Maker is doing there: http://vocamus.net/dave/?p=1532
Just a note: JS crash reporting is something we want to do as part of our Crash-Reporting-as-a-Service work for Marketplace in 2013.
This seems like something that would be very useful for Gaia if we don't already have something like it. I suspect the fact that Gaia is all JS is part of the reason for the low crash report numbers on B2G.
(In reply to Matthew N. [:MattN] from comment #7) > I suspect the fact that Gaia is all JS is > part of the reason for the low crash report numbers on B2G. No, that's probably because we are not testing/dogfooding enough (and have a relatively small set of users anyhow at this point). If we'd have JS crash reports, we'd also get a ton more reports of Firefox desktop, which has a real lot of its UI code code written in JS. Right now, if any of that throws exceptions, they're either lost completely or things just stop to work without us knowing directly and we get negative feedback from users in unspecific ways.
(In reply to Robert Kaiser (:kairo@mozilla.com) from comment #8) > (In reply to Matthew N. [:MattN] from comment #7) > > I suspect the fact that Gaia is all JS is > > part of the reason for the low crash report numbers on B2G. > > No, that's probably because we are not testing/dogfooding enough (and have a > relatively small set of users anyhow at this point). > > If we'd have JS crash reports, we'd also get a ton more reports of Firefox > desktop, which has a real lot of its UI code code written in JS. MattN was suggesting for only for Gaia in B2G (i.e. the lines you see in adb logcat prefixed with E/GeckoConsole), not for Firefox Desktop yet. This way, we can get crashes in Gaia (I think). Nominating for a feature in B2G.
tracking-b2g18: --- → ?
(In reply to Gary Kwong [:gkw] [:nth10sd] from comment #9) > MattN was suggesting for only for Gaia in B2G Well, I have filed this bug for getting JS Crash Reports in general.
> MattN was suggesting for only for Gaia in B2G (i.e. the lines you see in adb > logcat prefixed with E/GeckoConsole), not for Firefox Desktop yet. > > This way, we can get crashes in Gaia (I think). Nominating for a feature in > B2G. I cloned this into bug 857843.
tracking-b2g18: ? → ---
(In reply to Gary Kwong [:gkw] [:nth10sd] from comment #11) > I cloned this into bug 857843. Which probably means that that bug is dependent on the generic JS crash reporting capability that I request in this bug. And all this is probably dependent on bug 355430.
Depends on: 355430
Severity: normal → S3
You need to log in before you can comment on or make changes to this bug.