State of the WebKit port

[Daniel Ferreira (theiostream)]

Hi everyone,

It’s been a little over three weeks that I’ve been working on my
Google Summer of Code project of making JavaScriptCore (WebKit's JS
engine) and WebCore (WebKit's layout engine) build on top of GNUstep.
Today, I’ve completed the first “phase” of the project, which pretty
much involved 1) trying to build it; 2) noting down everything that
broke.

This effort generated a TODO list for adjustments to GNUstep so that
JSC and WebCore would work seamlessly on top of a GNUstep stack. Given
this list, we can start deciding on where to focus efforts for making
JSC/WebCore usable. Approaches include addressing the issue in GNUstep
or patching WebKit in a “GNUstep port”, that would get around these
issues by using some code from other current WebKit ports (GTK and Qt
are some examples).

First of all, I should address how the build was done. Until now, two
WebKit components have been fully built (WTF and JavaScriptCore), and
one has been compiled and not linked (WebCore).

WTF (the Web Template Framework) is a series of helpers for WebKit
which involves things as diverse as crypto, threading, text encoding,
low-level memory analysis and inter-process communication. Most work
here involved isolating (through preprocessor guards) code that had
been marked in WebKit as Cocoa-specific, but that was in fact
Darwin-specific — which will eventually constitute a patch to WebKit’s
upstream. This Darwin-specific code was seamlessly replaced with its
already-existing Linux-specific counterparts, and how to fit that into
WebKit is not the matter of this thread.

At this point, I chose to disable the remote inspector WebKit
feature[1], since it relied on XPC and Darwin's notify functions for
IPC. While these two libraries could eventually be implemented in a
cross-platform manner, they currently rely on the Mach kernel's
messaging model, so getting it to run on Linux would be too much of a
hurdle for now.

Moving on, some changes were done to WTF’s Platform.h header, which
defines some WebKit capabilities on a per-platform basis. Here, I
chose to disable support for audio, video, media streaming, RTC –
since realistically, GNUstep is also far from implementing Apple's
whole media stack, and graphics seem like a priority anyway. Since we
have the option to disable these features "cleanly", it seemed like
the right way to go for now.

After this was done, the only issue that stopped WTF from working
seamlessly was the lack of some CoreBase functions:
CFLocaleCopyPreferredLanguages(); the CFPreferences* suite. (The
latter will become a bigger problem when it comes to WebCore, but
we'll get there.); and CFBridgingRetain/CFBridgingRelease, which is
already the subject of a thread here which hasn't yet been concluded.

Moving on, I started building JavaScriptCore. Building was done rather
simply after some header adjustments in libobjc2, Base and CoreBase. I
moved on to running the JSC tests, and as they failed I started fixing
some bugs in GNUstep.

The first was a problem with NSMapTable in base for which I submitted
a patch to the mailing list which is currently inconclusive[2]. The
second issue was a matter with CoreBase's run loop where we got into a
deadlock if we tried to remove a timer from a run loop, for which I
haven't yet publicly submitted a patch. I will open a pull request
with both as soon as I split my myriad disconnected changes to Base
and CoreBase in a series of organized commits.

The next issue was a little more complex. JSC's bridge with
Objective-C relies on a private extension Apple made to the
Objective-C ABI which is only integrated with its ObjC runtime. An
issue briefly documenting the matter was opened in libobjc2[3], and
changes will need to be done to both clang and libobjc2. At this
point, I chose to move on from the failing JSC tests and start
building WebCore.

In this process, I haven't yet generated any patch aside from a small
one in Opal[4] regarding header issues, but I have generated a fairly
big "TODO list" to follow. Although it is not complete (certainly
linking and trying to run the tests, as with JSC, will show us some
more hidden issues), it fulfills the purpose of giving me (and the
project) elements to pick which direction to follow.

It is as follows:

1) New Frameworks (mostly Carbon stuff that has not yet been deprecated)
* CoreServices: implement TEC* converters (from CarbonCore.framework)
* CoreServices: implement HITheme, HIEvents UI functions
* CoreServices: implement CarbonEvents for the keyboard (from
HIToolbox.framework)
* ApplicationServices: implement UniversalAccess.framework
* ApplicationServices: define kAX* accessibility constants (from
HIServices.framework)
* ColorSync: define ColorSync types (no actual implementation is needed)
* Security.framework: implement Certificate Verification functions

