Old browser's tale

I have started as a software developer in late 2015. I would say it was a pretty nice time to start because there were popular frameworks out there which were making it easier to be a front-end focused developer. However, there were hardships as well. I think everybody has a story about supporting old browsers. Nowadays, most greenfield projects need to support the so-called evergreen browsers only.

These browsers are not limited to updates that are connected to OS updates. Usually, they automatically update and allow developers to adopt new technology early. However, there are still some areas where old browsers must be supported. I have been working on such a project lately, and it is especially hard to support IE11 when I only have a Mac.

IE11 is not a bad browser, but it is old and no longer supported. In 2015 I needed to support IE9 for various banking and accounting software. I know that some of you could go further telling horror stories about “ancient” times with IE8 or even IE6. The good news is that supporting IE11 is not that hard, you just have to check everything on caniuse.com. But of course, there are some funny stories that I can share with you.

The debugger was the culprit.

So here is the situation: On this project, we have a Back-End developer, a Front-End developer and a Manual Tester. The Manual Tester needed me to add some console logs to the Front-End code, so it would make their job easier to just pop up the devtools, and read the values. So, reluctantly I did that and we to developed for weeks, leaving console.log entries throughout the front-end code and testing it thoroughly in IE11… But with the devtools always open. Our tester went on vacation, and our Business Analyst took over testing the application.

What could possibly go wrong? One morning I opened the project’s JIRA board, and I nearly got a small heart attack. This does not work in IE, that does not work in IE, etc. I was nervous. How could that happen? How the hell will I debug it on a Mac? And similar, sometimes more obscene questions raced through my mind. I was convinced that everything should work, so naturally, I asked our BA to please open the devtools in IE11 and let’s check the console for errors or something. And everything worked like a charm.

So let’s repeat it with the devtools closed. Nothing works. Open it and it works again. A quick search and the answer became pretty obvious: in IE11 the console object is only created when the devtools is open. Therefore, if it is not open it can block javascript execution.

Triggered much?

So there is an IE11 issue with forms and accented characters, which can be especially annoying with Angular reactive forms. This bug is very simple: whenever an input field has an accented character in its placeholder, IE11 fires an input event. Why is that a problem? Well, in an Angular reactive form, an input event marks the form as touched, therefore, every input field’s validation error is displayed immediately.

It makes it harder when you have localisation, and you cannot be sure. Would this always occur? This is one problem I refused to hack around. I imagine that it could be done with checking the browser, the placeholder value and if it is the first input event then marking the form as untouched again. But that’s just too hacky, and I don’t think it would worth investing time to come up with a hacky and hard-to-understand solution.

Tyrannical buttons

I am usually very careful with using third-party libraries and UI components whenever I need to support IE11. The reason is, that most of the third-party libs never supported it or maybe just dropped support. I can’t blame them, but it might make my job harder.

I was working on a project that was using a third-party UI component for displaying tabs in an application. My predecessor chose the library, however, it supported tab focusing mechanism using HTML <button> elements. It was usable, looked okay and had acceptable accessibility. The problem started when the so-called ‘closable’ tabs used small “X” SVG icons with click handlers inside the <button> tags. Those small “X” buttons never got the events in IE, not even the hover events.

So, I needed to remove this UI component lib, and I needed to develop the tabs from zero, using <div> elements and styling them to look exactly like the previous ones. After that, I needed to replace all the existing tab components in the application. It took several hours. I also set the tabindex property to 0 for the divs, so at least keyboard navigation works. I also added role="button" to these divs, so at least the application stayed accessible.

Please, stop using IE11

I have had my share fo cross-browser compatibility issues working as a Front-End developer in the past 5 years. These obsolete and old browsers that we need to support sometimes are huge security risks and they don’t get updates anymore. That is scary, knowing, that certain banks and bureaucratic bodies still use insecure browsers and even operating systems (I saw Windows Vista during a screen share in late 2019) in their everyday work.

These projects that I work on nowadays are modernisation projects. Rewriting old software written in a very old programming language to modern web apps. These are usually greenfield projects, however, if we need to support IE11, at a certain point we won’t be able to use the latest technology. IE11 support is opt-in since Angular 9 and it is just a matter of time when will it be completely dropped. Many component libraries don’t even bother supporting IE11, which makes it hard to find one that will work properly after an update.

These projects also cost you a lot of money. I am confident, that updating your browsers to Microsoft Edge would be much cheaper than Front-End developers spending days investigating and fixing IE11 bugs. In my opinion, refusing to update to an evergreen browser in 2020 is not a sane business decision.

Do you have IE11 support stories? Share it with me on Twitter.