Agreed. Do a lot more investigation, including creating a minimal test case, carefully reading MDN to be sure the behavior isn't expected (and you should parse the docs to be able to state precisely what the intended behavior and output should be), and honestly, give a shot at actually debugging a development version of Firefox itself. You may well fix the bug yourself (and in the process learn a lot, or more likely realize your bug is not a bug and you just misunderstood the API)
You really want to avoid wasting people's time with a nonbug that is due to you misunderstanding a subtle API.
This is open source. There is no them. Them is us. The easier you make the bug ticket to read the likelier someone chooses to try to fix it.
I mean you do this for a living too so think of it like that -- are you writing a bug ticket that screams "nice easy junior beginner bug" or something that screams "I'm gonna investigate forever and never even figure out why the reporter thinks this is an issue"?
If you can make a truly good bug report it actually does have a good chance of being fixed, if not now, eventually, next time someone wants to "start contributing to open source" and sees this easy beginner bug ticket. Believe me, nobody will want to tackle one that's written like your above comment
Also, using a regex on a number doesn't sound that obscure. Ask yourself why you're the first one to catch this.
Also you must repro it on the latest nightly build or else you may be reporting something already fixed
Basically just do unto them as you would have your users do unto you in your day job projects.