[MC-271761] The "namespace" field of filter in pack.mcmeta leaks through definitions

(corrected after reading the comment by tryashtar)

The bug

If several blocks, including a block that filters out paths in namespace "minecraft", are defined in the filter, blocks that specify a not "minecraft" namespace will also filter out the same paths they say in "minecraft" namespace.

The attachment is a datapack to verify this behavior. It only contains a pack.mcmeta that filters out vanilla advancements and recipes from a namespace that does not exist.

How to reproduce

Download the datapack attached and install it to a world
Enter the world
Press "L" (or the key bind to open advancements tab) and observe that all vanilla advancements are disabled ✔
Execute this command through chat to get all recipes
```
/recipe give @s *
```

Observe that all vanilla recipes are disabled ❌

Attachments

namespace-leaking.zip

Comments 3

tryashtar 2024-05-08T20:39:05Z

From doing some testing, the issue isn't exactly as described. For example, a single block with a given namespace works properly. However, namespaces do seem to leak across definitions. For example this block

{
  "namespace": "&NONEXISTENT$",
  "path": "^recipes/"
},
{
  "namespace": "^minecraft$",
  "path": "&NONEXISTENT$"
}

filters out vanilla recipes, even though it should filter out nothing.

endsky 2024-05-09T06:07:30Z

I did more testing. A single block with given namespace only works if the given namespace is "minecraft", otherwise it blocks nothing.
I think I will do another report for this.

Misode 2024-12-09T00:13:00Z

I did some analysis on this. The ResourceLocationPattern class has a locationPredicate method, which is a predicate for testing an entire resource location. This is what the filter font/glyph provider uses for checking sprite resource locations, as intended.

However the ResourceFilterSection class has isNamespaceFiltered and isPathFiltered methods which respectively check if any of the listed blocks match the namespacePredicate or pathPredicate predicates. This means essentially that every combination of namespace-path blocks will block resource locations, which is not expected.

The example given by tryashtar is equivalent to specifying the following, in the current implementation:

{
  "namespace": "&NONEXISTENT$",
  "path": "^recipes/"
},
{
  "namespace": "&NONEXISTENT$",
  "path": "&NONEXISTENT$"
},
{
  "namespace": "^minecraft$",
  "path": "&NONEXISTENT$"
},
{
  "namespace": "^minecraft$",
  "path": "^recipes/"
}