Tag Archives: Browser

About browser-specific issues.

Adding support for Mozilla’s Extended Support Releases

Kerika works well on modern browsers, but we still occasionally get folks trying to sign up using an obsolete or very old browser. (For example, Internet Explorer is obsolete; you need to use Microsoft Edge.)

To handle this, Kerika checks the browser information returned by your computer when you try to sign up or login, to weed out the unsupported old browsers.

We have expanded this now to make sure organizations that are using Mozilla’s Extended Support Release (ESR) program to manage their Firefox deployments are not hindered.  Based upon this chart from Mozilla:

It looks like ESR 60.3.0 is equivalent to regular Firefox 63, so we now let people using this ESR (or newer) to use Kerika.

So long, Internet Explorer 11

We cannot continue to support Internet Explorer 11 any more, for the simple reason that Microsoft itself doesn’t want to support IE 11 any more.

All of Microsoft’s browser focus is on their Edge browser, which means that as newer HTML5 features and standards get adopted by the browsers, these are going to show up in Edge, not IE 11.

And since Kerika is a pure Web app, one that requires you to download no software of any kind, including browser add-ons and plug-ins, we really need to make use of the latest HTML5 goodies that the browser vendors provide.

These goodies are going to be available only on Chrome, Firefox, Safari and Edge, and that’s where Kerika is gong to work best.

Tripped up by an unkept Promise

As you know, Kerika is a Web Application: everything runs inside a browser, without the need for any plug-ins or add-ons.

We achieve all this with a ton of JavaScript code (and a sprinkle of SVG, for our Whiteboards.)

One, significant, disadvantage of JavaScript is that it is “single threaded”: two bits of script cannot run at the same time; they have to run one after another.

So while Kerika is running inside a browser on your laptop, our JavaScript has to share a thread with lots of other stuff that’s going on, such as painting, updating styles, and handling user actions.  All of this has the potential to slow down Kerika, while the JavaScript code waits for something else to finish.

To get around this, we used JavaScript’s Promise function: this let Kerika’s code get going with its normal business while waiting for other browser functions to finish.  What we didn’t expect, however, was that the Promise function isn’t supported by Internet Explorer 11. (Although it is supported in Microsoft’s Edge browser.)

This caused problems for all of our Internet Explorer 11 users — people using Chrome, Safari, Firefox or Edge were unaffected.  We finally figured out what the underlying problem was, and did a workaround using a polyfill, which is a way to provide new functionality in older browsers that don’t support it natively.

Bug, fixed: copy-paste of card details in Internet Explorer

Internet Explorer continues to be slightly offbeat in its behavior, and this trips up our testing since it still has some quirks that are not found in Chrome, Firefox or Safari.

One bug that one of our Norway-based users found was that he couldn’t copy the details of a card using the Ctl-C key combination while using Internet Explorer, without going into the edit mode of the card details.

We fixed that. Ctl-C and Ctl-V should work much better.

Snacking on our cookies

Ever wonder how many cookies Kerika sets when you are logged in, and why?

Here’s the answer:

Kerika's cookies
Kerika’s cookies

The first cookie, called “BAYEUX_BROWSER”, relates to our use of the CometD communications protocol for ensuring that you always get real-time updates whenever you are looking at any Kerika board, no matter which browser you are using.

CometD leverages WebSocket when it can (because it’s the most efficient web messaging protocol), and makes use of an Ajax push technology pattern known as Comet when using HTTP.  Most modern browsers support WebSocket, but we still have some older versions of Internet Explorer out there that don’t support WebSocket.  This cookie helps us track whether your browser supports WebSocket or not.

The next couple of cookies are used simply to keep track of your Kerika session.

The fourth cookie, “i18next”, is really not used much right now, but we hope to make greater use of it in the future.

Right now Kerika is available only in English, but the code was always written to make it easy for us to create versions in other languages, e.g. Spanish, Chinese, etc.  This process is called “internationalization”, and is usually abbreviated as “i18n” by us nerds.

