Cross-browser in 2011?

Date / aug 4, 2011 / Posted by / anhkiet / Category / Uncategorized

Disclaimer: I may not know what I’m talking about.

I never thought that writing code to handle browser differences in 2011 would be that painful. Maybe I was trying to do something out of the ordinary, but as a spoiled brat, I expected things to just work.

With our web application(s), we have a concept of account impersonation, similar to su. This allows our help team to login as customers and investigate issues. So I thought it would be a great idea to implement a toolbar that floats at the bottom of our admin page, making this process even easier. It’s a very simple idea and the UI needed three measly text fields to work: identity, password, and who you want to impersonate. Those who know me will know that I eat text fields for breakfast – so no problem there. And finally to top it off just because I am so awesome, I even took the liberty to include a button.

This was when brilliant idea #1 struck. Simplicity! There’s no need to show all three fields all the time. If the browser has a login manager, it would render the credential fields nearly useless. So why not show an abbreviated version like this:

The user would click the plus sign to show the fields to enter their credentials. This cleaner UI came with a cost, an additional click (yuck!).

Then came brilliant idea #2. Upon focus to the “login as” field, why not automagically expand and show the other fields? If the user already had their credentials saved, then it would remain collapsed. So brilliant!

The original goal was to create a self-contained script that would inject the HTML form into the page. This means it can be included on any page in the existing app with minimal code changes. This is where I ran into the first problem. Firefox’s password manager will not fill login forms generated by JavaScript. Someone even submitted a bug for it. Chrome works just fine. After trying various failed solutions, I begrudgingly generated the HTML as part of the page content.

After talking to our help team, it is apparent that they go through this impersonation process a lot. From our admin page, I thought it’d be useful to fire up a new window when they entered impersonation mode. In their workflow, once they’re done with helping a user, they can simply close out the window. Naturally and naively, I took the target=”_blank” approach,

  <form id="adminSudo" action="/some/login/url" method="post" target="_blank">
    <input id="login_email" type="text" name="login_email" />
    <input id="login_password" type="password" name="password" />
    <input id="other_email" type="text" name="other_email" />
    <input type="submit" value="Polyjuice" />
  </form>

This time, it’s Chrome’s fault. Everything works as expected except that it does not ask to “save your password.” Sigh. After some googling around, the answer was that I needed to use *drum roll* iframes! The page will use a hidden iframe and set the form’s target to the iframe’s id:

  <form id="adminSudo" action="/some/login/url" method="post" target="dummyTarget">
    ...
  </form>
  <iframe src="#" id="dummyTarget" name="dummyTarget" style="display:none"></iframe>

This change enabled Chrome’s password manager to kick in and save the password for us. Now, you will need to detect when the iframe is loaded to launch a new window,

    // Somewhere in the ready block
    $('#dummyTarget').load(function() {
        window.open('https://www.somelocation.com', '_blank');
    });

Was it silly of me to think that this would actually work? Cross browser problem again! This time more subtle than before. In using src=”#” for the iframe, Chrome will trigger a “loaded” event for the iframe on the initial page load. Firefox will not. So I tried two more alternatives, about:blank and leaving it empty. Here are the results, “y” means the event was triggered,

At this point, I threw my hands in the air and took a completely different approach. More JavaScript in conjunction with src=”about:blank”, the recommended way of representing a blank iframe. I would only hook into the loaded event during the first form submission. This way, I delayed the hook and bypass the initial trigger completely. The solution was something similar to the following:

  <form id="adminSudo" action="/some/login/url" method="post" target="dummyTarget">
    ...
  </form>
  <iframe src="about:blank" id="dummyTarget" name="dummyTarget" style="display:none"></iframe>

    $(function() {
        var sudoHandlerSet = false;
        function sudoSubmission() {
            if (!sudoHandlerSet) {
                sudoHandlerSet = true;
 
                $('#dummyTarget').load(function() {
                    window.open('https://www.somelocation.com', '_blank');
                });
            }
 
            return true;
        }
 
        $('#adminSudo').submit(sudoSubmission);
    });

I was simply amazed at all the trouble I went through for this to work. I would rant more about the styling and animation (jQuery) issues, but it would have made this post too long. Of course, this is nowhere near the nightmare that is IE6, but with the extra functionalities we are pushing to the browser, shouldn’t we expect more from browsers these days?