bdash

I'm not sure what you mean by UIWebView being an "older implementation of webkit". UIWebView uses the same version of WebKit as Safari on iOS, which is essentially the same version of WebKit as is shipped with Safari on OS X.

Is it safe to assume that any bugs that you're running in to are being reported to the browser vendors?

> Webkit isn't "Chrome in a box" either.

The Chromium Embedded Framework (http://en.wikipedia.org/wiki/Chromium_Embedded_Framework) isn't too far from that. I'm not sure if Opera is using this project in particular, but they do mention using Chromium.

And their first contribution is already attached to https://bugs.webkit.org/show_bug.cgi?id=15553!

Yes, I'm sure. The same core rendering engine, known as WebCore, is shared between both WebKit1 and WebKit2 on OS X. WebKit1 is used by most applications that use a WebView to display web content, while WebKit2 is used by Safari. The different API layers set up different delegate callbacks for WebCore so that they can tweak the behavior to fit their architecture (single process vs separate web and UI processes).

At http://my.opera.com/ODIN/blog/300-million-users-and-move-to-... they state they're switching because they feel it is a waste of resources to maintain their own rendering engine. I'd be surprised if the JavaScript engine was a big factor in their decision. The vast majority of "JavaScript" problems encountered by web developers are either problems with the DOM implementation in general. A smaller portion are in the binding between the DOM implementation and the JavaScript language, and fewer still are in the JavaScript engine itself.

WebKit2 is a new API layer on top of WebKit, not a new browser engine. It has been used by Safari since v5.1.

The press release notes that they're using the Chromium port of WebKit, so it's very likely that they'll be using V8 as a JavaScript engine.

In an email to the WebKit development mailing list[1] Håkon Wium Lie, the Opera CTO, mentioned that they've had engineers working on WebKit for a while now, and they'll soon be contributing their work on multi-column layout to the WebKit project.

[1]: https://lists.webkit.org/pipermail/webkit-dev/2013-February/...

That is incorrect. As the article you link to states:

> Webkit takes a very different approach, and very intentionally. They believe it's better to keep the text invisible until the font is ready. This way, there is no moment where the text flashes into its newly upgraded self.

Google Chrome, the subject of the original linked post, is built in WebKit and thus inherits this behavior.

My guess would be that data detectors are used to detect and format links in incoming messages.

> WebKit was open sourced roughly a week (June 7, 2005) before Nokia announced the port to their phone (June 13, 2005). That means that Nokia was able to do the port in less than a week with (presumably) a few competent developers.

While the ex-Nokia developers I've met have all been excellent engineers, they certainly didn't port WebKit to their mobile devices in under a week. June 7, 2005 marks the date that Apple started WebKit as an open source project. That is, on that date the CVS repository and Bugzilla instance were made publicly available. For over two years prior to that point Apple had been publishing the source code of the two main components of WebKit, JavaScriptCore and WebCore, alongside Safari releases. Nokia's port of WebKit to Symbian was based on those releases, and it wasn't until late 2006[1] that Nokia started developing against the current WebKit SVN repository.

[1] http://bugs.webkit.org/show_bug.cgi?id=11540

This matches my recollection of things as someone that followed WebKit from shortly after Safari was announced, and became actively involved when the open source project proper started up in 2005.

If that is the logic involved then why is iOS not affected?

The major difference is that Microsoft wasn't actively working with the various web standards groups to standardize its various proprietary features. The majority of the non-standard functionality that's added to WebKit and Gecko is done with the intent of moving it on to the standards track if it is beneficial to the web platform.

Edit: If you can't see any difference between the approach to standards taken by Microsoft with IE 6 and by the people involved with WebKit, I'd suggest reevaulating your own biases.

WebKit is constantly moving forward, and is not stagnant like IE6 was. Many of its initially-proprietary web features have been standardized and adopted by other browser engines. The primary challenge is convincing web authors to support the standardized versions of the formerly-proprietary features alongside the browser-specific versions.

Another post[1] on the same website suggests that DMA is also disabled for Thunderbolt when the machine is locked.

[1]: http://www.breaknenter.org/2012/02/adventures-with-daisy-in-...

As the article notes, OS X is only vulnerable to this issue when the machine is unlocked as DMA access via FireWire is disabled while it is locked. If your machine is left unattended and unlocked then anyone with the ability to plug in a FireWire device could already cause you grief.

It's the underlings you have to watch out for.

Yup!

Apple still owns and uses the entirety of 17.0.0.0/8.

v38. You'd not see it with v48.

The 7th is the first day of the second week of the year.

The majority of the other scrolling performance issues discussed in the article are things that browsers can and will improve over time. For instance, the version of WebKit used by Safari uses a combination of tiled rendering and multithreading to achieve smooth scrolling even when painting is expensive (such as on high-DPI devices where painting involves touching many more pixels). This multithreaded scrolling system was recently improved to support "position: fixed" elements, which means the benefit that the performance difference between "fixed" and "absolute" positioned elements that the article discusses is now nonexistent in Safari.

Pages that use scroll event handlers, however, place limits on what browsers can do to improve scrolling performance. Scroll events have to be interleaved with the painting that occurs during a scroll, otherwise any movement of onscreen elements that the event handler performs will appear out of sync with respect to the rest of the scrolling. The single threaded nature of JavaScript in web pages means that this event delivery requires bypassing the multithreading scrolling optimisation I mentioned above. Reducing, or preferably eleminating, these event handlers can result in dramatically smoother scrolling. Improvements to web technologies have been proposed in order to aid this. For instance, scroll events are often seen implementing headers that are in the flow of the page and then stick to the top of the viewport as the user scrolls downwards. "position: sticky", a means of achieving this effect without JavaScript, was recently proposed on the CSS standards mailing list [1] in order to help future developers unintentionally causing their pages to scroll in a jittery manner.

[1] http://lists.w3.org/Archives/Public/www-style/2012Jun/0627.h...

Resources such as nib files and help files aren't amenable to things like #defines. Filenames and build system metadata fall in to the same cateogry. The source code proper is a different story, but is also trivially updateable via sed or the like.

While I've not measured the performance of the approaches, from reading the Python patch discussed in the article it would appear that Objective-C uses a more intelligent approach to maintaining the reference count in the face of concurrent manipulation.

The patch to Python involves guarding every increment and decrement of a reference count with a single pthread mutex. This pthread mutex would become a major source of contention if multiple threads are attempting operations that manipulate the reference count. Pthread mutexes are also a relatively heavyweight synchronization mechanism, and their overhead would impact performance even when the single mutex was uncontended.

In contrast, Objective-C uses more efficient means of managing the reference count. The implementation of -[NSObject retain] uses spinlocks to guard the side tables that hold the reference counts. There are multiple such side tables and associated spinlocks in order to reduce contention if multiple threads are attempting to manipulate the reference counts of different objects. CoreFoundation, which provide the implementations of many common types such as strings and arrays, uses an inline reference count that is manipulated using an atomic compare-and-swap operations. This reduces contention at the cost of increasing the storage size of every object of this type.

I believe the non-LLVM backend to GCC was removed from Xcode 4.2, which was released in October 2011.

While the WebKit project has a strict review process and a substantial amount of regression testing, code reviews can't catch all issues and WebKit doesn't have complete test coverage for all aspects of web technology. Changes can, and often do, introduces regressions from subtle rendering errors to all-out crashes.

These sorts of temporary issues aren't that a big deal if it's in a separate application that you use only for testing, but they're a darn sight more painful when you replace your system WebKit frameworks and they start impacting things like your email client or the system installer stack.

By replacing your system frameworks with those from a WebKit nightly you're going to see trouble with OS X software updates, system-wide instability due to running bleeding-edge code, and a test environment which isn't representative of what your users will see.

If for some reason you need to use the frameworks from a WebKit nightly with your application, use DYLD_FRAMEWORK_PATH to point your app at the WebKit nightly's frameworks. This has the same benefit without any of the downsides mentioned above.

I don't see how this explanation can be correct given the fact that the code using host_vmxon / host_vmxoff in the revision you point to is guarded by #if VBOX_WITH_HOST_VMX, which the changeset also shows is false. It wasn't turned on until the following revision: <https://www.virtualbox.org/changeset/43380/vbox>. I can't see how any change in behavior of host_vmxon / host_vmxoff in 10.8.2 could be the cause if they weren't even being called prior to this.