Mobile Keyboard Complexity

Early this week, an issue I found using GitHub took my interest. It was about Keyboard input for mobile.

The problem

Have you ever been filling in a form using a mobile device and it auto-capitalizes your password or some field where it makes utterly no sense to have assistance?

Well for many years the internet was not designed for mobile devices. Laptops were huge clunky things and connecting to the internet was done via cable, so were more portable desktops than things designed for the lap.

So new attributes were added to retrofit the description of new intrinsic behaviours for HTML.

The real problem is not these changes or an imperfect history. It seems to be that developers are running off to find out the new shiny things, before considering the built-in.

A wider problem that the above is that there is so much to know and remember that

Frontend is a specialism, not a game. It impacts your users every bit as much as using the latest language features.

Rabbit holes

The original poster of the issue had posted a link to Stack Overflow, an often-touted font for programming knowledge.

Idealized workflow

1. Find where the edit needs to take place.
2. Add autocapitalize=none to the input element there.
3. Offer a patch with your genius ideas.

Rarely is anything, outside a small project, as simple as it first seems.

Real-world impacted workflow

1. Find the component library.
2. Find involved third-party code the component library uses.
3. Update both and test outside of the project you want to fix.
4. Submit patches, so that you can discuss with strangers, your proposed changes.
5. Iterate until changes are made acceptable, or if they cannot be made acceptable, define new code to overcome this issue.
6. Submit patches, so that you can discuss with strangers, your proposed changes.
7. Find where the edit needs to take place
8. Add autocapitalize=none to the input element there
9. Submit patches, so that you can discuss with strangers, your proposed changes.

Even this ignores testing, linting, beloved rituals of each project.

Levels of testing.

To throw further spanners in the works, I had only been testing that this attribute was present as none of the code libraries had tests. This is an incredibly shallow testing strategy.

I had verified the attribute should do the job with the Mozilla Developer Network HTML documentation about the autocapitalize attribute. I had verified it was present. I had not yet put this in a place that a mobile device could access the work to test that not only was the attribute present, but that it stopped auto-capitalization, which after all is the goal.

This is something to think about. Not expanding unit-tests, or manual tests to ensure that components render and behave. That is a multi-browser, multi-device task. But to consider the many levels of testing to ensure something is working, rather than should work.

I tested this in an android emulator, and it worked first-time. Sigh of relief.

When I finally put this on my phone, after submitting a PR and noticing a deployment preview, it did not work.

Complexity of systems

I was beginning to get a headache, but I knew completing this task would bring me some knowledge, however vendored, which might help me in work later.

The first thing I wanted to check was that the mobile was getting the same version of the page as my computer.

I performed several checks that this was the case, and nothing quite simple, like a missing file from Git commits was the cause of the inconsistency.

I cannot count the number of times I or someone I have worked with has forgotten to commit a file that needs to be updated and otherwise good work could not be reproduced.

I set about dissecting the state between my phone and the Android mobile phone emulator, and it turns out I had a program from Microsoft, which was providing a keyboard for me.

When any mobile browser asked for the onscreen keyboard, it was not the android keyboard, but a specific vendor keyboard, which seemed ignorant of this autocapitalize attribute, and instead has a setting within itself to force capitalization on or off.

The solution

Luckily switching back to the Google UK keyboard worked, and I could now submit my patch, schedule this blog post, and move on. At some point I would like to schedule contacting Microsoft to ask why their Keyboard breaks the expected behaviour of the web. I wonder if it is in-fact Google Android browser and Chrome browser that is not sending this information, but I had also checked mobile Firefox and found it also exhibited this behaviour when using Microsoft keyboard.

As a Final note, I have checked using mobile Safari that it similarly does not autocapitalize. Sometimes supporting stock device behaviour is the right for-now thing to do. I can always iterate later.