THere are 60 mochitest plain jobs on android. Having all 60 of them show up in the interactive view list is not helping (almost?) anyone.

I still frequently accidentally trigger stuff I don't mean to because I can't see the full list of what I'm triggering, and after repeatedly filtering I either get bored or think I've got everything.

Effectively, I usually want mochitest browser chrome (and sometimes, plain/chrome as well) tests on all desktop platforms (and sometimes android). I don't want pgo jobs, but I can't filter for !shippable because that kills off all the mac jobs. Then there's all the -qr and -sw- jobs that I also don't want, plus some other smaller things.

If I could only see "groups" of jobs instead of 6-20 rows for each platform+test+opt/dbg/pgo combination, mach try fuzzy would be a lot more usable.

I think I'd like to go a step further here and just always remove chunk numbers from mach try fuzzy / other selectors. Especially given that we are soon going to be landing "manifest scheduling" on autoland, which means the chunks that developers see in treeherder will not be the same as the chunks that they get locally. This would be a step in the direction of abstracting the concept of "chunks" away from developers.

So in this new chunkless world, selecting:

./mach try fuzzy -q "test-linux64/opt-mochitest-plain-e10s"

would run all Linux 64 opt mochitest-plain tests with e10s, no matter how many chunks there are. If a subset of mochitests are desired, then developers can specify a test path:

./mach try fuzzy -q "test-linux64/opt-mochitest-plain-e10s" dom/indexedDB

This way the default mental model is that I'm selecting "paths" not "chunks".

Note, we could potentially implement a flag to continue to expose chunks if that's desired for some advanced use cases. Though, if such use cases exist, I think we should try to see if there are alternative solutions (e.g using presets) to solve them first.

I've had a few requests for selecting platforms with |mach try auto|, and this is a blocker to that work (at least given the solution I have in mind). Will try and take a poke at this soon.

Didn't get a chance to make any meaningful progress here. May try again soon, but am not actively working on it.