[Bug / Question] Use of properties such as `lightTree` when developing extensions

[dsl101]

This may not actually be a bug if it's working as expected, but it caught me out while developing an extension. I was loading it as a temporary add-on via about:debugging and wondering if it could be made to work with lightTree: true, so I added that to the TST register call. After a bit of experimentation I decided it couldn't work, as I really needed the message.tab.discarded property. So I removed that line from the call to register the extension, but my extension still wouldn't work—message.tab.discarded was returning undefined. I removed the temporary add-on, and now my published (via AMO) add-on also stopped working.

It seems that TST caches the setting for the add-on (looking at tst-api.js), so that if ever you set lightTree: true during development, it's necessary to always include lightTree: false from that point on—am I understanding correctly? I was somewhat surprised that loading a temporary add-on would affect the value of that property for an installed add-on though.

[piroor]

Currently it is not documented but a designed behavior.

treestyletab/webextensions/common/tst-api.js

Lines 327 to 338 in bfe7a32

	// inherit properties from last effective value
	const oldAddon = getAddon(id);
	if (oldAddon) {
	if (!('listeningTypes' in addon) && 'listeningTypes' in oldAddon)
	addon.listeningTypes = oldAddon.listeningTypes;
	if (!('style' in addon) && 'style' in oldAddon)
	addon.style = oldAddon.style;
	if (!('allowBulkMessaging' in addon) && 'allowBulkMessaging' in oldAddon)
	addon.allowBulkMessaging = oldAddon.allowBulkMessaging;
	if (!('lightTree' in addon) && 'lightTree' in oldAddon)
	addon.lightTree = oldAddon.lightTree;
	}

It aims to minimize second and later API call of register-self to update stylesheets.
Should we reset allowBulkMessaging and lightTee on every API call? Or, simply it is OK to add a note about this behavior to the document?

[dsl101]

I think setting that flag once and having it 'stick' even for the main extension was quite an unexpected result. But is it really that much overhead to pass explicitly in every call vs the expense of checking in that code above? Sounds like 50/50 at best. My personal preference would be to take it out, and treat undefined as false at all times. But happy to go with documenting it if there's some other benefit I'm not aware of.

[piroor]

I've updated the API document with the note about inheritance of options.
https://github.com/piroor/treestyletab/wiki/API-for-other-addons#basics
And I've realized the inconsistency about my description - "name" and "icons" were not sticky. For API consistency all options become sticky at the next release.