Web 3.0, 6 Bladed Razors, 7 Minute Abs » Web Browsers

Don’t Let the Door Hit You Onunload and Onbeforeunload

Zach Leatherman — Wed, 23 Apr 2008 04:51:08 +0000

Many people attempt a last ditch effort to save page state in the browser by using the onunload or onbeforeunload events. This has been studied at great length by Patrick Hunlock, who uses the perhaps now common knowledge of using a Synchronous Ajax call to perform the page state save.

Another use for the onbeforeunload event to allow the user to cancel the action that initiated the user leaving in the first place. Gmail uses this technique when the user is in the middle of writing a draft of an e-mail and attempts to leave the page.

Gmail's pops up this prompt when the user attempts to leave the page while drafting an email.

Worthy to note, however, is that Opera doesn't fire the unload event when the browser refreshes the page, or uses the back/forward buttons to browse off of the page (I had no success with the fix posted in the comments on that page). What's worse, Opera never fires the onbeforeunload event. This creates a serious problem with attempting to save page state prior to a user leaving your page.

Browser support aside, I believe that the onbeforeunload prompt is not an ideal way to protect the user from lost work (or unsaved page state). Humanized has argued, and I agree, that an undo operation is much easier on the end user than a warning message. The strange thing is, Gmail could save the draft in a synchronous Ajax request in the onunload event. They aren't using the prompt to save Opera users from losing their drafts, since the Opera web browser doesn't even fire the onbeforeunload event. (Interestingly enough, they are using some sort of browser history management to fire a warning to the user when they press back, or forward, in Opera -- but Reload can't be caught using this method, so your could draft email be lost).

From a User Interface design standpoint, I would recommend just sticking with onunload. You can still perform your synchronous Ajax call in the method to save the state of your page, so that the user can later resume their state or undo the operation. (Except for Back/Forward/Refresh in Opera, until they support a better onunload or any onbeforeunload). The onbeforeunload prompt is an unnecessary evil, and doesn't do much besides annoy the end user with another warning message and a mouse click.

Technorati Tags: JavaScript, onunload, onbeforeunload, Ajax, Undo, Opera, Gmail

Minor Annoyances with Firefox Development

Zach Leatherman — Sun, 23 Mar 2008 20:39:40 +0000

When you're developing web applications in Firefox, do you find yourself constantly clearing your cache? Cache is a useful facet of web browsing for everything but the continuous testing environment of web development. Here's a nice alternative so that you don't have to disable your cache entirely:

Use the Firefox Plug-In called (humorously enough) JohnnyCache. I added the pattern 'http://localhost/' to my preferences and now I don't have to worry about cache on my local machine anymore. Simple, easy, effective.

Now only if I knew how to disable the Firefox preference that autopopulates form fields with default values when F5 is hit to refresh the page. Try creating a page with a single text field, type a value into the form, and then hit F5 to refresh the page. Your value will be prefilled into the form.

I find myself always hitting "CTRL+L" (goes to the Location Bar) and "Enter" to avoid that one. I looked through about:config, but only found: signon.prefillForms (related to usernames and passwords), and browser.formfill.enable (related to autocomplete dropdowns for forms, not default values).

Anyone know an easier method?

Problems with Looping through window.setInterval

Zach Leatherman — Mon, 24 Dec 2007 03:46:24 +0000

Look at this code. What do you expect to be the outcome?

var d = new Date();
var r = [];
for(var j=0,k=2;j) {
window.setInterval(function()
{
var next = new Date();
r.push(next.getTime() - d.getTime());
},1000);
}

Every 1000 milliseconds (1 second), the r array should have three delta timestamps added into it (one for each interval set in the for loop). In FireFox, however, there are exactly nine delta timestamps added per second. If you set k=10, the result is one hundred delta timestamps per second. If anyone has the answer, I am curious, even if the result is that I'm an idiot. It seems to work correctly in Internet Explorer 7. Thanks for your help, internet.



Forward Compatibility and JavaScript
Zach Leatherman — Fri, 02 Nov 2007 01:53:20 +0000
Many developers (myself included) complain endlessly about the problematic ECMAScript implementation that Internet Explorer uses called JScript.  And after reading one such very detailed complaint in the comments on Dave Massy's website at MSDN, and reading Chris Wilson's post about ECMAScript 3, it has become increasingly obvious of Microsoft's opinion on the subject of Forward Compatibility with JavaScript.  It's something they keep pounding their fists on the ground about, how they are adamant that new versions of their browser not "Break the Web."
Of course, "Breaking the Web" refers to the amount of code on the internet today that is an equal and opposite reaction to the broken bug-ridden JavaScript implementation of their browser.  It describes the unimaginable future in which Internet Explorer fixed the many well documented intricacies of JScript and thereby ruins the code that was originally written to support the problem.  What a conundrum.
But haven't we already been through this problem?  Isn't this the same exact thing we saw in the early days of CSS?  And how did the major browser players react?  By implementing both a Quirks and Standards mode for CSS through DocType switching.  Now my question is:
Why haven't we seen a Quirks and Standards Compatibility Mode for JavaScript?
I'm not necessarily encouraging the Quirks and Standards modes to be toggled with the DocType (as with CSS), but why not have these two modes?  To enable your site to use the Standards mode of JavaScript, the browser might require a certain DocType to be declared, or it might require a different script type in the browser:


 type="text/javascript" mode="standards">



Either that, or I could just use Base2.
Technorati Tags: JavaScript,  ECMAScript,  Quirks Mode



Cross Domain XHR with Firefox
Zach Leatherman — Thu, 30 Aug 2007 23:40:20 +0000
By now know you know that trying to do an XMLHttpRequest (XHR or AJAX) call to a domain that is different from the domain of the hosted JavaScript in Firefox will throw an exception.
Error: uncaught exception: Permission denied to call method XMLHttpRequest.open
If you don't want a history of the past solutions, page down to see the final solution.
The web has solutions to this problem, but most of them involve changing your JavaScript code, which I thought to be less than ideal.  A common solution involves setting the UniversalBrowserRead security property in your JavaScript code [Dion Almaer, of Ajaxian fame]:


netscape.security.PrivilegeManager.enablePrivilege('UniversalBrowserRead');



The problem with that solution (obviously) lies in single browser proprietary JavaScript polluting your code.  And you have to set this property inside the scope of any usage (ie: inside your library file that does your AJAX calls and inside your callbacks, etc).
Why can't it just be as easy as Internet Explorer?  They just pop-up a little security dialog asking you if you want to allow this access (which is also what the enablePrivilege function does as well).
Another solution involves setting the capability.policy.default.XMLHttpRequest.open preference inside your prefs.js Firefox preference file [Mike Dirolf].  This worked as desired and allowed the AJAX call, but anytime you attempt to access the resulting XML you received a nice exception as well.  It turns out this is the solution we wanted, it's just incomplete.
The Final Solution

Close Firefox.  It will overwrite your changes to the prefs.js file if you have it open.
Optional step: This approach will open up your Firefox security quite a bit, so I'd recommend setting up a separate profile in Firefox to use when testing.  It will not pop up a security dialog when a cross-domain AJAX call is made.
Find your prefs.js file.  In Windows, it is typically located in the C:\Documents and Settings\{YOUR_USERNAME}\ApplicationData\Mozilla\Firefox\Profiles\{YOUR_TEST_USER_PROFILE_ID}\prefs.js
Open it up and add the following lines:


user_pref("capability.policy.default.XMLHttpRequest.open", "allAccess");

user_pref("capability.policy.default.CDATASection.nodeValue", "allAccess");

user_pref("capability.policy.default.Element.attributes", "allAccess");

user_pref("capability.policy.default.Element.childNodes", "allAccess");

user_pref("capability.policy.default.Element.firstChild", "allAccess");

user_pref("capability.policy.default.Element.getElementsByTagName", "allAccess");

user_pref("capability.policy.default.Element.tagName", "allAccess");

user_pref("capability.policy.default.HTMLCollection.length", "allAccess");

user_pref("capability.policy.default.HTMLCollection.item", "allAccess");

user_pref("capability.policy.default.Text.nodeValue", "allAccess");

user_pref("capability.policy.default.XMLDocument.documentElement", "allAccess");

user_pref("capability.policy.default.XMLDocument.getElementsByTagName", "allAccess");

user_pref("capability.policy.default.XMLHttpRequest.channel", "allAccess");

user_pref("capability.policy.default.XMLHttpRequest.open", "allAccess");

user_pref("capability.policy.default.XMLHttpRequest.responseText", "allAccess");

user_pref("capability.policy.default.XMLHttpRequest.responseXML", "allAccess");

user_pref("capability.policy.default.XMLHttpRequest.send", "allAccess");

user_pref("capability.policy.default.XMLHttpRequest.setRequestHeader", "allAccess");





This code was copied (with the exception of 1 line) from a source repository at [kryogenix.org]

used in jackfield.  It wasn't intended to be used for this purpose, but it works.
If you still get Error: uncaught exception: Permission denied to call method _________ errors, you can add the method to your prefs.js.  I would appreciate a comment with any commonly used methods not included above.  Thanks.
Technorati Tags: Firefox,  Cross Domain,  AJAX,  XHR,  JavaScript



Screen Readers and Listening at the Speed of Sound
Zach Leatherman — Fri, 18 May 2007 00:23:38 +0000
Here is a presentation given by a guy named Victor Tsaran on how he personally uses screen readers to browse the web.  As web developers, accessibility is an important aspect of our work and cannot be ignored.  How many websites have you browsed that had flash navigation?  If you're not a web developer, you need to skip ahead to time stamp 25:44 to see the mega-fast speed this guy uses the screen reader at.  I couldn't understand a single word coming out of my speaker.



I-Frame Shims or How I Learned to Stop Worrying and Love the Bomb
Zach Leatherman — Tue, 24 Apr 2007 21:51:55 +0000
So again, I show up late to the party.  IE7 is already out, but my target customers are still using IE6.  So today, boys and girls, we're going to discover the magical world of using I-Frame shims to hide those bleeding heart select boxes from showing through our layered elements.
Typically, when creating an I-Frame shim, you're going to create the i-frame dynamically using document.createElement.  Let's start out with some successful code.


var iframeShim = document.createElement( 'iframe' );

iframeShim.setAttribute( 'src', 'javascript:false;document.write(”");' );

iframeShim.setAttribute( 'frameBorder', '0' );



Now for some caveats you might have encountered with code not matching the above:
I-Frame frameBorder attribute

Are you trying to get rid of that nasty i-frame border in Internet Explorer 6 (IE6)?  Tried CSS properties?  Tried setting the frameBorder attribute?  It turns out that when setting the frameBorder attribute, the name of the attribute is case sensitive.  Using frameborder will not work correctly, but using frameBorder (with a capital B) will give the desired result.  [Source: FlashApe]
HTTPS and I-Frame src attribute

Is your page hosted on a secure domain (https instead of just http)?  Is the dynamically created iframe causing the following error message in Internet Explorer?
This page contains both secure and nonsecure items.  Do you want to display the nonsecure items?
Some have suggested that changing the src attribute to point to a blank html page with no content is the solution, but that's an extra http request on your page that is unnecessary.  Others have suggested that that changing the src attribute to javascript:false works.  It does, in fact, but writes the text 'false' to your iframe content.  Others have suggested javascript:void(0) as your src attribute value [Source: ewbi.develops], but some Internet Explorer clients still have secure and nonsecure items alert popup.  I have not figured out the factors that separate these Internet Explorer clients.  
Update: The correct solution is in face setting "javascript:false;document.write(”");" as your src value, as I found in the jQuery BlockUI plugin.  This is a silver bullet fix that will avoid all the problems I have encountered.



