Safari 1.3 - QuirksBlog

Two days ago Apple's team launched Safari 1.3, being part of the OS X.3.9 upgrade (once again named after a fierce predator, but I forget which one). Despite numerous bug fixes, the new release is marred by extremely serious onunload problems.

Problems

Safari 1.3 hardly ever fires the unload event, and that's of course a serious bug. You can test it by going to some random pages in my site. The navigation link in the left frame that leads to the page you go to gets a special style onload, and this style is removed onunload. Safari doesn't remove the special styles. You can also try my Window events test page. When you leave this page, an alert "Unload event" should spring up. In Safari 1.3 it doesn't.

The only exception seems to be when you leave my entire frameset: then the event fires normally. When you run the test wholly outside my frameset, though, the event doesn't fire.

Furthermore, there seem to be focusing problems in a frameset. When I click on a link in my content frame, I cannot scroll the new page in the content frame by means of the arrow keys (though Page Up and Page Down work fine, go figure). The Cmd+Left Arrow (Back) and Cmd+Right Arrow (Forward) don't work, either. Clicking in the new content page solves these problems, but that shouldn't be necessary.

Fixed bugs

Despite this new, serious bug, the Safari team has clearly been working on solving other bugs. See also Dave Hyatt's entry for a list of new features.

Finally, Safari now boasts a JavaScript console (Debug => Show JavaScript Console; alternatively Shift+Cmd+J). The error messages aren't always very clear, but it's a distinct improvement over earlier versions.

Comments

1 Posted by Van on 17 April 2005 | Permalink

The problem with having to click within a frameset/frame to scroll it was present in Safari 1.2 as well or at least it was on some sites if I remember correctly.

2 Posted by Sebastian on 17 April 2005 | Permalink

Nice, you are the fastest guy in the web - wow ;) thank you for the overview and updated tables.

3 Posted by Geoff Moller on 18 April 2005 | Permalink

The onunload issue is very frustrating for apps that need to write a cookie onunload. Arg. I will be *eagerly* waiting for an update.

4 Posted by Keith on 18 April 2005 | Permalink

Great job, Peter-Paul, thanks!

One request: would you consider hosting an archived version of the tables with Safari 1.2 support? Many people (myself included) try to include support for older versions, at least for a while. Eventually, it'll be reasonable to make Safari 1.3 a minimum requirement, but probably not for a while - I wouldn't want to slip up by using a feature that would force this too soon.

Thanks!

5 Posted by Ryan Thrash on 18 April 2005 | Permalink

Any examples of the contentEditable working in Safari, yet?

6 Posted by Celso E Portela on 20 April 2005 | Permalink

Is there a workaround to the onunload problem in Safari 1.3? This update messed up my "work in progress" site http://www.celsoportela.com/eap_nuevo/

I'm using styleswitcher.js which places a cookie on the onunload event.

Thanks!

7 Posted by ppk on 20 April 2005 | Permalink

Keith, sorry, no, I don't offer older versions of the Tables. It's just too much work to keep separate oldies.

I could postpone the testing of new browsers, but "later" usually means "never", and besides, this is one area where I'm always in the forefront of the news, and I'd like to keep it that way.

So I'm afraid you'll have to reverse engineer Safari 1.2 support from the information on this page.

8 Posted by Chris Keppler on 21 April 2005 | Permalink

Is there a Safari equivalent of "Window.frameElement"? I am trying to change the SRC of the current frame from within the current frame (if that makes sense)for a page forward or page backward click event from a MAP AREA on the sides of the displayed page.

Thanks and GREAT SITE!!!!!

9 Posted by Kinny Landrum on 22 April 2005 | Permalink

Why won't Safari 1.3 even start for me? I downloaded the Java fix today, and I have no SIMBL folder in Application Support. Yet every time I click on Safari 13. it starts to open, then quits. Safai 1.2, which redownloaded works fine. If somebody can help I would appreciate it.

10 Posted by stephanie on 25 April 2005 | Permalink

I find I can no longer enter a URL without the www prefix -- Safari hangs & gives me the beachball of death.

So I have to remember to type www.google.com rather than just google.com.

11 Posted by Ryan on 27 April 2005 | Permalink

For what it's worth, Safari also fixed a CSS bug where application/xhtml+xml would apply the background of the body element to the canvas instead of the html element, like text/html does (you can see a test pages at http://RyanCannon.com/lib/html/mime.php).

12 Posted by IneX on 27 April 2005 | Permalink

I noted some nasty bugs in Safari 1.3 (German localization):

- I can't cycle through Tabs by using "Command+Shift+Arrow Key Left/Right" anymore

- There's no textinput-marker in textfields with a black background (set by CSS)

- The shortcut for opening the Source window changed from "Command+Alt+V" to "Command+Alt+U".

- Some descriptions in the Right-Click-Menu changed. For example: "Copy Link to Clipboard" changed to "Copy Link".

Safari might be faster, but because of this little changes I'd like to go back to version 1.2...

13 Posted by Ian Roberts on 28 April 2005 | Permalink

I'm not sure if I'm too mch of a novice to be sharing thoughts with you guys but it seems to me that 1.3 Safari doesn't like tables with % heights is this right?

14 Posted by rob on 28 April 2005 | Permalink

"- I can't cycle through Tabs by using "Command+Shift+Arrow Key Left/Right" anymore"

This works for me. Check to make sure the focus isn't in an input field (i.e., click on a background first). If an input field has captured the focus then the arrow keys apply to that field.

15 Posted by Jon Oliver on 30 April 2005 | Permalink

We have been having a problem with the onChange() event only from Safari users. Specifically when a user enters new information in a textbox and clicks directly onto the submit button without any intermedate tabbing or clicking.

The submit seems to take place before the onChange() event is handled. I have yet to do an official test but is this an official bug? (v1.2.4) If so is there a patch?

Cheers

16 Posted by till.. on 10 May 2005 | Permalink

hello everybody.
I'm just about to cry about an issue with Safari 1.3 vs. Frames: I have this type of frameset with a content frame in the very middle, which should be scrollable only horizontally.. no need for vertical scrollbars. But it seems that Safari 1.3. adds vertical scrollbars - no matter what I do against it - and then "forgets" about them after a reload.
Is this a known bug..? Does anyone know a workaround for this..?

thanks a lot! greetz, till.

17 Posted by Gavin on 18 May 2005 | Permalink

I've noticed that the unload handler, for a frameset at least, gets fired before the onload handler when first browsing to a page.

Another bugette I have spotted is that the (admittedly deprecated) .caller javascript property inside a js function is not supported.

18 Posted by Mathieu on 24 May 2005 | Permalink

Anyone know how to fix the OnChange for Safari when the users directly press the submit?

19 Posted by Broken OnUnload on 1 July 2005 | Permalink

Hi all,

Fantastic site. Great information.

I am curious if anyone has a sense of whether or not there will be an update to fix the onUnload() issue.

thank you!

20 Posted by Adam on 13 July 2005 | Permalink

I find it more frustrating with Safari's onLoad event handling after the back button. I have a form that prevents multiple form submits by disabling the submit button after the being clicked once. My onload event enables the submit button but, if I press the back button, I get the previous page with the submit button disabled thus demonstrating that the onLoad didn't run for the previous page. This gets tedious when a user needs to change her responses on the previous page and resubmit. I had to use the onUnload event to re-enable the submit button to work around the problem.

21 Posted by kyle on 25 August 2005 | Permalink

I don't know anything about your application, but it seems to me a better solution would be to disable the button onsubmit and re-enable the button onunload. enabling the button onload seems largely unnecessary since the default state of a button is 'enabled'