Source data filters suddenly show up blank in the web UI

I’ve just encountered a very strange issue with the Source Data > Filters section of the backup configuration editing web UI, namely that several entries no longer show up in the list view, but still appear in the text view. For example:

Sample 1 (screenshots)

Sample 2 (screenshots)

2024-02-25 04_56_21-NVIDIA GeForce Overlay DT

Looking through the rest of my filters, it appears that the only filter types showing up properly in the UI are:

  • Exclude folder
  • Exclude regular expression
  • Exclude files whose names contain

I’m not sure what brought this on, as I’ve always used the list view to edit filters, and these items always showed up before. This also occurs on the filter lists for all of my other backup configurations, even one which I haven’t edited the filters on for years.

Has anyone seen this bug before or have any idea how I might work around it? I’m honestly scared to edit my backup configurations at all right now, for fear it will eat all the entries which aren’t showing up in the UI the moment I click Save.

Firefox 123.0 released on Feb 20 does this for me using the filter set mentioned below on Feb 23:

Edge browser is what I usually use for Duplicati. It’s fine. What’s your browser version? Got other?

I managed to get two Firefox versions on one little-used system using its 122.0.1 install plus 123.0 installed from Going to the same old Duplicati, only the new one had the issue.


It’s ultimately the text version that matters, and you can certainly copy it out for safety if you wish to.
I did a small test of adding another exclude beyond the set of mostly empties. Save and revisit to do glance at Edit as text looked about right, and Edit as list looked as empty as it was before…

This probably needs to be looked at by someone who does JavaScript. Maybe a visit to Bugzilla for Firefox will turn up a clue. I couldn’t find anything in a Google search, but I only used general terms.

the lack of display seems to be a Firefox issue indeed. Chrome displays correctly on my Linux computer.

Some other weirdness with the new Firefox on two systems – one Duplicati, one


There are normally 10 options, but now there’s an empty one (which we’ve seen too much) at top.

Also some of them don’t work right building a filter from the GUI input, for example Exclude file specifying test as the expression builds test rather than -test. Still need some JavaScript help.

I don’t understand what is going on, the issue is when determining the filter type:


if (txt.indexOf(pre) != 0 || txt.lastIndexOf(suf) != txt.length - suf.length)
    return null;

In the browser console this if statement should be false, but the debugger will still step to return null:

>> txt
>> pre
>> suf
>> txt.indexOf(pre) != 0 || txt.lastIndexOf(suf) != txt.length - suf.length

The watch expressions in the debugger (not console) show up as unavailable if they evaluate to false or 0, so that doesn’t inspire confidence.

Because the type is empty, the select will be set to an empty string which will show up as an extra option. That part is expected at least, however I don’t know why a simple if statement doesn’t work.

During testing, I also managed to get it to work properly sometimes, but I didn’t change anything. After some console.log debugging, it seems that txt.lastIndexOf(suf) with an empty suf sometimes returns 0. Given this is javascript, it might be a bug in the method, or lastIndexOf could have been set to a different function for all strings. It has something to do with the calling context, since the first few times it is called it works:

this.splitFilterIntoTypeAndBody = function(src, dirsep) {
  if (src == null)
      return null;
  if (dirsep == null) {
      throw new Error('No dirsep provided!');
  console.log(src, src.lastIndexOf(""));

Output when setting the filter:

-test 5 x2
-test 0 x2

The number of correct outputs also sometimes changes.

Firefox 123 for developers
SpiderMonkey Newsletter (Firefox 122-123)
might show up something for you, but nothing clear for me. I did toggle this new option off, inspired by the performance work mentioned. Sometimes that breaks things. No help from turning it off, even after restart.


I didn’t even consider the browser might be causing it. Indeed, I’m using Firefox version 123, and the filters display just fine in Edge.

Good to know, thanks. I’ll keep an eye on the text version to make sure it stays consistent with what I want my filters to do.

Ahh, never thought about that giving issues, yes, I’m on 123.0, I’ll try edge…

Firefox 123 is out with broken site reporting tool makes me wonder if I can report 123 fails here?
I’m not sure it’s a new feature. How do I report a broken site in Firefox desktop? has further info.


Got another report back recently. Looking forward to your result.


Oops. I see that’s you in the other topic, so we’re not waiting for you here now…

Maybe I’ll see if any more luck happens in tracing down the JavaScript problem.

I looked to see what other browsers I could test with. Underlying engines are getting fewer these days, which presumably is why Firefox is worried about being left behind by, say, Chromium based browsers.

For completeness though, this seems fine on Chrome, Edge, Firefox 122.0.1, and Pale Moon which is related to Firefox long ago from a fork of its Gecko engine. I also searched Mozilla Bugzilla days back, finding nothing to indicate there is a general JavaScript bug, yet we have one. I reported it to Mozilla…

They’d probably prefer if it was a web site they could get to over the Internet, but that’s hard to arrange securely, so we’ll find out what happens with http://localhost:8200/ngax/index.html#/edit/12 which is where my installation happened to be when I was playing with the button and JavaScript issue.

Although behavior is reported above as a little unpredictable, I don’t do JavaScript or web work, so test that I tried was to start with no filters. Adding one in a working browser seems to give a default-to-tweak Exclude expression on the dropdown, * in the typing area, making three-button-menu Edit as text of -*, and being able to reverse back to original dropdown-plus-typing area form using Edit as list.

Firefox 123.0 fails in both directions, and it’s not anything we changed. Even years-old Duplicati breaks.


On Linux Mint 21.2, it works on 122.0 and fails on 123.0 after I let OS’ updater update. This was before rebooting, so it was the same running Duplicati. Only obvious difference was that it’s now Firefox 123.0.

Firefox 123.0.1 is out now, and initial test shows it fixes this issue for me. Anyone else want to try it?

Thanks Mozilla!

Looks fixed for me too, probably this point fixed it:

Fixed a regression in the JavaScript JIT engine incorrectly inlining strings in some cases. (Bug 1882386)

Given that the console and debugger printed different things, it had to be some deep engine bug.

It’s fixed for me on 123.0.1 as well! Thanks, everyone, for your help on this one.

FF 123.0 broke my GWT app discusses. The 2% to 5% performance boost (in newsletter) had a bug.

Optimisation ideas for inlined String functions

They moved the fix through very fast (thanks to a nice test case), found broken revision, got author in.

Had process for getting in the planned dot release, otherwise Duplicati users would be suffering more:

User impact if declined: Wrong result for String.prototype.lastIndexOf after JIT-inlining when the search string is the empty string.

Maybe that matches