JavaScript archives
Compatibility
CSS coaching
Thidrekssaga
QuirksBlog
Donations
Politics
Mobile
About
COH
Well, I've been using Safari Windows for a few weeks now, and I though it's time for a report. This report is only about the Windows version, because I can't install the Mac one. Why not? Because I don't have the right OS X version.
I wish Apple would stop tying Safari Mac releases to new OS upgrades; it makes running the latest and greatest Safari version too expensive. Currently I'm using 1.3.2 on my Mac; and I've decided to wait for Leopard before upgrading my Mac, which means this site won't feature bug reports for Safari 2 or 3 Mac in the near future.
More in general, I wish the Apple fanboys would admit that Apple is doing exactly the same thing Microsoft used to do back in the nineties and early 2000's and was rightly flamed for. This whole tying business is a nasty stain on Apple's browser policy.
In any case, the lack of Safari 2 and 3Mac reports on this site is Apple's fault; not mine.
Nonetheless, the release of Safari Windows is supposed to help people like me. People who don't own a Mac (or an iPhone) should be able to test their web pages in Safari, and therefore Apple released Safari for Windows. That's pretty simple, isn't it?
Unfortunately it isn't. As a browser tester of long standing I feel obliged to point out the obvious: in a little while we'll have three Safari versions that we have to test our pages in: Windows, Mac, and iPhone. That doesn't make things simpler, it complicates it quite a bit.
Now I do not doubt for an instant that Apple is going to go through major trouble to make sure that the three Safari versions are as similar as possible. Unfortunately, similar does not mean the same, because in the end programmers are humans, too, and humans make mistakes.
No doubt in a year or so we'll find discrepancies in some areas. If we're fortunate these discrepancies are truly minor and can be safely ignored, but with even a little less luck we'll have a few incompatibilities that require people to test their sites in Safari Windows, Safari Mac and Safari iPhone.
I will follow Safari's (lack of) discrepancies with interest.
In any case it is moving forward. I already gave a list of newly supported CSS; and on the DOM side of Apple is making progress, too. I haven't yet run official tests, but I did note that attributes[key] and cellIndex are finally supported properly. (The last one is especially important.)
According to Steve Jobs Safari is the fastest browser on Windows. Now he isn't very clear on the exact definition of "fastest", and as Apple CEO he'll have a rather hard time avoiding charges of prejudice in any case.
During @media 2007 Europe it was very fashionable to complain about Safari's lack of speed (to be fair: we were talking about 2, not 3). The consensus seemed to be that Safari may be pretty quick in loading web pages, but it can be agonizingly slow in closing down web pages, especially those that have plugin content. Jobs didn't mention these problems in his keynote.
Then I went through my DOM vs. innerHTML and style vs. className benchmarks in Safari Windows, and the test results are pretty awesome. So awesome, in fact, that I started to suspect there's something wrong.
Fortunately, for once I didn't have to do the dirty work myself. Mark "Tarquin" Wilton-Jones did some extensive testing and found the cause:
Safari does not update the date objects correctly. It appears to pause the date object while iframe src changing, page loading, and parsing is taking place, so the next request for a date object produces one with the same time as the one in the parent page. Even when forcing it not to cache the page, this still happens (and yes, I tested many times since I did not believe it myself). The page load itself could be seen to take about half of a second when timed with a stopwatch. Clearly, Safari has a bug with date objects here.
(And yes, this is the actual sequence of events: first I started to doubt Safari's reported benchmark results, and only a few hours later I read Mark's article.)
It gets worse, though. During his keynote, Jobs showed IE7 and Safari Windows running side by side, and noted the speed with which the browsers downloaded and displayed a few key test pages. Guess whih browser was fastest? Hint: it wasn't the one from the giant Apple competitor.
Obviously, any such speed test must use the load event: show load time when the page has been loaded completely. Unfortunately the load event in Safari is different from the same event in other browsers. Mark explains:
Safari does not fire onload at the same time as other browsers. With most browsers, they will wait until the page is loaded, all images and stylesheets and scripts have run, and the page has been displayed before they fire onload. Safari does not.
In Safari, it seems onload fires before the page has been displayed, before layout has been calculated, before any costly reflows have taken place. It fires before images have completed decoding (this can also happen in rare cases in Opera, but Safari seems to do it everywhere), meaning that a substantial part of the load time is not included. So basically, onload is not trustworthy in Safari for checking page loading times.
So Jobs' speed testing is unreliable. It compares Safari's load event to IE's, and the two are different. From a propaganda point of view Jobs said and showed the right thing, but from a technical point of view it's completely worthless.
The "fastest browser on any platform" claim is based on faulty implementations of the Date object and the load event, and is therefore untrustworthy.
Until these problems are solved we cannot really compare Safari's speed to other browsers' speed; and we must perforce conclude that Apple's test results are (let's keep this nice) too flattering.
(Kudos to Mark for testing this stuff. If the world had had to wait for me, these facts wouldn't have been uncovered for at least another year.)
Finally I'd like to note two relatively minor, but still annoying, problems with the Windows version.
No doubt these two problems will be fixed eventually.
This is the blog of Peter-Paul Koch, web developer, consultant, and trainer.
You can also follow
him on Twitter or Mastodon.
Atom
RSS
If you like this blog, why not donate a little bit of money to help me pay my bills?
Categories:
Comments are closed.
1 Posted by pauldwaite on 27 June 2007 | Permalink
I'm not sure 3 versions of Safari is quite right. According to Apple, iPhone runs OS X, and runs Mac applications just like a normal Mac.
As such, I'd expect Safari 3 uses the exact same rendering engine on iPhone and the Mac, and thus behaves the same.
I'm less sure about Windows, but I remember reading something about WebKit being made more cross-platform, so the rendering engine might be the same there too.
It's highly probable I'm missing something here, but I would have thought the Safari situation is the same as for Gecko-based browsers and Opera. Have there been any reported inconsistencies between Mac and Windows versions of those browsers?
2 Posted by ppk on 27 June 2007 | Permalink
No reported inconsistencies yet, but they'll appear. There are a few (very minor) inconsistencies between Firefox Win and Mac, and even, I think, with Opera.
If the Safari inconsistencies will remain as minor as the FF/Op ones there's no real problem.
3 Posted by Nick Matsakis on 27 June 2007 | Permalink
pauldwaite: The iPhone cannot "run Mac applications like a normal Mac". It's operating system is a version of OS X, but it is not a Mac.
Once Safari 3 is out of beta, I'd be very surprised if the difference between Safari for Windows and Safari for Mac is substantial at all.
Aside from font differences, are there really any substantial differences in Firefox on multiple platforms? What about Opera? If you can't point to problems with these, why do you expect Safari to have them?
4 Posted by Liam the lemming on 27 June 2007 | Permalink
"Aside from font differences, are there really any substantial differences in Firefox on multiple platforms? What about Opera? If you can't point to problems with these, why do you expect Safari to have them?"
Because we remember IE5/Mac.
It was wildly different in tests to IE/Win. It only takes one browser to behave differently across platforms; we see that, and we become suspicious of them all.
Safer to assume the worst, and all that. Sad, but that's the point we've reached.
5 Posted by Chris Snyder on 27 June 2007 | Permalink
"Aside from font differences..."
Number 1 complaint with Safari on Windows: the fonts look too good.
Apple's font rendering is so completely out of wack with other Windows browsers that I now have to support three different typographic stylesheets: Mac, Windows, and Windows Safari. Ick.
6 Posted by Tim on 27 June 2007 | Permalink
IE5/Mac was complete rewrite of the IE rendering engine for the mac platform! It made an attempt to be more compliant than IE5/Win, and so was *wildly* different.
Firefox, Safari (and probably Opera) share the same code and rendering engine across platforms. Fonts and replaced form elements are the only real difference.
In fact Safari/Win seems to make no effort to fit in with Windows at all (forms and fonts etc.), so I would expect virtually no differences. ie. "This is exactly what it will look like on the Mac/iPhone".
IE5/Mac must have cut you deeply...
7 Posted by Matthew Pennell on 27 June 2007 | Permalink
"When I use Windows+M to minimise all windows, Safari doesn't minimise. Since I use this function relatively often, it's starting to bug me."
Try Windows+D instead.
8 Posted by Martin on 27 June 2007 | Permalink
The different onload handling is significant. If you assume the page is done with all calculations onload and you use this to position some object on the page based on position and size of some other object, you might be up to some nasty surprises. Unless Safari intercepts access to the DOM properties and stalls the execution until reflow has completed.
9 Posted by Shane Shepherd on 27 June 2007 | Permalink
"Try Windows+D instead."
Works like a charm...even minimizes Visual Studio...on monitor #2! (Visual Studio also ignores Windows+M)
10 Posted by Dave Hyatt on 27 June 2007 | Permalink
onload does fire earlier in Safari than in other browsers. However it does not fire until all resources have been loaded. We do delay doing the first layout (if the page loaded quickly enough) until after the onload fires. This is simply common sense, since to do otherwise is to waste time doing relayouts as a result of the changes that would be executed by a typical onload handler.
Note that Firefox does not defer its first layout until after onload, but - like Safari - it also defers painting until after the onload has fired. Neither browser will paint until after the onload if the page loads quickly enough. (I ought to know. I implemented this in Firefox.)
Regarding images, Safari does wait until the image data has been fetched before firing onload, but it does not decode images until they actually paint. Again this is common sense to keep memory usage down (and is especially useful on mobile devices). Most other browsers are not very smart in this respect and aggressively decode images before firing the onload. This is neither necessary nor required to be compliant with onload (and it wastes memory and hurts performance).
11 Posted by Dave Hyatt on 27 June 2007 | Permalink
Finally, regarding the ibench test itself, ibench is specifically designed to work around onload. It forces the page to lay out and scroll, causing every browser in the test to paint each page twice. It also measures the overall time of the entire run, thus ensuring that as long as your paints take longer than the timeout values used, even the paints will be incorporated into the time. It’s actually really clever.
In other words, onload alone has *never* been a useful means of benchmarking time (even before Safari came into existence), since Firefox has deferred painting until after onload for years. The makers of i-bench knew this.
As a final note, if you add document.body.offsetLeft you will force a layout in both Firefox and Safari, and you'll get much more accurate results.
12 Posted by ppk on 27 June 2007 | Permalink
Dave,
Thanks for the clarifications.
Can you tell me where I can find the iBench test? I searched for it, but only got vague referrals, and I'd like to take a good look at this test before commenting any further.
13 Posted by Dave Hyatt on 27 June 2007 | Permalink
"The different onload handling is significant. If you assume the page is done with all calculations onload and you use this to position some object on the page based on position and size of some other object, you might be up to some nasty surprises. Unless Safari intercepts access to the DOM properties and stalls the execution until reflow has completed."
Yes, that's what all browsers do. All you have to do to get onload results that are the same as other browsers in Safari is add document.body.offsetLeft. For browsers that already did a layout, they won't do any additional work. Safari will stall and do a complete layout of the page, not returning until it has completed.
All browsers behave this way while running DHTML, i.e., they batch up changes to the DOM and only do layouts as needed, so if you are just benchmarking DOM operations with visual results, you should bracket the start/end of the test with document.body.offsetLeft. This is true of all four major browser engines.
Browser benchmarking is a really tricky business.
14 Posted by Heather on 27 June 2007 | Permalink
Right now I'm trying to make my web-app work correctly in Safari but I'm running to some issues mainly with Safari for Windows. Is anyone else finding that onresize isn't getting called or key press events for the ctrl key?
Also I haven't found a good way to prevent highlighting/selecting text when I'm dragging an object. Right now I'm trying parent.frames[1].document.selection.empty()
15 Posted by Peter Mularien on 27 June 2007 | Permalink
Regarding your bug #2, I believe you're talking about a "feature" of Safari, which is also present in Safari 2.x. You need to tell Safari to use tab to set focus on things other than basic form fields - it's under "Preferences > Advanced > Pres Tab to highlight each item on a webpage". Why this is not the default, I don't know.
16 Posted by Heather on 27 June 2007 | Permalink
Unfortunately that didn't seem to fix the highlighting problem. Essentially when I'm dragging something within my app I call a function to clear the selection so it doesn't appear on the screen. For firefox I'm using parent.frames[1].getSelection().removeAllRanges();
and for IE I'm using selection.empty(). Neither work for Safari.
17 Posted by Stephen on 28 June 2007 | Permalink
Heather: I too am having a problem with onresize not firing at all in safari. I haven't found a solution yet.
18 Posted by Josh on 28 June 2007 | Permalink
Of course, this was just released on VersionTracker after you posted, but it appears that there is a pixel-perfect iPhone emulator available now:
http://www.versiontracker.com/dyn/moreinfo/macosx/32728
19 Posted by Jordan West on 28 June 2007 | Permalink
The one bug that somewhat bothers me in the new safari has been spoke about before, but when you have a maximized window and then you minimize and then restore the window it is no longer maximized. What makes it worse is you can see it go to its maximized state and then go to a non maximized window.
Also, I haven't run actual tests yet but i had a frame animation that collapses/expands the frame. I use setTimeout to do so, it works in all other browsers but in Safari, the collapse/expand will only show if I move my mouse during the times my setTimeouts are firing. If i wait too move my mouse, the frame will stay at its current size and then at my first mouse movement show the collapsed or expanded frame at its fully collapsed or exapanded state. So its like it fires the setTimeout but doesn't make the update to the UI unless the mouse is moved. Also, if i stop moving my mouse the animation will stop, and then if i move again will show the final state of the frame.
20 Posted by Serg on 29 June 2007 | Permalink
Read such results of testing of load of page: IE 8ms, Mozila 4 ms, Safari 2ms
21 Posted by Ian on 1 July 2007 | Permalink
Actually, there is an open bug for Safari that it fires onLoad *before* images at least are ready:
http://bugs.webkit.org/show_bug.cgi?id=13241
That will affect performance on iBench, though I don't know if painting offscreen images have to be performed before the scrollTo iBench does. But as Dave mentions images are only decoded when needed, maybe it will not render offscreen images with the small scrollTo offset and thus jump to the next page without full layout of all content?
22 Posted by Tom on 2 July 2007 | Permalink
I’m running windows, and to me the font smoothing is too much. Smaller text becomes almost too chunky to read. On windows it crashes as soon as you try to type in your proxy password and you can’t edit the proxy settings (the button is greyed out in preferences.) It seems to render pretty quickly, but I was testing at work and it seemed to lag on the initial request, like the Microsoft network protocol was stopping it and saying “What are you doing here?” : ) All told, I don’t think I’ll be switching away from firefox. Safari currently lacks the plugins I’ve come to depend on, and I just don’t see anything that really makes it worth switching. Based on the text alone I don’t see myself switching over to Safari as my default browser. I know it’s still in beta but I see myself sticking by firefox. However, I’m very excited to see Apple opening up it’s browser to windows users. One more browser I can test my sites on now.
23 Posted by neil craig on 20 July 2007 | Permalink
the thing that has always bothered me most about safari is it's refusal to use for( in ) loops. in the js apps we've developed, safari 2.x and 1.x have always failed on these loops...very irritating...haven't tried safari 3.x yet.
24 Posted by Ben Listwon on 25 July 2007 | Permalink
Thanks for the tip on turning on Tab to all elements.
But, there is still a major issue in Safari 3. They have removed the ability to programatically set focus on non-form elements, such as spans or divs.
Has anyone found a way around this?
It really presents quite a problem for allowing javascript to let the user do something like tab through a calendar, or even to change a style onfocus.
25 Posted by Mirko Gustony on 3 August 2007 | Permalink
Safari 3.0.3 is ignoring the media attribute on xml-stylesheet processing instructions when serving xhtml as application/xhtml+xml. This results in mixed up screen and print stylesheets -- which looks really ugly.
http://bugs.webkit.org/show_bug.cgi?id=11939
This bug seems to cover it -- but it looks untouched since it's been reported.
Greetings,
Mirko
26 Posted by Maciej Stachowiak on 4 September 2007 | Permalink
There was a request for download location of the iBench. Here it is. Unfortunately you need a Windows system with IIS to run it.
http://www.lionbridge.com/lionbridge/en-US/services/outsourced-testing/zdm-eula.htm
As a side note, I don't think there is any bug with the date object. If you suspect that is affecting some benchmark, you can make it run for enough iterations to be testable with stopwatch timing. I think the reason those DOM benchmarks are so fast is that our JS and DOM really are that fast.