A388

SPOKE TOO SOON

It appears that Apple decided to finally fix the issue in the latest iOS 14 update which came out ~2 weeks after I wrote this.

In one of my projects I was using flatpickr as a date/time picker and I've been slowly removing it in favor of the built-in browser types. All was going well, except one of the forms I updated recently is primarily used by our users on their iPads. After the update was published I started getting hammered with error reports from users.

Turns out iOS Safari is stupid when it comes to datetime-local fields. It validates the field's value as yyyy-MM-ddTHH:mm, but it generates the value from its picker as yyyy-MM-ddTHH:mm:ss.fff. Since all you get is a picker control, there's no way to correct the value and Safari traps itself into a never ending invalid state.

To fix the issue, you have to use JavaScript to correct the value after its generated, which defeats the purpose of just using the browser's built-in functionality. Using jQuery and Date.js you can do something like this:

$("[type='datetime-local']").on(elementBlur, (
    e: JQueryEventObject) => {
        const $field = $(e.currentTarget);
        let oldValue = $field.val();
        const lastPeriod = oldValue.lastIndexOf(".");

        oldValue = oldValue.substring(0, lastPeriod);

        const newValue = Date.parse(oldValue).toString("yyyy-MM-ddTHH:mm");

        $field.val(newValue);
    });

What makes it worse is that it's been an issue since iOS 10 released in September of 2016. All Apple has to do is fix the format of the generated value. Arguably a very simple fix in the grand scheme of things, yet its been ignored for four years now. Apple has succeeded in becoming the Microsoft of the old days, and Safari has succeeded in becoming the new Internet Explorer.

That is one of the reasons why I think iOS Safari is worthless, but that will never change on iOS since Apple likes to be in absolute control.

In my Arex388.AspNetCore NuGet package I have an AntiFavicon middleware that would intercept requests to /favicon.ico and return a 404 early in the request processing pipeline. At some point I forgot about it and in one of my bigger projects I implemented a different fix that I found on this StackOverflow question.

It is a much better approach than my middleware because it stops the browser from making the request from the very beginning. All you have to do is add this link element to the head element:

<link rel="icon" href="data:;base64,iVBORw0KGgo=" type="image/png" />

I'm going to remove my interception middleware since this is the better approach. Thank you Diego Perini for providing this solution!