Ask HN: I found an obscure bug with Firefox. Is it worth reporting? It’s really quite strange but when you use a “number” input field in Firefox, then validate it with RegEx, it totally flips out. I can provide examples but I guess my question is, is it worth reporting these? Or will it just never get fixed? Edit: spellcheck |
Spend a day turning this into a bug report that's up to the standards of Mozilla; maybe another day trying to track down the behavior and suggest a patch. File the bug, and maybe the patch, and then implement a work around and go on with your life. Sure, watch for replies and try to respond in a timely fashion, but don't expect anything.
That said, I've put in a bugzilla bug and it got fixed in a reasonable time and then pushed in the next eligible release; https://bugzilla.mozilla.org/show_bug.cgi?id=1740856 but it was widely applicable, and the observed behavior was clearly broken, but details were hard to observe for many (which is why effects from the bug were observed but not diagnosed in related bugs)
<!DOCTYPE html>
<input type="number" id="progress" class="form-control mr-0 pr-0" placeholder="Progress (%)" />
<script>
document.getElementById('progress').addEventListener('change', function() {
console.log("fired!");
// Remove any non-numeric.
let val = this.value.replace(/[^0-9.]/g, '');
// 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.value = numVal === 0 ? '' : numVal;
});
</script>
Thanks for this though!
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.
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...
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);
});
//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.
There needs to be a balance, but I'm not sure what it would look like.
You basically wrote the entire bug report here, instead of doing it on Bugzilla.
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"
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.
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)