bdash

Safari in 10.9.2 ignores autocomplete=off. The preference was removed since it's no longer of any use.

Yes, this should be fixed in 10.9.2.

Looks like it's at http://support.apple.com/kb/HT6150

Core Animation layers have a mode in which Core Graphics calls targeting them are both processed asynchronously by a another thread and rasterized via OpenGL.

It was only used for canvas in the initial release before being deployed more widely.

For what it's worth, WebKit on OS X uses hardware acceleration for both rendering and compositing by way of Core Animation.

>1/2GB of source code?

WebKit's entire Source directory is 247MB, and more than 100MB of that is ChangeLog files.

An entitlement.

As far as I'm aware, iCloud accounts aren't required for push notifications. The push notification system identifies devices by an opaque token that isn't tied to any user-identifiable information.

Edit: The Apple Push Notification Service documentation at https://developer.apple.com/library/ios/documentation/Networ... talks about the architecture and seems to match my recollection.

From the "Notification Programming Guide for Websites"[1]:

    > Opting In to Notifications
    > 
    > Users must opt in to receive notifications. The opt-in process only occurs
    > once per domain. The presentation of asking for permission is identical
    > for all website notifications. In fact, the permission policy that
    > a user chooses for push notifications applies to local notifications.

It goes on to say that "users can adjust their notification preferences in Safari preferences and System Preferences".

[1]: https://developer.apple.com/library/mac/documentation/Networ...

Can you clarify what part of my comment this is in response to? I'm having difficulty understanding why you chose to post it in reply to my comment.

Yes, this only works if you have Mavericks. It is called Safari Push Notifications because it's a push notification feature provided by Safari, to distinguish it from OS X's more general support for push notifications.

Safari also supports the "Web Notifications" specification[1], which allows a website to post a notification while it is open in Safari. This has been supported for a few releases now and is also available in some other browsers. I believe Gmail can make use of this to call attention to new emails while open in a background tab.

[1]: <https://dvcs.w3.org/hg/notifications/raw-file/tip/Overview.h...

WebKit makes relatively heavy use of reference counted objects, though a custom reference counting implementation is used rather than std::shared_ptr. That said, there has been an increasing emphasis on preferring unique ownership to shared ownership of objects where possible.

I'm a little confused by your throwaway comment about Gecko being the smallest browser engine though. WebKit weighs in at less than 3 million lines of code, much smaller than the size you quote for Gecko.

You can. See http://shantonu.blogspot.com/2012/07/building-xnu-for-os-x-1...

OS X provides the POSIX_SPAWN_CLOEXEC_DEFAULT flag to posix_spawn, which results in it automatically closing all file descriptors that aren't described by the file actions passed to posix_spawn.

After adding the site to the home screen there doesn't seem to be any way to get back to your site after following a link to the full version of an article. Known issue?

Other than that issue, I'm very impressed with the site. The design and performance are excellent.

I'm not sure about that. I'll follow up with some of my colleagues to see why typed arrays are in such an state.

Am I correct in assuming that if JavaScriptCore starts successfully executing the tests, it'll automatically start showing up on the relevant part of arewefastyet.com?

Also the name of JavaScriptCore's regular expression implementation, as Yet Another Regexp Runtime: http://trac.webkit.org/browser/trunk/Source/JavaScriptCore/y...

Thanks for the pointer on running the tests. I noticed two big issues:

1. Some of the tests use shell functions like "read" that jsc doesn't provide. This is easy enough to address.

2. I was mistaken about the quality of the typed array support in JavaScriptCore. While the interpreter has knowledge of typed arrays, the actual implementation that's used when running in-browser lives in WebCore rather than in JavaScriptCore. When running in the shell only a bare minimum typed array implementation, primarily intended for JSC-only regression tests, is available. This trips up some tests since the implementation is much less complete than the one in WebCore.

That looks like everything's being built and run in the correct way for OS X. Is there an easy way to run the benchmarks from that repository against my own WebKit working copy without having to set up all of the server-side support that the main README talks about? If I can run things locally I might be able to spot what's going awry with the asm.js tests for JSC.

I'm not familiar with building just JSC on Linux, but last time I looked in to it the only way to build JSC was as part of building all of WebKit.

Nope, they work just fine from the `jsc` shell.

From what I can tell, JavaScriptCore has had typed array support since at least as far back as December 2011 (http://trac.webkit.org/r103637, a random change in JavaScriptCore involving typed arrays).

It's a bit odd that arewefastyet.com stops showing results for JavaScriptCore when switching to the asm.js view.

> Can you ask LLDB to never stop at certain functions or files?

LLDB has a setting named target.process.thread.step-avoid-regexp, the value of which is a regular expression defining functions that step-in won't stop in.

> Can you wrap a class with some user defined script to simplify its interface for debugging?

LLDB exposes its entire API to Python, so you can either embed Python scripts in to the LLDB debugger or embed the LLDB debugger in to a Python script. There's an introduction available at http://lldb.llvm.org/python-reference.html, but for more detailed documentation you'll need to use the help functionality within lldb's built-in Python prompt.

That option is present only in WebKit nightly builds, and has been since when the new Web Inspector was introduced.

The whitepaper at http://msdn.microsoft.com/en-us/library/windows/hardware/gg4... indicates that Windows timer coalescing requires an application to explicitly opt in. The article describes OS X Mavericks' support as applying to all upcoming timers while on battery power (presumably excluding particular classes of timing-sensitive applications, such as audio playback), which would be a much more aggressive approach than in Windows.

SpiderMonkey uses JavaScriptCore's regular expression JIT, YARR (Yet Another RegExp Runtime).

The Qt port of WebKit uses JavaScriptCore, not V8.

Speaking as someone that has spent time working on a web browser, that would be a fantastic policy, both for browser developers and for web standards in general.

Nitro is Apple's marketing name for JavaScriptCore, so UIWebView and Safari both make use of Nitro. The difference you're thinking of is whether a JIT compiler is used. That difference has nothing to do with the age of the version of WebKit used in UIWebView vs Safari.