Surfin’ Safari

<< WebKit Coding Style Guidelines
JavaScript and DOM Compatibility >>
 

WebKit Fixes in Safari 2.0.1

Posted by Maciej Stachowiak on Saturday, September 17th, 2005 at 4:12 pm

Many of you have asked for the list of WebKit bugs fixed in Safari 2.0.1.

First the disclaimers: This list does not include any changes to Safari the app, only to the open source components (WebKit/WebCore/JavaScriptCore). Also, it only includes the changes made from the 10.4.2 software update to the Safari 2.0.1 update, not any earlier fixes. And finally, we don’t necessarily promise to do this for future updates, but we might.

And here’s the list:

  • Fixed a bug where form submissions from a page with an XSLT stylesheet would get submitted to the next page you navigate to.
  • Added support for document.elementFromPoint DOM extension from IE.
  • Added support for focus and blur methods on <button> elements.
  • Fixed a bug where <select> elements sometimes would not update their size
  • Include unconfirmed inline text input (when typing Japanese for instance) when submitting a <textarea>.
  • Implemented window.showModalDialog extension from IE.
  • Support both colons and equal signs as separators for showModalDialog parameters.
  • Fix outerHTML to work on <img> elements.
  • Fix window.opener to work in windows opened via targetted links rather than window.open.
  • Fixed a bug where using an accesskey on a <button> element would cause a crash.
  • Fixed crash when clicking more than once on a particular like on the quirksmode.org innerHTML test page.
  • Added support for loading external scripts and executing inline scripts by dynamically adding <script> elements to the DOM.
  • Fixed bug where WebKit would change ” to ‘/’ in the query part of a URL.
  • Fixed bug with painting of background images when negative coordinates are included in the background-position.
  • Made return key on a checkbox submit the form instead of toggling the checkbox.
  • Made sure that remote Web Archive files are downloaded instead of displayed inline to plug a security hole.
  • Applied standard security policy to links embedded in RTF files.
  • Applied standard security policy to links embedded in PDF files.
  • Fixed a parsing problem with <script> tags that use XML-style self-closing syntax but are also followed by a close tag.
  • Fixed a bug where WebKit would mistakenly trigger a full reload when following a link in some cases.
  • Fixed a crash when calling setAttribute on elements that were removed from the document.
  • Made non-ASCII characters work in XHTML titles.
  • Fixed list-style CSS property (accidentally broke, causing problems on alistapart.com and many other sites.
  • Implemented Mozilla’s DOMParser extension (to go along with XMLSerializer and XMLHttpRequest which we already had).
  • Made importNode create HTML elements when used on an HTML document.
  • Fixed bug where progressive loaded background images would scroll down (no, that wasn’t on purpose).
  • Fixed bug where relative URL backgrounds would be wrongly shared between different pages.
  • Fixed flash of unstyled content when accessing window.innerWidth/innerHeight during the page load (e.g. on wired.com).
  • Now properly ignoring NaN values in window.open parameters.
  • Fixed a race conditionwhere frames changing the location of other frames during loading could keep the other frame from getting loaded at all.
  • Fixed a bug where early return from layout would prevent future layouts from happening (caused frames to come out blank sometimes).
  • Fixed crash when loading an XML page that contains an element named script that’s not in the xhtml namespace.
  • Fixed common crash in removeAllEventListeners on .Mac, travelocity, abercrombie and many other sites.
  • Fixed crash when ESC key is held down across a series of authentication sheets.
  • Fixed crash when an element removes itself from its own onblur handler.
  • Fixed crash when closing child windows in some cases.
  • Changed name property of the window object representing a frame to properly give precedence to name element attribute over id
  • Eliminated unnecessary horizontal scrolling when focusing a text field.
  • String.replace method now works when the regular expression uses {n, m} syntax.
  • Made dynamic modification of the text of a <title> element work.

You can follow any responses to this entry through the RSS 2.0 feed. Both comments and pings are currently closed.

20 Responses to “WebKit Fixes in Safari 2.0.1”

  1. John Siracusa Says:
    September 17th, 2005 at 5:19 pm

    Go to this URL:

    http://webkit.opendarwin.org/blog/?p=26

    and note that there’s still no indication of who posted this. I complained about this when this blog first started, and it’s still driving me insane. (I get to these pages directly via mynewsreader, so I never see the author attribution on the “index” page.) Can someone *please* update the WordPress template for these types of pages and add some “posted by…” text?

  2. Clint Ecker Says:
    September 17th, 2005 at 6:15 pm

    Hmm NetNewsWire says it was posted by someone called Maciej.

  3. maciej Says:
    September 17th, 2005 at 8:08 pm

    The “posted by” is at the bottom.

  4. Sören Nils 'chucker' Kuklau Says:
    September 17th, 2005 at 9:32 pm

    The “posted by” is lacking on the entry itself: “This entry was posted on Saturday, September 17th, 2005 at 4:12 pm.” — …by?

  5. LochNess Says:
    September 17th, 2005 at 11:23 pm

    I’m not sure I understand.

    In Safari, I see “This entry was posted by maciej on Saturday, September 17th, 2005 at 4:12 pm. You can follow any responses to this entry through the RSS 2.0 feed. You can leave a response, or trackback from your own site.”

    In NetNewsWire, I see “Surfin’ Safari 9/17/05 4:12 PM maciej Uncategorized”

  6. maciej Says:
    September 18th, 2005 at 12:52 am

    I updated the template to make the author more clear on both the main page and the single article view.

  7. xfinite Says:
    September 18th, 2005 at 5:00 am

    Hey guys, thanks for this very informative post! I really hope you’ll be able to give webdevelopers similar lists for future revisions of Safari as it is very helpful to know exactly in what version something was implemented, fixed, etc. for end-user support and feature planning. Things like adding the DOMParser object (and Anders’ dynamic script loading code! Yay!) may not mean much to Joe Safari User, but for Ajax developers it’s a big deal. Again, thanks for the list.

  8. John Siracusa Says:
    September 18th, 2005 at 10:27 am

    Thanks maciej! :)

  9. Phrogz Says:
    September 18th, 2005 at 6:55 pm

    What was the cutoff date for bug fixes for this release? I’m sorry to see so many browser-compatibility extensions added, while two core ECMAScript failures that I filed (and which were fixed) failed to make the cut. (Bugs 3293 and 3294) Ah well, hopefully the next release.

  10. Phrogz Says:
    September 18th, 2005 at 6:59 pm

    (Thank you, by the way, for the precise details.)

  11. nettles Says:
    September 18th, 2005 at 9:49 pm

    Just a note on the XML you are generating for the atom feed, since I want it to be as pretty as can be!
    When I read the page at through the Atom feed, the fourth bug fix gets written as:

    <code><select></select></code>

    While over here directly in the blog, it is encoded as:
    <code>&lt;select&gt;&lt;/select&gt;</code>

    –Ben

  12. nettles Says:
    September 18th, 2005 at 9:51 pm

    I should have added, that the former has the effect of generating a Drop
    Down element when viewed in Safari, while the latter displays the code
    fragment as intended.

  13. jan Says:
    September 20th, 2005 at 5:17 am

    >> Fixed bug where progressive loaded background images would scroll down (no, that wasn’t on purpose).

    Can we have it on purpose then? It just looks too good :-)

    Keep up the good work,
    Jan
    –

  14. gyoung Says:
    September 20th, 2005 at 5:20 pm

    Hiya – thanks for the posting. Just wanted to say that this kind of run-down of features and fixes is hugely valuable to web developers. Perhaps there’s another place this list is posted (and I’d be happy to check it out) but in the past I’ve not found it. So if you don’t do it on the blog, where will this kind of list live in future? TIA.

  15. ap_kelly Says:
    September 26th, 2005 at 12:35 am

    Doesn’t supporting none standard features from IE weaken the whole concepts of standards? I mean, these none standard features will never go away if we keep supporting them. If they ever become standard then we should obviously support them, but I think this move just gives more power to IE, and less freedom to others.

    Keep up the otherwise excellent work.

    Andy.

    PS: When will we see the acid test compliant version of Safari released?

  16. vnoel Says:
    September 28th, 2005 at 11:38 am

    Are any of the memory leak fixes mentioned in the previous post present in this release ? Or do we have to go get nightly builds if we want the fixes ?

  17. ckizer Says:
    September 30th, 2005 at 11:35 pm

    The best fix by far is the insert into textedit. Do you realize how HUGE this fix is? Every WYSIWYG editor, and every forum software on earth lets you use WYSIWYG tools to set styles, now they work properly because Safari supports moving where text is inserted. This is a HUGE leap forward. It means all those forum, toolbars work, and now a host of WYSIWYG web based editors, and many tools can be used with Safari!

    Thanks!

  18. ckizer Says:
    October 1st, 2005 at 12:01 am

    You can see a demo of the fix here:
    http://www.courtkizer.com/movies/webkit_builds_fix.mov

  19. natekoechley Says:
    October 4th, 2005 at 9:19 am

    Hello,

    I wanted to take a moment to thank you. It’s great that you’re communicating your progress. This level of information is valuable, and helps me provide the best experience to Safari users. It’s clearly a Good Thing that you’re fixing bugs and creating an ever-better product, but I wanted to write to commend you on the communication first and foremost. I’m a developer at a large web site, and knowing what you’ve addressed in each release makes it much easier for me to create for Safari.

    I believe in a vibrant and varied ecosystem of user agents, and this transparently into features, fixes and issues is critical to that end. I want to deliver a delightful experience to Safari users, and this information makes that possible. Please strongly consider continuing to share this information in the future.

    Thanks, Nate

  20. Pingback from Nate Koechley’s Blog » Blog Archive » Safari Browser Continues to Improve:
    October 4th, 2005 at 9:54 am

    [...] tinues to Improve

    In Safari browser news, they’ve recently announced a long list of fixes to the WebKit rendering engine and a renewed focus on JavaScript and DOM Compatibility [...]