[remote-dbg-next] Show warning when temporary install fails

RESOLVED FIXED in Firefox 66


Last year
8 months ago


(Reporter: jdescottes, Assigned: jdescottes)


(Blocks 2 bugs)

Firefox 66
Dependency tree / graph

Firefox Tracking Flags

(firefox66 fixed)


(Whiteboard: old-remote-debugging-ng-m3)


(4 attachments)

Current about:debugging displays several warning when a temporary addon fails to install. This feature should be ported to the new about:debugging.

See usage of localized strings:
- addonInstallError
- legacyExtensionWarning
Priority: P5 → P3
Hi. I was pointed at this as a good first bug (first time in devtools land, and working on Mozilla Central). Is there anything that I should know about where/how I should go to implement this?

I can see that the strings you've highlighted are in `devtools/client/aboutdebugging/components/addons/Target.js` & `devtools/client/aboutdebugging/components/addons/InstallError.js`. It looks like this issue is about moving the error functionality from those files into `devtools/client/aboutdebugging-new/components`. Does the whole addons functionality need porting too or just that error capability? 

How do I go about using the new about:debugging opposed to the original one?

What are the best STR for testing this is working (i.e. how would I install a temporary addon that fails)?


Flags: needinfo?(jdescottes)
Thanks Emily! 

To setup your m-c environment we have some documentation at https://docs.firefox-dev.tools/getting-started/build.html

In order to use the new about:debugging, you need to set the preference `devtools.aboutdebugging.new-enabled` to true in about:config. This new version already supports installing temporary addons, but never displays any error message if the install fails.

The steps here are:
- open about:debugging
- click on Load Temporary Addon
- find the path to an invalid extension (we have one in the mozilla central repo, under devtools/client/aboutdebugging/test/addons/bad/manifest.json so you can just navigate to this json and try to load it)

Expected Result: the installation error should be displayed to the user 
Actual Result: nothing happens (you can try this on the current about:debugging to see how the feature looks like today) 

For the UI, we can reuse the same colors and icons as the ones used in the current about:debugging. 

The error message also contains a "Retry" button, to retry installing the addon at the same path. 

In this bug let's keep things simple and only implement a "Dismiss" button that will hide the message. We will implement the Retry feature in a follow-up bug.
Flags: needinfo?(jdescottes)
Assignee: nobody → etoop
Hi. I realise I shouldn't have picked this up and then headed off on PTO. Sorry about that.

I am trying to figure out where is best to handle the extenstion installation failure mode. Can I please query about the `runtimeReducer` (`runtime-state.js`)? I notice that in all of the `actionTypes` defined in `constants.js`, only the success conditions are implemented in `runtimeReducer`. Is this deliberate and failure states should be implemented somewhere else, or is the project currently still a in happy-path only state (I can't find any failure state implementations anywhere)?
Flags: needinfo?(jdescottes)
Actually, ignore that, I think I just figured it out. I think I need to examine the details of the props target as shown in `ServiceWorkerAction` and render different things based on the output.
Flags: needinfo?(jdescottes)
Emily told me she's no longer working on this, so unassigning
Assignee: etoop → nobody
filter on remote-debugging-next-move-m3-to-m2
filter on remote-debugging-next-move-m3-to-m2
filter on remote-debugging-next-move-m3-to-m2
No longer blocks: remote-debugging-ng-m3
Priority: P3 → P2
Whiteboard: old-remote-debugging-ng-m3
Assignee: nobody → jdescottes
Priority: P2 → P1
Posted image existing_mockups.png
Matt, I plan to do a simple implementation to show install errors for temporary addons. I will follow the original mockups for now. Would it make sense to have a UX followup for this particular item, or for installing temporary addons in general?
Flags: needinfo?(mcroud)
Actually I can't really follow the mockups here because when a temporary installation fails, we don't have the necessary metadata about the addon to display its name, id, icon etc...
Yes a UX bug for this would be good.

Can I confirm my understanding that the use case for this feature is to allow developers to install and run an unsigned add on they are developing?

Is there a way I can test this failure myself?
Flags: needinfo?(mcroud)
(In reply to Matthew Croud from comment #14)
> Yes a UX bug for this would be good.
> Can I confirm my understanding that the use case for this feature is to
> allow developers to install and run an unsigned add on they are developing?

Yes, that's exactly the idea. Filed Bug 1509091 and wrote some more details about the feature in https://docs.google.com/document/d/1GKOODQaMyO9eMu0vgXQybHO2HFR_pL3z9JGzF5c25qE/edit# 

> Is there a way I can test this failure myself?

You can have a look at the (slightly old) documentation at https://developer.mozilla.org/en-US/docs/Mozilla/Add-ons/WebExtensions/Temporary_Installation_in_Firefox

The easiest is probably to clone the source code for an existing extension (eg https://github.com/captainbrosset/devtools-highlighter) and try to load it as a temporary extension, modify a few things, reload etc... 

Note that there is an alternate workflow for developing addons which relies on webext https://developer.mozilla.org/en-US/docs/Mozilla/Add-ons/WebExtensions/Getting_started_with_web-ext . I don't know if one is more popular than another, I don't think we have telemetry for those.
Pushed by jdescottes@mozilla.com:
Show install error message for temporary addons;r=daisuke,ladybenko
Add test for temporary extension install error;r=daisuke
Closed: 8 months ago
Resolution: --- → FIXED
Target Milestone: --- → Firefox 66
You need to log in before you can comment on or make changes to this bug.