Comments by webkit.org
Reply | Original | Permalink | Tweet@randalfarmer
It would stink if you had to take some action to disable the page cache full-time when you only really want it disabled in this one edge case. As mentioned in the post, developers should only install unload handlers when they actually need them to be installed. Do you install an unload handler full-time, or do you install it only in onsubmit?If there were some other programatic way to disable the PageCache, that would still be desirable to the unload handler. Semantically, the “unload handler” and “I want to disable the PageCache!” are two completely different things.
Opera invented “history.navigationMode” for this reason. We might consider implementing that (https://webkit.org/b/29739) but I would shudder if developers just started flipping the switch at page load and left it on the whole time!
Of course, maybe that wouldn’t be much different than the situation today…
Reply | Original | Permalink | TweetCyberSkull, you’re exactly right and I strongly recommend you keep your eyes out for part 2.
Reply | Original | Permalink | TweetRoy, “/” used to be, in its entirety, considered a valid relative URI/URL, at least as of RFC2396. RFC3986 renamed it to a “relative URI reference” and it remains valid as such. Colloquially, I’d expect most people would say it’s still ok to call it a relative URL in a context that expects such.
Reply | Original | Permalink | TweetWhat we’d like to see—and the Super Friends Guide to HTML5 Hiccups recommends this—is optional syntax checking in validator.nu, which would then get picked up by the W3C validation service. That way, developers who care about XHTML syntax can have what they want, and the rest of the universe can have what it wants. :)
validator.nu does have an XHTML mode, and can even override the Content-Type. It doesn’t have support for checking as HTML and XML syntax at the same time however; you have to check twice if you want content that works as both.
Reply | Original | Permalink | TweetIf you have a small list of sites where visiting them increases the memory footprint significantly above what you would expect, please take a few moments to file a bug report at http://bugreport.apple.com/ with that info so the problem can be investigated.
Reply | Original | Permalink | Tweet> The golden ticket, though, is when your bug "goes to rdar". rdar is Apple's internal (private) bug tracker.
*Radar* is Apple's internal bug tracking system. rdar:// is the protocol that happens to be used for URLs into that system.
Reply | Original | Permalink | TweetAlso the WebKitScriptDebuggerEnabled default does nothing anymore since Drosera was replaced.
Reply | Original | Permalink | TweetYou can turn on the tools from Safari's advanced preferences.
Reply | Original | Permalink | TweetIf you like Chrome’s stripped down Web Inspector, you will love the original, full featured version in the WebKit nightlies. Cheers!
Reply | Original | Permalink | TweetIf you like Chrome’s stripped down Web Inspector, you will love the original, full featured version in the WebKit nightlies. Cheers!
Reply | Original | Permalink | TweetIf you like Chrome’s stripped down Web Inspector, you will love the original, full featured version in the WebKit nightlies. Cheers!
Reply | Original | Permalink | TweetIf you like Chrome’s stripped down Web Inspector, you will love the original full featured version in the WebKit nightlies. Cheers!
Reply | Original | Permalink | TweetYes, the fix for this issue is present in the Mac OS X 10.5.3 update released today.
Reply | Original | Permalink | TweetPaul, it’s worth clarifying that WebKit and Safari are very different things. In many parts of your post you conflate the two. WebKit is an HTML rendering engine. Safari is a web browser that uses WebKit to display web pages. The WebKit.app application you download from http://nightly.webkit.org/ contains an updated version of WebKit and *not* Safari. It makes use of the version of Safari that you have installed on your system. Every single one of the “WebKit” improvements you would like to see are in the domain of the Safari application.
Extensions are not explicitly disabled with nightly builds. You may receive warning dialogs asking you to disable them before filing bug reports and some extensions will disable themselves when they notice that they are being run against a newer version of WebKit than the developer has tested with. This is highly desirable as many extensions hook into undocumented and unsupported parts of WebKit/WebCore which means that there is a very real likelihood their use will result in crashes with the nightly builds. Other extensions such as Inquisitor are almost entirely at the Safari application level, in which case changes to WebKit are not particularly important from their point of view.