Just create a text field with a filter integer.

With such a giant range of values no one is going to want to scroll through a list

Would be cool if we could have different layouts for that field, like dropdown (which we have now) and slider. For such large ranges a slider could be appropriate.

Using such big range obviously will cause a problem somewhere: or server, or on client side. It is expected.
For now can use what @brianteeman suggested.

If you just want to ask for new custom field that implement "number" input, then please edit the issue description so it is clear "Feature request", or open a new issue for it.

Thanks.

btw: Joomla already have this field type

BTW the number field is very limited in functionality on safari
https://caniuse.com/input-number

Guys as a developer i can find the way out.
The point of this, is to fix or improve the way it works.

Any range that exceeds 1000 numbers renders it useless and this is a very usual real world scenario.
Not to mention that it is almost impossible to use it, after a certain point from the user perspective.

@brianteeman not sure that i get the safari limitations. As far as i can see any version after 2010 seems to support this.

Anyway, if the release leader wants to fix that, i can create a PR.

Please submit PR. It should also fix #27877. Thanks.

I need to get a green light from the release leader.

Sure ? thank you @sakiss ? great if we can also fix the issue @Quy mentioned with your PR.
Many thanks for your willingness.

@brianteeman not sure that i get the safari limitations. As far as i can see any version after 2010 seems to support this.

There was an error on the caniuse website that has now been resolved. The issue is onlt with Safari on ios

@sakiss do you still wnat to fix the issue?

@rdeutz yes i will create a PR soon.

This still happens on Joomla 6.2.0, and on a shared host it takes the whole article editor down rather than just making one page slow.

Setup: a custom field of type Integer for articles, with Last set to 1000000000 and First and Step left empty. Empty values keep the plugin defaults (First 1, Step 1), because the params merge skips empty strings. So IntegerField::getOptions() builds one billion options.

Result: opening a new or existing article in the administrator runs PHP into the account memory limit (1 GB under CloudLinux LVE). The request fails and the server answers 503. It starts seconds after the field is saved, and the editor stays down until the field is changed or unpublished. Nothing in the field form warns that the range becomes a list.

The fix proposed in #43697 (a number input instead of a dropdown) was closed without being merged, and IntegerField still extends ListField on 6.2-dev. So the problem is still there in practice.

If a change of input type is not wanted, two smaller options:

• refuse to save an Integer field whose range would produce more than a fixed number of options (for example 1000), with a message that points to the Number field type;
• or stop adding options past that number in getOptions() and log a warning.

Workaround for anyone who lands here: use the Number field type for large ranges.

it was closed because it broke backwards compatibility

Thanks, that explains it. The two smaller options above keep the dropdown as it is, so existing fields and their stored values are not affected. The softest one is just a warning when the field is saved, saying how many options the range will produce and pointing to the Number field. Would a PR for that warning be welcome?