Closed Bug 1263687 Opened 6 years ago Closed 6 years ago
Log to the browser console when an add-on fails to load
58 bytes, text/x-review-board-request
When an add-on fails to load from about:debugging, it prints an error message. That's wonderful and so helpful: https://www.dropbox.com/s/4fmxv6fxnp4jw4d/Screenshot%202016-04-11%2011.34.05.png?dl=0 But the browser console does have some good details. It would be nice if it could show the warning AND log to browser console.
Alex, would you be interested in mentoring this bug, and give a few tips and pointers for a new contributor who'd like to fix this?
Priority: -- → P3
Summary: Restore browser console when an add-on fails to load → Log to the browser console when an add-on fails to load
This is a followup of bug 1231128 and definitely not easy. I stated in that bug that it would be hard to do and may not be worth the investment. Unless someone find a way to easily pull these errors out of platform guts? Andy, it would help if you expose what typical error you see in the console that you think should be visible on about:debugging. I may requalify this based on the very precise things we want to catch.
Depends on: 1231128
I think Andy's request was just to take the error that is currently displayed in the add-on manager and also log it to the browser console so it gets recorded and there is way to see the error even after dismissing the message from the add-on manager. It should be a one-liner, I can whip up a patch unless we'd like to leave it available for a new contributor?
Oh. Ah. It is the other way around. Then yes. it sounds much simplier. Do not hesitate to fix that then.
Review commit: https://reviewboard.mozilla.org/r/45797/diff/#index_header See other reviews: https://reviewboard.mozilla.org/r/45797/
Attachment #8740482 - Flags: review?(poirot.alex)
Tested manually, I don't think this warrants an automated test. Also ran lint by hand and got the usual bunch of warnings, eyeballing the list I don't think I added any new ones.
Sorry for the late comments. https://www.dropbox.com/s/jiavg4k67cfapgg/Screenshot%202016-04-12%2009.59.34.png?dl=0 Is what I see when an add-on fails to load in dev edition. It's the same error message but contains more details about what went on that would be useful to people trying to track down problems. Catching an error is cool and useful, but I feel like if we don't propagate up a full stack, one day this will catch us out. So I might asking for the harder thing...
Prior to 1231128 I think it was more accident than design that we got full stacks -- installTemporaryAddon() returned a promise that the caller never looked at so when it was rejected, the exception was just dumped into the browser console. In 1231128 we just displayed the message field from the exception, which meant the full stack was gone. But the attached patch uses reportError() so the full stack is once again available in the browser console. The "uncaught promise rejection" noise is gone, which I think is a good thing.
Comment on attachment 8740482 [details] MozReview Request: Bug 1263687 Log add-on temporary install errors r?ochameau https://reviewboard.mozilla.org/r/45797/#review42579 Looks good. But I have some doubts about the overall UX your are trying to get. Do we expect Addon developer to have about:debugging + Browser console + Addon toolbox? It sounds like too much! They may even have the Browser toolbox to inspect the UI :/ Is there someone trying to think about the overall UX of WebExtension development? I see a lot of contribution around it these days, but I don't step back to ensure the various contributions are coordinated and aims to a precise goal.
Attachment #8740482 - Flags: review?(poirot.alex) → review+
(In reply to Alexandre Poirot [:ochameau] from comment #10) > Is there someone trying to think about the overall UX of WebExtension > development? > I see a lot of contribution around it these days, but I don't step back to > ensure the various contributions are coordinated and aims to a precise goal. I agree, and I think this is exactly what Andy had in mind when he opened bug 1263688.
I hit submit too fast, the bug from the previous comment is narrow in scope, there is also bug 1226743. I don't think either of those has anybody's full-time attention, but the issue you raise is certainly on peoples' radar.
You need to log in before you can comment on or make changes to this bug.