1263687 - Log to the browser console when an add-on fails to load

Status: RESOLVED FIXED

(DevTools :: about:debugging, defect, P3)

Description

[Andy McKay]

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.

Comment 1

[Jan Keromnes [:janx]]

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?

Comment 2

[Alexandre Poirot [:ochameau]]

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.

Comment 3

[Andrew Swan [:aswan]]

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?

Comment 4

[Alexandre Poirot [:ochameau]]

Oh. Ah. It is the other way around. Then yes. it sounds much simplier.

Do not hesitate to fix that then.

Comment 5

[Andrew Swan [:aswan]]

Attachment: MozReview Request: Bug 1263687 Log add-on temporary install errors r?ochameau

Review commit: https://reviewboard.mozilla.org/r/45797/diff/#index_header
See other reviews: https://reviewboard.mozilla.org/r/45797/

Comment 6

[Andrew Swan [:aswan]]

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.

Comment 7

[Andy McKay]

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

Comment 8

[Andrew Swan [:aswan]]

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 9

[Andy McKay]

Awesome!

Comment 10

[Alexandre Poirot [:ochameau]]

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.

Comment 11

[Andrew Swan [:aswan]]

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

Comment 12

[Andrew Swan [:aswan]]

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.

Comment 13

[Pulsebot]

https://hg.mozilla.org/integration/fx-team/rev/b79aa52d7ee2

Comment 14

[Carsten Book [:Tomcat]]

https://hg.mozilla.org/mozilla-central/rev/b79aa52d7ee2