4 ms·

Ask HN: I found an obscure bug with Firefox. Is it worth reporting?

5 points by heigh 2y ago

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

BoredPositron 2y ago
If you are going to report it like you wrote this post, you don't need to report it.
- galdosdi 2y ago
  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 2y ago
    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 2y ago
    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:  <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.
    - heigh 2y ago
      Also, how I knew it's a bug? I changed type="number" to type="text" and my code worked as expected.
      - 2y ago
- deleted 2y ago
  [deleted]
runjake 2y ago
I am not super good at this and only using half my brain, but I did my best attempt to convert this to vanilla JavaScript and get seemingly odd results. <!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> Someone educate me, especially if I am off base or the code is inherently incorrect.
- heigh 2y ago
  Scrapping the jQuery is definitely useful to recreate it, thanks for that. The only thing I would do extra is adding in HTML, HEAD and BODY tags to make it a bit more syntactically correct... Thanks for this though!
KomoD 2y ago
Honestly, you could have spent the time you used to write this post and comments on making the report instead. You basically wrote the entire bug report here, instead of doing it on Bugzilla.
toast0 2y ago
IMHO, it's worth reporting, but temper your expectations of it being fixed. I've seen clearly written, easily reproduced, possibly easily fixed bugs linger in Bugzilla for decades. At Mozilla and other organizations using bugzilla and other trackers. 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 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)
rossng 2y ago
Yes, you should report it. I've reported several Firefox bugs and the tickets often spring to life suddenly after several years of sitting there unaddressed. It makes life much easier for the developers if you include a clean, easy-to-reproduce test case.

JohnFen 2y ago

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 2y ago
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 2y ago
  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 2y ago
    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)