views:

875

answers:

2

I'm working on login page written as a JSP. It's pretty simple but behaves differently in IE8 and Firefox (big surprise there). I have not tested this is other browsers yet.

I could probably hack a fix in with some Javascript but I was looking for more information about the behavior, before I just implement a workaround, with hopes of a cleaner fix and avoiding this problem in the future.

The server-side generated HTML snippet in question is this:

<form name="member_session_info" method="post" autocomplete="off" action="/membersession" onsubmit="return validate_form()" >
      <input type="hidden" id="memberSessionAction" name="memberSessionAction" value="" /> 
      <input type="hidden" name="homePage" value="/2009/aas/aas_home.jsp" />
      <input type="hidden" name="memberLandingPage" value="/2009/aas/aas_member_landing.jsp" />
      <input type="hidden" name="memberProfilePage" value="/2009/aas/aas_member_profile.jsp" />
      <input type="hidden" name="passwordRecoveryPage" value="/2009/aas/aas_password_recovery.jsp" /> 

      <input id="uname" class="text xsmall right" name="username" value="USERNAME" onclick="checkClickUser()" onKeyPress="checkKeyPress(event, 'login', sendProfile)" style="width: 220px;" type="text">

      <input id="pass" class="text xsmall right" name="password" value="PASSWORD" onclick="checkClickPassword()" onKeyPress="checkKeyPress(event, 'login', sendProfile)" style="width: 220px;" type="password">

      <a href="javascript:sendProfile('startPasswordRecovery');" class="xsmall">FORGOT PASSWORD</a>
</form>

and the Javascript that backs it up is:

<script type="text/javascript" language="JavaScript">

function validatePost(code, doAlert)
{
    postValid = true;
    return postValid;
}

function sendProfile(action)
{
    document.getElementById("memberSessionAction").value = action;
    document.member_session_info.submit();
    return false;
}

function initializePage()
{
}

function validate_form()
{
    return false;
}

function checkClickUser()
{
    var username;

    username = document.getElementById("uname").value;

    if (username == "USERNAME") {
     // Clear the field since it's the first time
     document.getElementById("uname").value = "";
    }

    return true;
}

function checkClickPassword()
{
    var username;

    username = document.getElementById("pass").value;

    if (username == "PASSWORD") {
        // Clear the field since it's the first time
        document.getElementById("pass").value = "";
    }

    return true;
}

function checkKeyPress(event, object, func)
{
    var keycode;
    if (window.event) keycode = window.event.keyCode;
    else if (event) keycode = (event.which) ? event.which : event.keyCode;
    else return true;

    if ((keycode == 13)) // check for return
    {
        func(object);
        return true;
    }
    return true;    
}

</script>

The basic symptom is this: If you use tab to navigate from the username field to the password field in the form, the password is correctly highlighted and cleared in FF, but not in IE8. In IE8, tabbing to the password field moves the cursor to the very beginning of the password box, leaving the default value (PASSWORD) in place, and not clearing it.

Any idea on why this occurs? Is this a known bug or inherent flaw of IE8 that I will just have to hack around, or can I just add a wee bit of code somewhere to handle IE8 more correctly?

If the problem isn't clear from my description I can attempt to elucidate or just throw up a screenshot/video clip, or upload a static copy of the HTML somewhere. (If the last one, I could use a recommendation of a good site or service to do this since the actual site is still in dev and not availabile to the web yet.) Thanks!

Edit: Changing the onclick property to onfocus fixed that problem, but brought another one to light (see my comment @David). Could this be related to the way that checkKeyPress is written? It's a function I borrowed from elsewhere in the site. In particular I'm wondering if changing its return statements could be the fix. Maybe it shouldn't return true/false/anything at all?

Edit 2: I removed the checkKeyPress method entirely to see if that was causing the problem, and it changed nothing.

The full source is here. The div that focus randomly jumps to is the one between the two "global nav" comments, at the very top of the body. Still no idea why it's happening. To see if the focus was somehow just getting reset, I added another div above the one that focus is jumping to randomly, expecting focus to start jumping to the new div instead. It didn't. It still switches focus to the div with the image in it. I am utterly befuggled.

+2  A: 

What if you put the check in onfocus instead of onclick? Tabbing to a field technically isn't a click anyways.

David
Good point - I didn't write the original page, I'm only updating it. I'll give that a shot.
Matt Ball
Okay, so that fixed one problem but brought another one to light: now, when typing in either field (in IE8) that input will randomly lose focus, so I actually have to click back in to keep typing.
Matt Ball
@Matt: I took your supplied code, changed `onclick` to `onfocus` for the two input fields and I'm not seeing your lost focus issue here.
Grant Wagner
+1  A: 

Since the lost focus seems to happen every 6000 milliseconds, I'd point the blame somewhere at expandone()/contractall() in /js/qm_scripts.js.

Your login form is in the "dropmsg0" div, causing it to be briefly hidden and redisplayed every 6 seconds. The textboxes lose focus in IE8 when hidden. I'd either rename the div to exclude if from the ticker, or modify the ticker script to not run when there's only one dropmsg div.

David
+1 By golly, you nailed it. Don't even ask me why qm_scripts.js includes the ProHTML ticker script. You don't want to know.
Matt Ball