[galdosdi]

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.

[heigh]

My sincere apologies to you both - I am mostly a lurker, and really didn't expect a response to my post, especially one as detailed as you've given.

I'm a 20 year dev, and it really is a strange bug, but as I mentioned before, I didn't expect a response, so as I only had my password for HN on my phone (which I only have stored there), I didn't have access to my code, nor thought to bother to reset my password and store it so I can access it from my PC.

I'm kicking my laziness/sloppiness-self now, and sorry for my crappy original post. I reset my password and want to thank you both for your feedback.

I will post the bug and see how it goes...

[heigh]

For what it's worth the issue I encountered is this, and now, I am wondering if the ticket should actually be directed to jQuery, rather than Firefox...

The bug is actually around a type="number" input field, not a number in an INPUT field. But here goes my summary of it:

<!-- HTML Code //--> <input type="number" id="progress" class="form-control mr-0 pr-0" placeholder="Progress (%)" />

//JS Code $('#progress').on("change",function() { let val = $(this).val().replace(/[^0-9.]/g, '');

        // Ensure only one decimal point
        let parts = val.split('.');
        if (parts.length > 2) {
            val = parts[0] + '.' + parts.slice(1).join('');
        }

        let numVal = parseFloat(val) || 0;

        if (numVal > 100) {
            numVal = 100;
        } else if (numVal < 0) {
            numVal = 0;
        }

        $(this).val(numVal === 0 ? '' : numVal);
    });

//Expectation OnChange, it removed everything except valid numbers (including a single decimal place).

//Reality It does this for the first iteration, but not further iterations

//Example 1. Enter "1234.456AB" into the progress field (excluding the quotation marks). 2. blur from the field to trigger the onChange. 3. Observe that it works and produces the result 100 (as per the code). 4. Type in ABCD into the progress field 5. Nothing happens. ABCD remains there.

[galdosdi]

A great way to make the bug report better would be to remove jQuery from the equation and see if it still repros. The smaller the test case the better.

[heigh]

Also, how I knew it's a bug? I changed type="number" to type="text" and my code worked as expected.

[carlnewton]

I think the behaviour you're describing is that a non-numeric value in a number field doesn't trigger the change event in JavaScript. I don't know if it would necessarily be a bug, but a difference in behaviour between Firefox and Chrome. In trying it with the JavaScript querySelector instead, it looks like Chrome restricts the input on keypress, whereas Firefox restricts it ahead of the change event. You could always use the keypress event, but looking at your snippet, it looks like you could just use the min and max attributes of the number field instead?

[JohnFen]

You're not completely wrong, but posing all of that as some sort of hard requirement also encourages people to just not report bugs.

There needs to be a balance, but I'm not sure what it would look like.

[galdosdi]

I apologize if it sounded like a "hard requirement". In fact, I have no affiliation with firefox, so obviously this is no requirement of any kind, soft, hard, or medium, just random advice from a random guy.

The question is "will 'they' actually fix it" which sounds a lot like "what can I do to make it more likely it'll actually be looked at or fixed" and the answer is "idk, but the better the bug report, the better the chances"

[JohnFen]

Ah, I understand better, thank you.

This is a topic of interest to me because the problems related to bug reporting is one of the several things that got me to largely disengage from the formal OSS community (where I used to be very active). Even as a dev who understands what a good bug report looks like, actually making one is often a very unpleasant experience. So I stopped doing that.

[galdosdi]

Yeah, I get your point.

In fairness-- most of the work involved in making a decent report is the same work the fixer would have to do anyway, except it's much easier for the reporter to do it since the fixer cannot read the reporter's mind if reproducing fails due to vague reports.

So, when someone submits a poor report, it's hard to escape the conclusion that the bug wasn't important enough to them to put in the effort. If it's not important enough to even put in the bare minimum effort for the reporter, why should the fixer, who may have to put in an order of magnitude more effort, conclue it's important?

I honestly don't mind the FOSS community being hardasses about accepting bug reports for this reason-- fundamentally, a bug reporter interacting with a maintainer is the same dynamic as a homeless man interacting with a passerby or a nonprofit writing a grant proposal for a foundation-- you are begging for a handout, to get something for nothing.

It's when they're hardasses about accepting bug reports that come with full working PRs that fix the bugs that one is a little more disappointed. At that point I don't necessarily expect arbitrary PRs to be merged of course-- but the fact that a patch is available should be strong evidence that the underlying bug report is more than legit enough to call for looking into, even if fixed some entirely different way.

In my experience, while submitting a bug report doesn't necessarily get it fixed and submitting a PR doesn't necessarily get it merged -- submitting a bug report WITH a PR that fixes it does have a far higher chance of getting the underlying bug report taken seriously (albeit fixed some other way that doesn't use the sample patch submitted)