Tim Fennell [17/Mar/07 01:54 PM] Ok, from reading through various blog entries it would seem that the easiest way to fix this that doesn't significantly change how it works (i.e. cause the focus to happen much later after the field is rendered) is to wrap the current javascript in a call to setTimeout(). E.g. <script type="text/javascript">setTimeout("var z=document.getElementById('database.id'); try{z.focus();z.select();} catch(e) {}", 1)</script> Walter: I don't have easy access to a modern IE. Can you please let me know if this would/does work for you? ps. I can't believe that is in this day and age IE is still this crappy! At least just through a JS exception instead of aborting the whole page load. Sigh.

Walter Rumsby [18/Mar/07 07:37 PM] Hi There, Running some very basic tests this appears to work OK in IE7. Is the value of the timeout period significant, or is simply wrapping this in the setTimeout good enough? 1 millisecond + the execution time of the setTimeout method seems like a really short period of time for their to be a significant impact. Things work OK with my test page, but with the existing page on which I notice problems these only occur one in every 5 or so attempts to load the page. Perhaps there will still be problems with a bigger page. Yahoo!'s YUI JavaScript library provides an event management API that allows you to write something like: YAHOO.util.Event.addListener(window, 'load', function() {   // do some stuff } }; The "// do some stuff" part won't be run until the window has been rendered. Obviously you don't want to add a requirement for YUI here, but there might be some ideas in their implementation which could be useful. If you can get back to me with an answer on the significance / impact of the milliseconds value and if you want me to test with bigger pages (I only noticed this problem on the largest HTML page of my application) I'm more than happy to help.

Tim Fennell [19/Mar/07 04:28 AM] Your're right that 1ms doesn't seem like that much time. I have no scientiffic backing for that other than the fact that all the examples I found related to your Google Maps example used 1ms too ... so I /assume/ that works for IE either because it gives IE enough time in some bizarre way, or because it doesn't actually get run until the render is complete in IE's case. I'm familiar with the onload technique, but I don't really like it. I'm trying to avoid the case where (and, my bank does it this way) focus gets put into the field a significant amount of time after rendering. That can lead to nasty situations like (in my bank's case), the user having input his username and tabbed to the password field before the page completes loading, only to have the JS put focus back into the username field while the user types his password in! Bleuk. If you could test with the problem page with this solution I'd really appreciate it. The other reasonable solution might be to make the JS itself configurable so that if the version that ships with Stripes has any issues, it's not a big deal to change it without a release....

Walter Rumsby [19/Mar/07 01:37 PM] Sorry, I should have been more clear, "my test page" is the page I first noticed this problem with, i.e.: * with the old JavaScript code I notice a problem 1 in every 5 or so attempts to load the page * with the revised JavaScript code I haven't noticed any problems So at the very least this solves this problem I was having :)

Tim Fennell [27/Mar/07 04:41 AM] Fixed this using the setTimeout method as described in the comments.