2) Base (mostly new APIs introduced after OSX 10.4)
* base: considerable adjustments to NSURL
  * +[NSURL fileURLWithPath:isDirectory:] (OSX 10.5, with some 10.6+
auxiliaries)
  * +[NSURL URLByResolvingAliasFileAtURL:options:error:] (OSX 10.10)
  * -[NSURL getResourceValue:forKey:error:] (OSX 10.6)
  * NSURL.fileURL
  * NSURLBookmarkResolutionOptions enum
* base: minor changes to NSFileManager
  * -[NSFileManager attributesOfFileSystemForPath:error:] (OSX 10.5)
  * implement NSFileManagerDelegate (OSX 10.5)
* base: minor changes to NSProcessInfo
  * -[NSProcessInfo disableSuddenTermination]; -[NSProcessInfo
enableSuddenTermination] (OSX 10.6)
  * -[NSProcessInfo beginActivityWithOptions:reason:]; -[NSProcessInfo
endActivity:], NSActivityOptions enum (OSX 10.9)
  * -[NSProcessInfo systemUptime]
* base: implement NSURLCredentialPersistenceSynchronizable
* base: implement new NSURLProtectionSpace authentication methods
  * NSURLAuthenticationMethodNTLM
  * NSURLAuthenticationMethodNegotiate
  * NSURLAuthenticationMethodClientCertificate
  * NSURLAuthenticationMethodServerTrust
* -[NSURLProtectionSpace distinguishedNames]
* base: implement new NSURLRequest cache policies
* base: major changes to NSURLConnection
* declare NSURLConnectionDelegate as a protocol
  * -[NSURLConnection currentRequest] (OSX 10.8)
  * -[NSURLConnection scheduleInRunLoop:forMode:] + unschedule (OSX 10.5)
  * -[NSURLConnection start] (OSX 10.5)
  * -[NSURLConnection setDelegateQueue:] (OSX 10.7)
* NSURLAuthenticationChallengeSender corrections
* base: update NSCoder to new APIs
  * -[NSCoder decodeObjectOfClass:forKey:] (OSX 10.8)
  * NSSecureCoding protocol and method (-[NSCoder requiresSecureCoding])
* base: NSDate: NSSystemClockDidChangeNotification
* base: create NSMakeCollectable() as wrapper around CFMakeCollectable()
* base: create NSURLSession class
* base: create NSFileCoordinator, NSFilePresenter classes
* base: add NSFileWriteFileExistsError = 516 to FoundationErrors
* base: NSGeometry: create NSEdgeInsets, NSEdgeInsetsZero
* base: add new NSHTTPCookie properties
  * NSHTTPCookie.HTTPOnly
  * NSHTTPCookie.secure
  * NSHTTPCookie.sessionOnly
* base: NSCalendar: NSCalendarUnitSecond etc. new enum values
* base: NSCalendar: NSCalendarIdentifier* enum

3) CoreBase
* corebase: implement CFNotificationCenter functions
* corebase: implement CFStringTokenizer functions
* corebase: implement CFPreferences functions
* corebase/base: implement -[NSRunLoop getCFRunLoop]

4) CoreNetwork
For CoreNetwork we need to implement some further socket functions,
CFHTTPMessage and proxy support. However, I wonder why CoreNetwork was
started given CFNetwork's state. Is there any reason why we should
push for CN rather than just use CFNetwork?

5) Opal (mostly small adjustments)
* opalgraphics: re-typedef enums so they are interchangeable
* opalgraphics: should definitely not need a cast between CGPathRef
and CGMutablePathRef
* opalgraphics: implement CGContextPathContainsPoint() for CGContext
* opalgraphics: export CGImage property strings and
CGImagePropertyOrientation enum for use with
CGImageSourceCopyPropertiesAtIndex()
* opalgraphics: CGPDFDocumentGetPage()
* opalgraphics: new CGPath functions
  * CGPathCreateMutableCopyByTransformingPath()
  * CGPathGetBoundingBox()
  * CGPathAddRoundedRect()
  * CGPathCreateWithRect()
* opalgraphics: divide OpalGraphics and "OpalImage" as an ImageIO equivalent[5]
* opalgraphics/gui: create interaction between NSColor and CGColor
* opalgraphics/gui: create interaction between NSImage and CGImage

* opaltext: introduce SFNTLayoutTypes.h
* opaltext: re-typedef enums so they are interchangeable
* opaltext: update CTFontUIFontType enum with new values
* opaltext: implement CTFontDrawGlyphs(),
CTFontManagerCreateFontDescriptorFromData()
* opaltext: define kCTFontOpenTypeFeatureTag,
kCTFontOpenTypeFeatureValue constant strings
* opaltext: update CTFontSymbolicTraits enum with new values
* opaltext: implement CTLineGetBoundsWithOptions(), define
CTLineBoundsOptions enum

