1352217 - webextension sources should be refreshed in the debugger after reload

Status: NEW

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

Description

[Anthony Lieuallen]

User Agent: Mozilla/5.0 (X11; Ubuntu; Linux x86_64; rv:52.0) Gecko/20100101 Firefox/52.0
Build ID: 20170317213448

Steps to reproduce:

Pre webextension, I could put a text file in my profile, and have that extension-I'm-developing always available.  Now, as best I can tell, I have to open about:debugging and click several buttons every time.

Pre webextension, I had persistent data storage.  Now, as best I can tell, every time I restart my browser, the entire extension and all its stored data/preferences is completely gone.  Each day, I have to set up the entire thing again.

Every time I hit 'reload', my debugger is broken.  Every time I hit 'debug' I have to wait for an awkward second or so, then a confirm dialog pops up, but very quickly then the debugger itself pops up, over the confirm dialog.  Stealing keyboard focus.

I always want the debugger available (for this extension I'm developing).  I always want it installed.  I always want its stored data available.  I don't want to keep confirming it, keep installing it, keep configuring it again each day.

This is a drain on my time and makes developing webextensions harder than necessary.  I'm fine with an unsigned-like model of this working only in non-mainline builds if necessary.

When I "Load unpacked extension" in Chrome, it stays put, even across Chrome restarts.

Context: https://bugzilla.mozilla.org/show_bug.cgi?id=1334174

Comment 1

[Rob Wu [:robwu]]

Luca, since you have been doing work on add-ons debugging, could you take a look at the request? Thanks!

Comment 2

[Luca Greco [:rpl] [:luca] [:lgreco]]

Hi Anthony,

The addon debugger toolbox is designed to work across addon reloads, and if the debugger breaks on reload, it is a bug and it should be fixed (e.g. recently, I filed Bug 1349956, basically a breakpoint in a browserActor popup breaks the debugger if the "no popup autohide" toggle button has not been enabled).

If the issue experienced in this case is not the one described by Bug 1349956, it would be very helpful to know the steps to reproduce it and how the issue present itself (what devtools panel and which feature becomes visible broken first and if errors have been logged in the Browser Console).

Comment 3

[Anthony Lieuallen]

1. Launch Nightly.
2. Open about:debugging#addons
3. Load Temporary Add-on  (https://github.com/arantius/greasemonkey/tree/webbymonkey)
4. Click its Debug
5. Click OK
6. Click Debugger

At this point, I see all my background scripts listed.  I can click on them and see their source. 
7. Click Reload

Now the still visible debugger tab says "this page has no sources".


If I open (Ctrl-Shift-J) browser console after step 2, I see some warnings at various points.  At 'click reload' time, these lines appear:



1492198538964	addons.webextension.<unknown>	WARN	Loading extension 'null': Reading manifest: Error processing permissions.3: Unknown permission "windows"
1492198539058	addons.xpi	WARN	Addon with ID 7e4ccdaa69fa75a3462ff32d7aa9d118a85a85f9@temporary-addon already installed, older version will be disabled
Error: Got an invalid root window in DocumentWalker  core.js:100
1492198540014	addons.webextension.7e4ccdaa69fa75a3462ff32d7aa9d118a85a85f9@temporary-addon	WARN	Loading extension '7e4ccdaa69fa75a3462ff32d7aa9d118a85a85f9@temporary-addon': Reading manifest: Error processing permissions.3: Unknown permission "windows"
Warning: attempting to write 5974 bytes to preference browser.uiCustomization.state. This is bad for general performance and memory usage. Such an amount of data should rather be written to an external file. This preference will not be sent to any content processes.
XrayWrapper denied access to property Symbol.toPrimitive (reason: object is not safely Xrayable). See https://developer.mozilla.org/en-US/docs/Xray_vision for more information. Note that only the first denied property access from a given global object will be reported.  script.js:2360:4
TypeError: can't access dead object  core.js:100
Webconsole context has changed
TypeError: can't access dead object  core.js:100



In addition to wanting all the things above I've mentioned, I'd want to be able to (re)start Nightly and have not only my in-development extension still installed with its persistent data, but also automatically restore the debugger (if it was open when closing Nightly).  With no confirmation prompt, and in the same location/size as it was before.

Comment 4

[Luca Greco [:rpl] [:luca] [:lgreco]]

Hi Anthony,
Thanks for the detailed STR, I've been able to reproduce the issue:
none of the logged warnings is related to the issue, the list of sources is empty because of a bug in the old debugger ui frontend, which does not reload the list of the sources (the browser toolbox has the same issue, because it also uses the old debugger ui frontend code).

I tried the same STR on with the new debugger frontend ui enabled (Bug 1346902) and I've been able to verify that the new debugger frontend doesn't have this issue and reloads the list of the sources after an addon reload as expected, and so this part of the issues described will be fixed once Bug 1346902 lands.

A more persistent development workflow on builds where the xpi signatures checks can be disabled seems to be the aim of Bug 1309288 (which should expose in the about:debugging page the new UI related to Bug 1185460).

Comment 5

[Anthony Lieuallen]

Another follow on in generally the same vein:  I've got bits of my UI that load in tabs, e.g.:

      browser.tabs.create({
        'url': browser.runtime.getURL('src/content/manage-user-scripts.html'),
      });

If I open that tab, work on it a bit, then need to change the background handler of a message, I have to reload the extension.  Clicking reload closes that tab, and I'm forced to click around in my UI again to get that tab back just to continue development/testing.

If Firefox could not destroy such tabs on extension reload, even if it has to reload the tab, it would be a big time saver.

Comment 6

[Julian Descottes [:jdescottes]]

I am going to block this bug on Bug 1346902 for now, as it seems this will address the main issue described in the summary. 

Maybe a separate issue should be filed for your comment 5?

Comment 7

[Anthony Lieuallen]

There are several things I'd like to see, all in the vein of "make developing web extensions easier".  Only one of them is reflected in the current title of this bug.  Happy to split out separate bugs if you'd like me to:

1. Install-once for webextension under development.  (Rather than install on every launch of Firefox/Nightly.)
2. Persistent data persistence.  As-is I lose my values (webext storage, indexeddb) which A) is extra work to set back up B) blocks testing of some things that involve restarting the browser and having the state there.
3. Webext debugger should work across extension reload.
4. Bonus: everything including debugger, its active tab, window size/location, etc. should continue working and restore settings across both extension reload and Firefox/Nightly restart.
5. Open popups/tabs should remain across extension/browser reload/restart, even if the tab has to reload.  Making a change to a background script (message handler), switching to the about:debugging page, reloading the extension, then clicking around in my UI to re-open that feature under test takes a long time.
6. An easier way to reload my background scripts, which doesn't involve swapping tabs.  (This is a _frequent_ action for me.)
7. When my extension under development throws an error, it should always be visible.