The last two cookies, “last-selected-auth-service” and “tabs”, are used to remember what you were last doing when you were logged into Kerika on that computer: when you log back in, after having logged out, these two cookies help us restore your view of Kerika to exactly where you left off.

As it says on our website, we are committed to transparency, so now you know everything about our cookies.

Want to learn more? Check out our privacy policy.

AdBlock was messing up our website (even though we don’t serve ads!)

We discovered recently, to our considerable annoyance, that it is possible for AdBlock to mess up our website in a really serious way, even though we don’t serve up any advertisements of any sort (and never have.)

Here’s what was happening: when you use AdBlock, you have the option to add various lists of advertising sources. (You can find them here.)

One of these lists is from someone called fanboy.

If you subscribed to fanboy’s EasyList, for example, Kerika’s sign up page would not display the buttons for Kerika+Google and Kerika+Box:

AdBlock problems
AdBlock problems

(The same problem showed upon the Login page as well.)

It turns out that the EasyList filter uses JavaScript classes called social-media-header’ and social-media-button,  social-button and soc-button which were also the names of classes that Kerika was using.

The conflict caused Kerika’s signup and login buttons for Kerika+Google and Kerika+Box to not appear for Chrome and Firefox users who had AdBlock installed.

It took a while to figure out this was the cause.  We are not fans of fanboy.

Bug, fixed: board descriptions in Internet Explorer 11

We found a bug that was causing problems for users who wanted to edit/update their board descriptions, using Internet Explorer. We fixed that.

In case you are wondering where the board description is found in the first place, here’s how you can edit it:

Click on the gear icon that appears on the top-right corner of every Task Board, Scrum Board or Whiteboard, and then chose the Settings tab:

Editing board descriptions
Editing board descriptions


By default, the board description field will be empty, naturally, but if you are one of the Board Admins (or the Account Owner), when you move your mouse over the Description field you will see a pencil icon appear (highlighted in red, above), and clicking on that will let you add a board description.

Adding a board description
Adding a board description


Board descriptions can be up to 180 characters long, and as you type the system will automatically let you know how many characters are left for you to type. (Yes, Twitter-style.)

Board descriptions are going to be very useful in the future as we make some changes to our user interface and search functions.

We are going to drop support for Internet Explorer 9

We have been one of the last jazzy Web apps out there that was still running on Internet Explorer 9, but that’s going to change: with our next release, due in a month or so, we will be asking Internet Explorer users to upgrade to IE10 or later.

The main reason for this change is that all “modern” browsers — and IE9 qualifies as “modern” only when it stands next to IE8 — do a lot of work within the browser itself that Kerika currently does: stuff like managing and manipulating the DOM structure of the Kerika application.

This means that the Kerika client-application — the bit that you actually see and use in a browser — is unnecessarily complicated, and somewhat slower, than it needs to be, because we are doing some work that IE10+, Chrome, Firefox and Safari all do within the browser itself.

Dropping support for IE9 will enable us to provide a faster user experience, with less complexity in the code.

Internet Explorer remains the odd man out on tablets

We have been putting in a ton of effort to improve the Kerika user experience on tablets: while Kerika runs OK in the Safari and Chrome browsers on iPads, the experience is somewhat uneven across other tablets, particularly Android and Windows tablets and “convertibles”.

It’s a little frustrating to find so many oddities about Internet Explorer 11 (the latest, greatest version from Microsoft) when it comes to Windows 8.1 tablets and convertibles.

Looking at our internal Scrum Board for our tablet work, we are struck by the many ways in which the touch and swipe gestures in Internet Explorer are different from the Webkit-based browsers (Safari and Chrome):

IE11 problems

I met my old lover
On the street last night
She seemed so glad to see me
I just smiled
And we talked about some old times
And we drank ourselves some beers
Still crazy after all these years
Oh, still crazy after all these years