How to get browser.tabs.executeScript() to work?

Add-ons Development
#1

browser.tabs.executeScript is supposed to return a Promise. So I am using it in a Promise sequence that starts with the user clicking in the Firefox context menu. But it does nothing and generates error message “Error: missing ) after argument list err@moz-extension://c4f1e771-138e-4ba2-9e9e-a7fdfe05b765/PM_bg.js:150:24”. I cannot find a missing right paren.

...then(L3)...

function L3()
	{
	return browser.tabs.executeScript(null,{file:"/PM_fg.js"});
	} // L3

ADDED: If relevant: the code first loads a URL into a new tab, then waits 1 second for the tab to settle down, then calls L3 to insert a script. No, I didn’t want to put a very large file full of extraneous stuff here.

Firefox 64.0 (64bit)

#2

ADDED: Well, it seems that browser.tabs.executeScript was doing something: it was analyzing the foreground/insertion script and finding problems with it. Making the FG script shorter fixed the problem (and uncovered more problems). It is so hard to debug background/foreground scripts, because of the poor support for errors built into Firefox WebExtensions. Why is no one improving it? Why do the experts not tell the rest of us what to avoid? Sorry I am writing in such a frustrated way, but well, I am frustrated.

#3

The line and column number in the error should point to the exact place in your source code where the error is found.

#4

Martin, you would think so, right? But since most of my errors are subtle (not well explained in the documentation), they seem to occur mostly in functions outside of my own code, internal parts of the debugger or JavaScript systems. A good example is a “dead object”, which is leaked and only detected on temporary addon reload. There is no file/line number info for such subtle errors.

Also, in some cases, I see reports on the Web or even bugs in Bugzilla that are not solved or fixed even after months or years. It is very discouraging.

But the good news here is that I’ve made some progress today and have had my first successful automatic login to a website (a commercial cross-browser testing site). I could be making progress so much faster if the documentation matched the kinds of operations actually needed by a password manager… It is hard to debug when there is only an obscure error message to work with or no clue at all, and “console.log” doesn’t work.

I have become almost expert at making browser Notification boxes work via message from foreground to background. And I can make debugging information appear by putting it in a login field of my external test website.

#5

If they don’t affect you, you can safely ignore them. You will see much more errors in the devtools than are caused by your own code. And finally the documentation only mentions errors that are specific to extension APIs, since this is after all the normal web stack. But I’m sure you’re aware of that.

I have seen your thread on it. Which turned out to be an (unnecessary) event listener that was never removed and leaked when you reloaded a temporary install (or if you were to upgrade your extension). At least that’s what I grasped from your description of the issue afterward.

Error reports and problems can stall for various reasons. I don’t think you should be discouraged by that but instead try to figure out why it stalled (was there some information missing, was it a generic communication issue etc.)

Console.log should work everywhere in your extension code. Please consider https://developer.mozilla.org/en-US/docs/Mozilla/Add-ons/WebExtensions/Debugging on where you’d find the output for a console.log statement. As an example, for your content scripts/execScripts you’d want to check the page dev tools.

Lastly, MDN is an open wiki. Of course content should be structured, but if you think there’s some information that is glaringly missing, please contribute it to MDN. Note that documentation is a very exact science and you will often find information in one specific place and not repeated any further.

#6

Are you using web-ext? If not, you should. It makes development much easier. Things reloads itself.
Also there is a browser debugging console in the about:debugging page. But you can debug content scrips, pop-ups, add-on own pages… Also maybe you don’t want to use browser.tabs.executeScript but a normal content script defined for specific domains in manifest.json.

#7

juraj, You don’t have to guess what I’m trying to do. I’ve said I want to create a better Password Manager than the existing ones (by simply not guessing what websites need to log you in). I’m using a normal content script, but it has to work for all domains, since any domain can expose a login mechanism, so I can’t use the predetermined URL pattern matching. I will try Web-Ext; thanks for the nudge.

#8

juraj, web-ext requires nodejs. I’ve previously tried this system and am not happy developing in a minimal command-line environment. I like Windows-oriented tools.

However, yesterday I improved my ability to debug by defining a different error reporter to replace “.catch()”. It is as follows:

function onerr()
	{
	this.console.log.bind(console);
	} // onerr

It is used as follows:

promise-function.then(…).then(…).onerr();

When I create errors in promises, either deliberately or by accident, this function actually shows the line number of the error. catch(err) fails to do this.

#9

web-ext is not platform specific. I’m using Windows as well, there is no issue with web-ext. After you install it with npm i -g web-ext, you just execute web-ext run in you add-on folder and that’s it. You can even create .bat file that will run it for you. It’s easier than it looks. Also there is a lot of advanced features, see the docs.