Starting to edit a file with emacs makes web-ext (and Firefox) die (Error: ENOENT)

[M-Reimer]

Is this a feature request or a bug?

Bug

What is the current behavior?

Once I start editing a file, the emacs editor creates a symlink to a "pseudo file" into the project directory which leads to nowhere:

$ ls -la | grep '^l'
lrwxrwxrwx  1 mozdev users    32 15. Feb 08:14 .#contentscript.js -> mozdev@desktoppc.3589:1245462345

This seems to be used for "file locking" by emacs. Once this "non targeted" symlink appears, web-ext catches it up and dies:

Error: ENOENT: no such file or directory, stat '/home/mozdev/git/languageswitch/.#contentscript.js'

I've tried all kinds of things to exclude such files from web-ext monitoring but failed so far. Seems like the code, which makes it crash, runs before the file actually gets excluded.

What is the expected or desired behavior?

Such "ENOENT" errors should not cause web-ext (and Firefox) to just "disappear" immediately. This bug makes it really difficult to work on Add-ons with emacs.

Version information (for bug reports)

• Firefox version: 85.0.2
• Your OS and version: Arch Linux
• Paste the output of these commands:

node --version && npm --version && web-ext --version

v15.8.0
6.14.11
5.5.0

[rpl]

@M-Reimer would you mind to provide as the full stack trace form the error? (try --verbose if the stack trace is not visible without it).

[M-Reimer]

There is no stack trace. Just

Error: ENOENT: no such file or directory, stat '/home/mozdev/git/languageswitch/.#background.js'

It is possible to reproduce this on any Linux system if you run "web-ext run" in one terminal window and then open a second one where you create a symlink to "nothing" in the directory where you started "web-ext run" in:

$ ln -s this_file_does_not_exist this_is_a_broken_link

[M-Reimer]

Oh. And as long as this link exists, there is no way to use "web-ext run" again until the symlink is deleted 😆

[rpl]

Forgot to comment about this right after I did look into it (shortly before releasing web-ext v6.0.0):

• This issue was triggered by an unhandled rejection
• Only with more recent nodejs versions unhandled rejections trigger a fatal failure and nodejs shutdowns the process automatically
• Reproducible locally on nodejs 12 and web-ext 5.5.0 by using node --unhandled-rejections=strict $(which web-ext) run ...
• Not reproducible anymore on master (and I can't reproduce it anymore on the last released version, web-ext v6.0.0)
• Based on a quick look to the verbose logs it seems that we are ignoring those files from the FileFilter class because it does match one of the default ignore files patterns, “**/.*”

I suspect that the fs.stat call that was triggering the failure may have been part of watchpack and the fix is very likely due to updating watchpack version as part of web-ext v6.0.0

It may be worth adding an explicit integration test, in case the issue was triggered by a dependency as I suspect and may be reintroduced again in future npm deps updates (I just filed #2210 as a followup for doing that that).

[rpl]

Closing as fixed by #2024
(@M-Reimer feel free to re-open this and mention me if you can still reproduce)