Isn't it a Firefox-Issue?

Same issue here with Safari.
The issue is that someone systematically changed these fields to number. #18199
See also #18415
Staging is also concerned.
I fail to understand the use of number when field is readonly.

Restore filter="unset" please.

Filering too is not necessary if no input is allowed.

Filtering is needed. readonly is a client-side restriction. Which means it can be circumvented easily. E.g. by entering a value through developer tools or removing the attribute itself the same way. Server-side validation/filtering is a must.

Also unset filter prevents data from being saved to database. We need this to ensure that we don't overwrite hits value.

I have restored the filter="unset". And I too would use type="text" here. So I am ready to change it to type="text". But it does not make a difference in the behaviour.

Semantically it is a number field not a text field
For assistive technology it is a number field not a text field

Changing it to a text field to work around a visual guide you don't like is a wrong approach

Using a number field with size when input is allowed was good, but I see now that over all components at least the "id" field is not consistent, in backend as well as in frontend.
Sometimes the field is hidden and has type="numeric" and a size (i.e. note.xml), sometimes the hidden field has no other attributes (i.e. override.xml, category/edit.xml)).
If the field is not hidden, it is always readonly but has different definitons. (i.e. item

Which is the correct definition for a hidden field?
Which definition to use if the field is visible but readonly?

Can we make a rule for that to avoid inconsitent use in components?

For assistive technology it is a number field not a text field

Reference?

Which is the correct definition for a hidden field?

Hidden type fields don't need any visual attributes (class, size, readonly).

IMO, ID field should be visible across all forms in backend but hidden in frontend.

Which definition to use if the field is visible but readonly?

Size attribute either needs to be reviewed and updated across the board or removed entirely. Currently its use seems random at best and it has no effect in core because default templates control input size anyways. class="readonly" can be removed.

Size is not a valid attribute for a number type field

elements of type "number" don't support form sizing attributes such as size. You'll have to resort to CSS to change the size of these controls.

https://developer.mozilla.org/en-US/docs/Web/HTML/Element/input/number

It maybe useful: https://w3c.github.io/html-reference/input.number.html

Concerning spin-buttons. Maybe something horrible like this in CSS?

<style>
input[type=number][readonly]::-webkit-outer-spin-button,
input[type=number][readonly]::-webkit-inner-spin-button
{
 -webkit-appearance: none;
}

input[type=number][readonly]
{
 -moz-appearance: textfield;
}
</style>

Looks good to me! Thanks!