Contents tagged with Safari

  • OpenAjax requests comments on browser wishlist

    The OpenAjax Alliance has been working with some of the top Ajax developers on a wishlist that aims at gathering and prioritizing the development features that we need the most from next generation browsers. The process is completely open and Wiki-based, so feel free to contribute.


  • Getting absolute coordinates from a DOM element

    For some reason, there is no standard API to get the pixel coordinates of a DOM element relative to the upper-left corner of the document. APIs only exist to get coordinates relative to the offset parent. Problem is, it's very important to get those coordinates for applications such as drag and drop, or whenever you need to compare coordinates of elements that may be in completely different parts of the document.

    In Microsoft Ajax, we implemented such a function (Sys.UI.DomElement.getLocation) but it proved to be one of the most difficult problems we had to solve. Not so surprisingly, every single browser has its own coordinate quirks that make it almost impossible to get the right results with just capability detection. This is one of the very rare cases where we reluctantly had to use browser sniffing and implement a completely different version of the function for each browser.

    We also had to implement a pretty complex test suite to verify our algorithms for thousands of combinations of block or inline elements, offsets, scroll positions, frame containment, borders, etc., and run those on each browser that we support. The test suite in itself is quite interesting: it renders an element with the constraints to test, gets its coordinates from the API, creates a top-level semi-transparent element that is absolutely positioned and check that both overlap exactly to pixel precision. To do so, it takes a screen shot and analyses the image to find the rectangles and check their color.

    The simplest runtime implementation is the IE one, thanks to a little-known API that does almost exactly what we want: getBoundingClientRect. Almost exactly as we quickly discovered it has a weird 2-pixel offset except on IE6 if the HTML element has a border (which is a "feature" that was removed in IE7 and which we chose not to support). It also doesn't include the document's scroll position. Finally, if the element is in a frame, the frame border should be subtracted. This actually was the cause for a bug that we unfortunately discovered after we shipped 1.0 but which is now fixed in ASP.NET 3.5 as the parent frame may not be in the same domain, in which case attempting to get its frame border will result in an access denied error. So you need to do this in a try-catch and just accept the bad offset in that fringe scenario.

    In all other browsers, you currently need to recurse through the offset parents of the element and sum the offset coordinates.

    In Safari 2, though, the body's offset gets counted twice for absolutely-positioned elements that are direct children of body. Something you don't just guess, you need the thousands of test cases I mentioned earlier to discover something like that...

    In both Safari and Firefox, you must subtract to the coordinates the scroll positions of all parent nodes (and not the offset parents like before). Well, except if the element is absolutely positioned (this last restriction doesn't apply to Opera). Or if the parent is the body or html element. Confused yet? Wait, there's more.

    In Firefox, non-absolutely positioned elements that are direct children of body get the body offset counted twice.

    In both IE and Firefox (but you don't care for IE as it has getBoundingClientRect), the border of a table gets counted in both the border of the table and in the td's offset.

    Finally, on Opera, there are scroll values on elements that are not scrolled so you need to explicitly check for the overflow mode before you subtract scroll positions. Opera also includes the scrolling into the offsets, except for positioned contents.

    The worst part in all this is that we don't even know for sure that we nailed it, and we know that future browsers will require adjustments.

    Speaking of which... Firefox 3 will implement getBoundingClientRect. I haven't tried their implementation yet and checked whether it has the IE quirks, but it should be a lot simpler than what we have to work around today to do the same thing and we'll definitely have to rely on less undocumented quirks. By the way, if you were thinking of using the undocumented getBoxObjectFor, forget it, it was designed for XUL elements and will probably get removed from non-XUL elements in future versions.

    There is a bug open against WebKit to get that in Safari but it's currently without an owner. Here's to hoping this gets into the next version. Vote for it.

    Opera apparently also implements that in 9.5, referencing a W3C draft which curiously doesn't contain any references to getBoundingClientRect.


  • How to build a cross-browser history management system

    When we built the history management feature in ASP.NET Futures, we spent considerable time experimenting with the different behaviors of the main browsers out there. The problem with such a feature is that it has to rely on a number of hacks because browser vendors basically never anticipated this need. Now they're thinking about it, so all this may be simplified in a few years, but in the meantime, it's a very complicated feature to build. One of the things that struck me was how little reliable literature is available on the subject. There is a lot of partial information, lots of false or unverified information, but very little that's really comprehensive, reliable and up to date. Good references I found include Brad Neuberg's Really Simple History and Handling Bookmarks and Back Button as well as Mike Stenhouse's Fixing the Back Button and Enabling Bookmarking for Ajax Applications. But it was a lot easier to just experiment directly on the different browsers and verify our theories directly.

    This blog post will attempt to be an account of the difficulties we encountered and how we worked around them. It's also a brain dump that will help me and others maintain the feature in the long term. I hope it will evolve over time as feedback comes in, browser bugs get fixed and we ourselves learn more.

    Note: all code in the pages attached to this post is pure JavaScript and XHTML and has no dependency to any script library.

    How history used to work

    It used to be the case that history in the browser just worked: the user navigated from page to page following links and the history stack just got filled, the back button worked as usual and life was good. With dynamic pages that post forms, things got a little less ideal as every post action would make a new entry, no matter if or how little the state of the page changed. Plus, you got this nasty "do you really want to repost this form" dialog that most users had no clue what to do with.

    But Ajax applications broke the model in a more fundamental way because most actions are done without navigating away from the page or posting forms. This means that the browser basically has no way of knowing the state of the application changed in a meaningful way and nothing new gets in the history stack. Any naive user who doesn't know the implementation details of your application will expect the back button to work like it has for decades, which is catastrophic because by navigating back to the previous page it knows about, the browser will lose all the user's precious work.

    Thanks to a few hacks such as the ones I will expose here, it doesn't have to be that way, and the control of the history stack can be given back to the application developer. We can even make the model better than it used to be and choose exactly what constitutes a meaningful enough state change to warrant an entry in history.

    Navigating without moving

    The main trick that history managers use is to have the browser believe the user navigated to a new url without the current page and all its JavaScript and DOM state being thrown away. The only part of the url that enables such a thing is the hash part. The hash part is what comes at the end of the url after a pound (#) sign. The original intent of this part of the url was to allow for navigation inside of the document. You would put a special named, href-less anchor tag in your document, and then navigating to #nameOfTheAnchor would just scroll the anchor into view. The page doesn't get reloaded, but it does enter the browser history (almost, we'll see about that in a minute). This is great for long pages with a table of contents for example.

    But it's also great in that it's a way for us to manipulate the history stack without unloading the page, which is exactly what we need. So this is one more example of using something for a totally different use than what it's been designed for, but what choice do we have? And it's actually all right as this new usage doesn't conflict with the old one.

    So it seems like we have an easy way to get this to work: whenever you want to create a history point, just navigate the page to #SerializedFormOfTheStateOfTheApplication; detect url changes somehow (polling works (almost) everywhere) and re-hydrate the application state from that. That should work, right? Yes, it should, but it doesn't, except on Firefox and Safari 3 for the Mac, for various reasons.

    I've prepared a page that implements exactly that logic that you can try here:
    HistoryHash.htm.txt (download and rename HistoryHash.htm to run on your system)

    Here's a summary of the results on some popular browsers:


    IE 7

    Firefox 2

    Opera 9

    Safari 2 Mac

    Safari 3 Windows beta

    Safari 3 Mac beta
    URL changes Yes Yes Yes Yes Yes Yes
    Creates history entry No Yes Yes Yes Not on first page Yes
    Back doesn't kill timers Yes Yes Not in 9.23 and 9.24
    Yes in 9.10
    Yes Yes Yes
    Back enables forward Yes Yes Yes Yes Sometimes Yes
    location.hash reflects changes in the url Yes Yes Yes No Yes Yes
    Making it work in IE

    The problem in IE comes from the fact that it doesn't create a history entry when the hash changes. This can be worked around by navigating an iframe in addition to changing the hash as IE does create a new history point every time a frame is navigated. The problem with that technique is that just like the main page, the iframe can't be just navigated to a new hash, it needs to move to a different page, which means a round-trip to the server on every new state, which is quite wasteful. I've heard of techniques to create the iframe's contents through clever scripting in the iframe url and document.writing, but I've never been able to consistently reproduce it.

    <update date="Sep. 14 2007">
    One of the comments over at Ajaxian pointed me to this great article from Julien Lecomte, where he explains how they built the feature over at YahooUI. It's a super-interesting read and thanks to it, the document.writing trick suddenly clicked together for me. The trick is that you need to open the document before you write to it and close it when you're done if you want the history point to be created by IE. Somehow I had missed that but today I tried again and had no difficulty making it work. The only thing that may be a little tricky is that you need to pass a url into or the browser will default to about:blank. That may look ok until you try it under https, in which case you're going to get the infamous dialog about mixed contents. This can be solved by using the usual magical url javascript:'<html></html>' (thanks to the toolkit team for that trick). Please note that now we don't even have a single request for the frame, even on the first hit, again thanks to the magical url. It's also important to note that the iframe must absolutely be in the static markup of the page (you can't create it dynamically) and on the first request it must point to an existing page on the server.
    I've updated the sample page for IE below to include this trick and I'll also integrate it into ASP.NET Ajax.

    The frame gets the state passed to it through the search part of the url (the part after a question mark). It then calls back into a function in the main document when it loads. When the user navigates back to a previous state, it's the iframe that really navigates back, not the main page. When it does, its load event fires, which calls back into the main page again. From that callback function, we set the hash so that the browser url reflects the state for bookmarkability, and of course we update the application with that state.

    Here's a simplified implementation of this. I didn't hide the iframe to make clearer what is happening here but that's of course what you'd do in production code.
    HistoryIE.htm.txt (download and rename HistoryIE.htm to run on your system)
    You will also need the iframe file:
    HistoryFrame.htm.txt (download and rename HistoryFrame.htm to run on your system)

    <update date="Mar. 31 2008">
    Internet Explorer 8 finally gets rid of the need for the iframe navigation: changing the url fragment now results in a new entry being created in browser history. We were able to make our implementation of history work in IE8 by just restricting the iframe code to versions earlier than 8. Internet Explorer now follows exactly the same code path as Firefox, Safari 3 and Opera 9.5. Not all is perfect though as IE still has this weird quirk where when navigating away from the history-managed page causes its history entries to collapse to just one entry. If you do go back, it will expand again but this is really confusing to the users.
    On the bright side, IE is the only browser as I write that implements an HTML5 event that gets triggered when the url fragment changes, eliminating the need to poll. I really hope the other browser follow that lead...

    Making it work in Safari 2

    While the workaround for IE results in a completely different implementation, at least it makes some sense and is consistent. With Safari, we're lost in bugland. In Safari 2, monitoring the hash from a timer doesn't work as location.hash is not getting updated as the url in the browser's address bar changes. This is a plain bug that is fixed in Safari 3 and the current WebKit builds. The only information we have that gets correctly updated when the user navigates through history is history.length. In other words, we know the index of the history point but we don't know the corresponding state. One thing we can do to work around this is to maintain our own array of states and use the index to retrieve the right state from this array. One caveat is that if we use a JavaScript variable to store this array, navigating to a different page will completely wipe out the state array and kill the history feature. This can be partially worked around by storing the information into a hidden form field instead of a JavaScript variable: form field values are restored by the browser when navigating through history. This works relatively well to maintain history even if the user navigates away to a different page and comes back but what it doesn't handle on the other hand is the user pressing F5.

    Here's an implementation of those workarounds (I've left the history stack field visible to make it easier to understand what happens but of course in a real application it would be idden):
    HistorySafari2.htm.txt (download and rename HistorySafari2.htm to run on your system)

    This must be fixed in Safari 3, right?

    Well, yes, Safari 3 Mac does the right thing as the unmodified hash code that works on Firefox just works. But on Windows currently other bugs cripple the feature. In the current nightly build and public beta of Safari 3 for Windows, if your page is the first that you load in the browser, no history entries get created when the hash is modified. Another weird bug that I couldn't quite find reliable repro steps for is that under some circumstances, hitting back does not enable forward, making time travel only possible to the past, without any hope of return. Somebody give them a flux capacitor, an old clock and a thunderstorm... Because of this, the Safari 3 for Windows implementation kind of works sometimes but it really needs to be fixed. I filed bug 14080 in WebKit a while ago to track this. Seriously, I don't blame them, it's a beta, betas have bugs and I'm pretty confident this will get fixed pretty soon. I've had pretty good experience with their reactivity in the past.

    What about Opera then?

    Well, it used to work perfectly well in Opera up until version 9.10. Then they broke it. In 9.23, and also in 9.24 which is the current version as I'm writing this (not a beta), for some reason Opera cancels all timers when hitting back. This completely breaks any history manager because there is now no way of knowing the user navigated. This problem has been reported by several persons on the Opera forums and apparently there's a bug open for it, but the closedness of Opera's bug database doesn't allow us to monitor the status of the issue.

    <update date="Sep. 17 2007">
    Neil Jenkins pointed me to a nice trick he's come up with to work around this bug. The idea is to have a hidden image with the following src attribute: javascript:location.href='javascript:onTick();';
    Amazingly, this works and the code gets executed when the user hits back. Just doing javascript:onTick(); directly doesn't work for some reason that I don't quite understand. Apparently, Opera tries to be smart about what can be run as an img src, but it's easily worked around. If you ask me, script should simply not be allowed as image urls (as well as in a number of places) but I suppose that would break too many hacksapplications.
    Anyway, the workaround does work, and it's simple enough that you should use it if you need to support Opera 9.23 and 9.24. But you also need to know that this is fixed in Opera 9.5 (still in beta as I'm writing this) so it may not be worth fixing in the long run. Kudos to Opera for their reactivity on this issue.
    HistoryOpera.htm.txt (download and rename HistoryOpera.htm to run on your system).

    The state of things

    So things are in a pretty grim state currently. It seems like we're going back (pun intended). We used to have a collection of tricks that made possible an implementation of a history manager that worked pretty well in IE, Firefox, Opera and Safari. Now, we only have IE, Firefox and Safari Mac. I just hope this is only temporary and that both Apple and Opera repair their browsers soon.

    <update date="Sep. 17 2007">
    As explained in the previous section, there's now a known workaround for the Opera bug, and the bug itself will be fixed in 9.5.

    <update date="Feb. 18 2008">
    The WebKit bug seems to be fixed.

    <update date="Apr. 18 2008">
    Apparently I forgot to mention one annoying bug in Firefox that url-decodes the hash automatically, which gets in the way of using the hash as a querystring-like state bag. More details in the bug comments here:

    <update date="Dec. 22 2008">
    Some great additional information on ways to help refresh behave better on IE can be found here:

    What's next?

    In the next posts, I'll get into more details about the initial request, maintaining meaningful titles and mixing all this with asynchronous operations, which is where it really gets tricky.


  • Why Safari for Windows looks like a Mac application

    One thing that really stands out in the Windows version of Safari is that it's exactly identical to the Mac version, almost down to the pixel level. That must have been quite a pain to achieve, and it would probably have been way easier to use the OS for many things. Does Apple really think PC users will go "gee, that Mac UI is really sweet, I think I now have an uncontrollable urge to buy a Mac"? Probably not.

    So here's my hypothesis:

    Safari for Windows is not intended to take over the Windows browser market, nor is it a showcase for the wonderful-mac-ui-that-if-only-we-knew-it-would-make-us-all-switch. It's an emulator.

    Its one and only purpose is to make sure that devs who work on PC can build apps that will run on the iPhone and on the Mac. Especially the iPhone: when you have relatively little screen real estate, making your UI fit is no easy task, and the closer the browser on your dev machine is to the real thing, the better.

    So here's my bet: when the final version of Safari ships, it will have an option to emulate the iPhone.


  • Is Safari on Windows a good thing or a bad thing?

    The first thing most web developers probably thought this morning when they learned about Safari for Windows was "oh man, yet another browser to test in". And yes, for the moment, that's what it amounts to. Coincidentally, I have spent a good part of last week making the history management in Microsoft Ajax work in Safari 2.0.4. I got it to work fine (after much Apple cursing), so the first thing I tried after I downloaded Safari 3 beta was my history tests. And sure enough, it breaks in new, unexpected ways. History management is pretty much a big hack that is different on about all browsers (Firefox and Opera are the nicest ones here, with predictible, similar behaviors). And sure enough, Safari 3 brings a totally unheard of model. I didn't find a way yet to create a new entry in history from script that doesn't navigate away from the page. None of the old Safari tricks work anymore (they were probably and rightfully considered bugs and were fixed). They weren't replaced by the more rational things that work in Firefox and Opera. Even the iFrame trick that we use on IE doesn't work because Safari now crashes if you try to dynamically add a frame to the DOM. If anybody here found a way to do that, I'd love to hear about it.

    But there is at least one thing to like about this new version: Apple is going to release it for MacOSX Tiger (the current version of their OS), which means that thanks to auto-update, the horrible, horrible browser that is Safari 2.0.4 is going away in the not so far future. When I say that it's a horrible browser, that's entirely from an Ajax developer's perspective. Your mileage may vary, but the latest Webkit, even with its flaws, fixes the most serious problems that plague Safari 2, and the new Safari 3 is based on that better codebase.

    Another thing to like is that it seems like the behavior of the browser on Windows is very very close, if not identical, to the behavior on MacOS. That doesn't entirely remove the need to test on both platforms, but at least it promises to make it possible to automate test runs on all Windows browsers as part of your integration process. This way, you'll catch most Safari regressions earlier, and that's only goodness.

    So sure, it's never fun to have yet another browser to test, and this release has its problems that hopefully will get fixed (I filed several bugs already today, and the total lack of error feedback doesn't help), and others that probably won't (why can't they respect the conventions of the host OS?) but I'm convinced that in the long term, we'll all benefit from this move from Apple. But there may be a few difficult months ahead of us as we work around new Safari 3 bugs and still have to work around old Safari 2.0.4 bugs.

    What do you think?


  • What are these Foo$Bar$baz functions in the Microsoft Ajax Library files?

    If you've looked at the debug version of our JavaScript files, you may have noticed code similar to that:

    Foo.Bar = function Foo$Bar() {
    function Foo$Bar$baz() {
    	// Do something
    Foo.Bar.prototype = {
    	baz: Foo$Bar$baz

    And looking at that, you may have wondered what the Foo$Bar$baz names were for. That's a very good question and I congratulate you on your thoroughness. Here's why:
    Stack trace shows anonymous functions

    "JScript anonymous function"? That's not very helpful in a debugger stack trace and that's what you'd get if we had written the above code this way (or run the release version of the script):

    Foo.Bar = function() {
    Foo.Bar.prototype = {
    	baz: function() {
    		// Do something

    In this case, the methods on class instances are anonymous methods.

    Thanks to the global "dollared" names that we inject into the debug code, the functions have a global name that is easy to map to the actual member that they are aliases for, and here's what a typical stack trace looks like in debug mode:
    Stack trace shows meaningful function names

    That's of course a lot more useful. Of course, you should never use those names in code that consumes those libraries, as they are here only to make debugging easier and they won't be there if you run the release versions of the scripts (which you are doing on your production servers, right?). For example, Foo$Bar$baz in the above example is an alias for Foo.Bar.prototype.baz, which is what you should use if you need it. Most of the time, you'll just call baz off an instance, like this: myBar.baz().

    Finally, you may wonder why we're not writing this (which would be more compact and maybe a little easier to read):

    Foo.Bar = function Foo$Bar() {
    Foo.Bar.prototype = {
    	baz: function Foo$Bar$baz() {
    		// Do something

    Well, that would be great, but our good friend Safari 2 refuses to parse it... Safari 3 seems to fix that bug though.