6) QuartzCore (LOTS of work!)
* quartzcore: +[CATransaction setCompletionBlock:]
* quartzcore: major CALayer additions
  * -[CALayer setBorderWidth:]
  * -[CALayer setMask:]
  * CALayer.name
  * CALayer.drawsAsynchronously
  * CALayer.doubleSided
  * CALayer.borderRadius
  * CALayer.edgeAntialisingMask
  * -[CALayer renderInContext:]
  * CALayer's all sorts of filters
  * CALayer.contentsScale
  * CALayer.anchorPointZ
  * CALayer.borderColor
* quartzcore: CAAnimation additions
  * quartzcore: -[CAAnimation isRemovedOnCompletion]
  * quartzcore: CAAnimation.keyTimes
  * quartzcore: CAAnimation.timingFunctions
* quartzcore: implement CAValueFunctions
  * -[CAValueFunction name]
  * +[CAValueFunction functionWithName:]
  * generate CAValueFunction selection name constants
* quartzcore: create unimplemented layer subclasses
  * CAOpenGLLayer
  * CAShapeLayer
  * CATransformLayer
* quartzcore: new include guards for CATransform3D to operate
ObjC-independenty (incorporate to current PR)
* quartzcore: make NSView interact with CALayer[6]

7) GUI (LOTS of work too implementing modern APIs mostly)
* gui: create NSGestureRecognizer
* gui: create NSPasteboardItem
* gui: create NSTextAlternatives
* gui: create NSRunningApplication
* gui: create NSSharingService
* gui: create NSVisualEffectView
* gui: create NSUserInterfaceLayout* enums (+ support in NSCell)
* gui: create NSAccessibility functions and categories
* gui: implement new NSWritingDirection enum values +
NSWritingDirectionAttributeName (NSAttributedString)
* gui: implement NSBackgroundStyle for NSCell
* gui: NSSpellChecker: -showCorrectionIndicatorOfType:...,
-dismissCorrectionIndicatorForView: (OSX 10.7)
* gui: -[NSEvent isDirectionInvertedFromDevice]
* gui: NSEvent: implement phases (NSEventPhase)
* gui: implement NSPasteboardWriting, NSPasteboardReading protocols
* gui: NSPasteboard: implement NSPasteboardType* constants; options
* gui: -[NSScrollView setScrollerKnobStyle:]
* gui: implement NSScrollView contentInsets, scrollerInsets
* gui: NSScroller: implement scroller style
* gui: implement NSSpeech property constants
* gui: -[NSTextField sizeThatFits:]
* gui: -[NSTextList startingItemNumber] (OSX 10.6)
* gui: -[NSFontManager orderFrontStylesPanel:]
* gui: NSView: implement NSFullSizeContentViewWindowMask
* gui: NSColor: handle SRGB (OSX 10.7)
* gui: +[NSCursor IBeamCursorForVerticalLayout]
* gui: -[NSWindow setStyleMask:]
* gui: NSCell.truncatesLastVisibleLine
* gui: -[NSView setShadow:]

8) libobjc2
* implement _protocol_getMethodTypeEncoding() -- requires clang ABI change
* make `nil` and `NULL` interchangeable[7]

---

That all said, I'd really appreciate opinions on the items on the list
if you've played with them before; or if there's any particular issue
you'd like to work on to help me get a working WebKit :) Equally, if
there's anything more seasoned project contributors consider more
worthy of attention than other items.

Thanks -- really -- for all the support so far,
-- Daniel.

[1]: https://trac.webkit.org/wiki/WebInspector#UsingtheWebInspectorremotely
[2]: http://lists.gnu.org/archive/html/gnustep-dev/2017-06/msg00015.html
[3]: https://github.com/gnustep/libobjc2/issues/37
[4]: https://github.com/gnustep/libs-opal/pull/1
[5]: A preliminary discussion on this can be found on
http://lists.gnu.org/archive/html/gnustep-dev/2017-06/msg00033.html.
[6]: This item, as Ivan has already mentioned to me, is extremely
complex and should practically be considered as part of a section of
its own.
[7]: On Apple's stack, passing `nil` as a value for a raw pointer is
accepted. In many cases in WebCore, it requires `NULL` to be used
instead else the build breaks due to type conflicts.