The HTML5 fallback JavaScript converts <input type="number"> to a <select> field if the browser doesn't support it unconditionally. This makes sense if things like the min, max, and step attributes are set. But without these things this field should really degrade to a plain <input type="text">

@dgt41 something you could probably easily fix (assuming it's still an issue)

@mbabker easy (but not optimised) fix:
replace https://github.com/joomla/joomla-cms/blob/staging/media/system/js/html5fallback-uncompressed.js#L410 with:

			if (min === max || min === "undefined" || max === "undefined") {
				$elem.prop("type", "text");
			} else {
				$elem.replaceWith( $select );
			}

This still needs a fix. The snippet posted above will apparently work for everything but IE8, because:

Attempting to change the type property (or attribute) of an input element created via HTML or already in an HTML document will result in an error being thrown by Internet Explorer 6, 7, or 8.

In that case we need to create another element, copy the attributes from the old (except the type obviously) append it in the doc and then remove the old.

Set to "closed" on behalf of @alikon by The JTracker Application at issues.joomla.org/joomla-cms/10449

after something like 3 years i hope some more new browser are used
i'm going to close it.
it can be always reopened if it's still an issue

after something like 3 years i hope some more new browser are used
i'm going to close it.
it can be always reopened if it's still an issue

after something like 3 years i hope some more new browser are used

Still doesn't change the fact certain polyfills do not behave correctly for older browsers for which Joomla claims to support. Unless Joomla is now taking the stance of "only use the browsers I want you to use, which is something released this year" and ignoring enterprise environments that don't get to day-zero upgrade browsers as they push updates.

Set to "open" on behalf of @alikon by The JTracker Application at issues.joomla.org/joomla-cms/10449

reopened

reopened

btw

Beginning January 12, 2016, only the most current version of Internet Explorer available for a supported operating system will receive technical supports and security updates. Internet Explorer 11 is the last version of Internet Explorer, and will continue to receive security updates, compatibility fixes, and technical support on Windows 7, Windows 8.1, and Windows 10.

@alikon It doesnt matter because of the stated browser support policy for j3

then we should change that policies in some way, i've quoted microsoft https://www.microsoft.com/en-us/windowsforbusiness/end-of-ie-support
i'm afraid that this issue can stay open from another 3 years without no progress ?

Then so be it. If something is a confirmed bug, realistically the only reasons to close it are because the bug is fixed or the project is acknowledging that the bug is something that it won't fix. Closing issues because "well, nobody ever came around to it so it can't be that important" doesn't send the best of messages. I've put in way too many hours dealing with PHP 5.3 specific problems, you don't get to close those issues out as "too old PHP, update you fool!" because Joomla still supports that version.

My point here is if Joomla says it's supporting a given environment and there's a confirmed bug in that environment, there's a responsibility to at some point fix the issue. Whether that's a priority is to be determined by whomever is taking the time to fix bugs in most cases. It could very well be nobody cares about fixing IE8 compat issues, but until IE8 support is dropped then the issue should stay open.

my fault here was that i've made a simply thinking that if Microsoft tell us in the 2016 don't use less than ie11 and i've missed to check browser support policy for j3

Most CMS' have a slower support policy than either the upstream software vendors (PHP, MySQL, PostgreSQL) or the clients used to interface with them (browsers). So sadly, the vendors saying "this is EOL" or "don't use this because we know it's old and garbage" doesn't apply to the CMS support policies.

(BTW, a browser or database upgrade nag would be great for a health check system like I've suggested should be part of com_admin for years now, WordPress' new Site Health feature is a good structure to duplicate)

Setting to confirmed as this is not a discussion at this point as it is has been confirmed as a bug prior to discussion tag.

Replacing the numberType function with the following do the trick:

numberType: function( self, elem ) {
    var $elem = $( elem ),
        type = $elem.attr( 'type' ),
        isInput = /^input$/i.test( elem.nodeName ),
        isType = /^(number|range)$/i.test( type ),
        min, max, step, value, attributes, $select, $option, i;

    if ( !isInput || !isType || ( type == "number" && features.types.number ) || ( type == "range" && features.types.range ) ) {
        return;
    }

    min = parseInt( $elem.attr( 'min' ) );
    max = parseInt( $elem.attr( 'max' ) );
    step = parseInt( $elem.attr( 'step' ) );
    value = parseInt( $elem.attr( 'value' ) );
    attributes = $elem.prop("attributes");

    if (min === max || $elem.attr('min') === undefined || $elem.attr('max') === undefined || $elem.attr('step') === undefined) {
        $newElType = 'text';

        $newEl = $('<input>');

        $.each( attributes, function() {
            if (this.name !== 'type') {
               $newEl.attr( this.name, this.value );
            }
        });

        $newEl.prop("type", "text");
    } else {
        $newEl = $( '<select>' );
        min = isNaN( min ) ? -100 : min;

        for ( i = min; i <= max; i += step ) {
            $option = $( '<option value="' + i + '">' + i + '</option>' );

            if ( value == i || ( value > i && value < i + step ) ) {
                $option.attr( 'selected', '' );
            }

            $newEl.append( $option );
        }

        $.each( attributes, function() {
            $newEl.attr( this.name, this.value );
        });
    }

    $elem.replaceWith( $newEl );
},

Yes, this is a confirmed issue. However, after 6 years of not finding a solution and the affected browsers being absolutely EOL and not really used anywhere anymore, Joomla 3 approaching the end of its bugfix support lifetime as well, I'm closing this one as WONTFIX.

@flashfs thank you for reporting this and yes, it sucks that we couldn't react better on this report. We will try to do better in the future. I hope you will still support us. ?