For #7: today I was writing some code, I accidentally wrote "foo()" which should have been "this.foo()".  When I triggered that code to run, nothing happened, and nothing was logged anywhere.  I took a blind guess where the error was, wrapped it in a `try { ... } catch (e) { console.error(e); }` and it was then logged and obvious.  In this case, foo() was a method of an object in a background script, operating in the context of a message handler, triggered by a user action in a script operating in the scope of a moz-extension:// page in a tab.

Comment 8

[Andy McKay]

(In reply to Anthony Lieuallen from comment #7)
> 2. Persistent data persistence.  As-is I lose my values (webext storage,
> indexeddb) which A) is extra work to set back up B) blocks testing of some
> things that involve restarting the browser and having the state there.

Have you tried the steps laid out in bug 1356661 comment 5?

Comment 9

[Anthony Lieuallen]

No, I have not followed those steps.  I did what the documentation said:
https://developer.mozilla.org/en-US/Add-ons/WebExtensions/Your_first_WebExtension#Installing

I don't really like `web-ext`, and I don't like the description at bug 1356661 about how it works.  It creates temporary profiles?  So bookmarks and history and other browser settings won't persist?  That sounds like the opposite of what I want.

To be thorough, though, I tried setting up `web-ext`.  Doing nothing but launching that way, I stored something to IndexedDb and restarted the browser.  No surprise, it's not there.

So then I set an applications/gecko/id in my `manfest.json` and nothing changed.  If I restart the browser, my (IndexedDb) persisted data is gone again.