Change 884935 had a related patch set uploaded (by EpicPupper; author: EpicPupper):

[mediawiki/skins/MinervaNeue@master] Fix search input autocapitalize property on Firefox

https://gerrit.wikimedia.org/r/884935

Test wiki created on Patch demo by EpicPupper using patch(es) linked to this task:
https://patchdemo.wmflabs.org/wikis/e809a51a6a/w

Link for testing. On Firefox for Windows, I seem to get the same autocapitalize=sentences.

MDN says that the attribute is behind a flag in Firefox (and unsupported on Safari Desktop). When I enable the flag, I get autocapitalize="none" (intended behaviour here). It looks like this is an upstream browser issue, but changing the code to use attributes is probably best-practice in any case.

No apparent relation to jquery-client plug-in. Untagging.

No apparent relation to jquery-client plug-in. Untagging.

I think you missed the bit in the description @Krinkle. I'm thinking about filing an upstream bug on jQuery but wanted to check in with performance team first. It seems $( '#searchInput' ).prop( 'autocapitalize' ) returns different results in Firefox and Chrome. Since jQuery is about making browsers behave consistently these seems like a bug to me. Do you agree?

I don't think jQuery Client is what you think it is.

https://phabricator.wikimedia.org/tag/jquery-client/

You are right. Might I suggest that could be renamed #mediawiki-jquery-client ? I thought it related to jquery upstream.

I've just gone ahead and filed the upstream bug: https://github.com/jquery/jquery/issues/5202

Change 884935 merged by jenkins-bot:

[mediawiki/skins/MinervaNeue@master] Use an attribute for disabling search input autocapitalization

https://gerrit.wikimedia.org/r/884935

In T328390#8582604, @Jdlrobson wrote:

You are right. Might I suggest that could be renamed #mediawiki-jquery-client ? I thought it related to jquery upstream.

I'd rather not. It's a standalone library, not part of MediaWiki. Generally all tags on phabricator.wikimedia.org for software, relate to Wikimedia software projects. Prefixing them all with "Wikimedia-" would be redundant. We do have Upstream to track issues with upstream software.

@Jdlrobson wrote in the task description:

jQuery however is supposed to provide consistency between browsers so I wonder if this is an upstream jQuery bug?

jQuery provides consistency for web standard behaviour. autocapitalize is a standard attribute and so is made available through attr(). If we suppose there was a browser that incorrectly exposed it only as a property (due to a browser bug, or perhaps an older spec), then you could count on jQuery to offer compat and return it in those browsers as if it was an attribute.

There is no standard that says all other properties must return undefined. Doing so would be incompatible with progressive enhancement and with custom elements / custom properties that one could e.g. add to an HTMLElement yourself. E.g. accessKeyLabel is only available in some browsers. Under progressive enhancement, jQuery makes it easy to detect whether these features are available, and ensures attempts to use them will gracefully degrade in a standardised way, which for unsupported properties means to return undefined.

When a web developer calls prop(), there is not a difference between a property existing due to non-standard behaviour, or a new standard that only some browsers support, or something custom that you yourself have added to an HTMLElement before calling prop(). For example, if autocapitalize were a new feature today, you'd expect attr() to work where it can and do nothing otherwise, and not e.g. "consistently" ignore the attr call or consistently return undefined merely because one browser can't support it yet.

Test wiki on Patch demo by EpicPupper using patch(es) linked to this task was deleted:

https://patchdemo.wmflabs.org/wikis/e809a51a6a/w/