JavaScript Code Coverage Tool for Firebug
Zach Leatherman — Wed, 18 Apr 2007 20:08:06 +0000
Download FirebugCodeCoverage-0.1.xpi
Recently, I've become interested in client side automated testing tools.  When I found the Selenium plug-in for Firefox, I was blown away.  I can record actions in my browser and play them back!  No more manual testing of JavaScript code!
Researching a little bit more about automated testing tools led to the discovery of a metric called 'Code Coverage', a statistic that gives you a percentage of how much of your code executed during a certain period of time (usually while your automated test was executing).
Of course, I immediately thought of Joe Hewitt's Firebug extension for Firefox, which includes a feature for JavaScript Profiling.  The Profile feature of Firebug was similar to a Function Entry Code Coverage report, so I decided to modify the feature and release an add-on for Firefox that showed (at a file level) a list of which functions executed and which functions did not.

So, now, to test my JavaScript code coverage, I will write automated tests using the Selenium IDE plug-in for Firefox, hit the Code Coverage button in Firebug, and try to get my Code Coverage statistics in the upper 90%'s.
Screenshot Example of running the tool at yahoo.com


Download FirebugCodeCoverage-0.1.xpi.
Requirements (obviously)

Mozilla Firefox
Firebug Extension for Mozilla Firefox

Limitations:

Does not include statistics on anonymous functions.
Is limited to function (entry) code coverage, does not include other forms such as exit, statement, condition, or path code coverage. (Description: Wikipedia)
Is my first Firefox add-on, so there was a learning curve involved.

Future Improvements:

Automated integration with Selenium IDE (one button to run tests and do code coverage)
Better display of results, instead of a big kludge of function names
Additional types of coverage, depending on what options are available from jsdIDebuggerService

Technorati Tags: Firebug,  Code Coverage,  JavaScript