Support

I will say this a final time and close the ticket with prejudice.

As we have done since December 2009, we output a very simple INPUT field. For example:

<input class="form-control" type="number" 
       id="engine.dump.common.batchsize_custom" 
       min="0" max="100000" step="1" style="display: block;">

The browser itself renders it as whatever, in this case as an input box with a spinner control. We DO NOT have control over this. The reason we are using type="number" is client-side validation. The reason we want client-side validation is that it improves user experience. Sure, we do server-side validation as well, but try to communicate that one input in a sea of configuration options is invalid and the user will, understandably, get frustrated and very correctly retort "why don't you idiots do client-side validation instead of letting me submit this insanely long form with invalid data and then have me try to find where the heck I made an error I didn't know about?". It's the kind of thing that can make or break user experience, and lose you users, let alone paying clients. I mean, this is the primary reason we've gone through the pain to make this JavaScript-based configuration page instead of just using Joomla's Form to spit out an insanely long configuration form and call it a day (which, incidentally, was pretty much how JoomlaPack —Akeeba Backup's predecessor— worked and had exactly that negative user experience effect).

We capture the blur event of that input box to update an INPUT field of type="hidden" with the real value:

                    var elCustomValue = document.createElement("input");
                    elCustomValue.className = 'form-control';
                    elCustomValue.setAttribute("type", "number");
                    elCustomValue.id            = config_key + "_custom";
                    elCustomValue.style.display = "none";
                    elCustomValue.setAttribute("min", minValue);
                    elCustomValue.setAttribute("max", maxValue);
                    elCustomValue.setAttribute("step", stepValue);

                    akeebabackup.System.addEventListener(elCustomValue, "blur", function ()
                    {
                        var value = parseFloat(elCustomValue.value);
                        value     = value * defdata["scale"];

                        if (value < defdata["min"])
                        {
                            value = defdata["min"];
                        }
                        else if (value > defdata["max"])
                        {
                            value = defdata["max"];
                        }

                        elHiddenInput.value = value;

                        var newValue = value / defdata["scale"];

                        if (defdata["scale"] > 1)
                        {
                            elCustomValue.value = newValue.toFixed(2);
                        }
                        else
                        {
                            elCustomValue.value = Math.trunc(newValue);
                        }
                    });

The browser is supposed to issue a blur event when you move the focus away from the input box, including after using the spinner and immediately clicking on a save button, as per the official documentation on Mozilla's official Mozilla Developer Network site: https://developer.mozilla.org/en-US/docs/Web/API/Element/blur_event. In other words, the company making Firefox is saying that the code above has to work.

The fact that the browser does not issue the blur event, or at the very least does not execute the event handler, is a BROWSER BUG. Since we are NOT the developers of the browser we have ABSOLUTELY NO CONTROL OVER IT. As a result, there is nothing to "fix" in our code. Firefox should fix its own code. Updating the contents of the input box clicking on the spinner control but never going through blur when the entire control (spinner and input box) loses focus is just plain wrong. And I am not saying this as a web developer. I am saying this as someone who was writing DESKTOP SOFTWARE for the better part of a decade in a plethora of languages —Turbo Pascal, Delphi, Visual Basic, C#— before moving to web software development. Issuing an event when the control loses focus is fundamental in GUI implementation.

The fact that it is a browser-specific bug is further corroborated by the obvious fact that all other major browsers —which have a collective market share well over 90% in general, and over 95% among our clients— do work correctly, as well as the fact that this approach has worked just fine even with Firefox in the past.

Moreover, you should note that your market share information is generic. We make decisions based on what our clients use, not what is used in general. It's very different. Otherwise we'd still be idiotically trying to support Internet Explorer and would've already dropped support for PHP 7.4 and 8.0. But we don't write software for the imaginary "average computer user". We write software for a very well-defined subgroup of computer users, therefore we get to support what our clients use. Simple, isn't it?

Further to that, the number of people who use spinner buttons instead of typing a value is infinitesimal compared to the people who actually type in a value. Most people, like yours truly when using my secondary development environment (Linux, Firefox), either type a value in the box, or focus the edit box and use the up/down arrows on their keyboard. Both methods work great even on desktop Firefox, which should tell you a lot about where the bug is and if you don't get it you are not qualified to make comments like the ones you made in this ticket. Therefore, the number of people who are likely to have this problem is negligible. As a matter of fact, you are the only person who has ever reported this issue. So, basically, we are wasting our time talking about how less than 0.01% of users will experience this. Wow, that's pointless!

I'm sorry that you are one of the two or three people in the world who are affected. However, I am simply not willing to screw over literally everyone else —thousands of users— to appease you. The alternative would be removing client-side validation which would result in many more support tickets about what people would correctly perceive as a problem with Akeeba Backup's interface, and losing many users and paying clients as a result. And all that for what? A browser bug that the browser's maker has documented should not be happening. Sorry, this is not something I am willing to do. It makes no sense from a software development perspective, and it makes no sense from a business perspective.