Submit Hint Search The Forums LinksStatsPollsHeadlinesRSS
14,000 hints and counting!

10.4: Build a better Safari Web Browsers
Tiger only hintOne of the cooler things that's happened at WWDC this week (other than that minor Monday announcement) is the launch of a new Apple open-source site. The WebKit Open Source Project is the new home of all work on WebKit, WebCore and JavaScriptCore. These are the frameworks behind Safari (and other applications). This is exciting for a number of reasons -- bugs and fixes are now publicly viewable, and if you're much brighter than I am, you can even modify the code and submit bug fixes and new features back to Apple for possible inclusion in the next official Safari release. But since I lack such skills, I found the most interesting bit to be this: you can now build your own version of Safari from code that's newer than the latest public release.

Why might you want to do this? Because the Safari team is constantly rolling fixes and enhancements into the code base, and sometimes, it's nice to have those new features now rather than later. Consider, for instance, the browser stress-test known as the Acid2 Browser Test. This test is designed to see how well browsers support some of the more leading-edge features of HTML and CSS, and how well they deal with errors in such code. The final output is quite simple -- a smiling face. But it's built using some complex code, and not many browsers do very well at it.

Below is a comparision picture showing how well the two versions of Safari do at the test. On the left is the released version of Safari, in the middle is the built-from-source version of Safari, and on the right is the ideal "reference image" for what you should see.


As you can see, the built version of Safari handles that page much better (the left-most image has been trimmed, too. The red-orange fill extends to the width of your browser window). This new version also loads pages faster, and has a number of other bug fixes. Best of all, installing this version of Safari does not replace your current version of Safari, so you actually have the best of both worlds -- as there are some risks associated with using bleeding-edge source code, it's good that the old version is retained. What you're actually building are the new frameworks within Safari, and these frameworks do not overwrite the default ones. You'll use the Terminal to launch your modified Safari while a double-click in the Finder will launch the standard Safari.

Read on for how I built it from source, as well as a couple of gotchas to watch out for. And the usual disclaimer applies: although this hint should not hurt anything on your machine, it's possible that it just might. So please, have a recent backup, and proceed at your own risk (which should be minimal; this is pretty simple stuff). If you're comfortable typing and editing files in the Terminal, have XCode installed, and don't mind a bit of waiting, then you can probably get through this process (Apple has made it quite easy).

The Getting the Code and Building Webkit pages of the Apple site contains detailed instructions on exactly what you'll need to do. If you have lots of experience with compiling applications, just head over there and follow their directions. I'll repeat their instructions here, with added details based on my experience. I'm assuming you have XCode installed (version 2.0, not the newly available 2.1. If you have 2.1, you'll need to modify the installation process), the Terminal open, and that you know how to edit files in the Terminal. I'm also assuming you have not checked things out from CVS (see below) before, nor have your own already-existing builds directory. If any of the above is false, modify these instructions based on your setup.
  1. The WebKit code is stored in something called a CVS, or Concurrent Versioning System. To download the files, open the Terminal and type these commands (text marked /* like this */ is a comment; don't type any of it):
     $ cd ~ /* change to your home directory, just in case you're not there. */
     $ touch .cvspass /* required to make CVS access work -- only needed once */
     $ mkdir builds /* the new build directory; do not put spaces in its name */
     $ cd builds /* change to build directory */
     $ cvs -d :pserver:anonymous@anoncvs.opensource.apple.com:/cvs/root login
       /* the above command connects to Apple's WebKit CVS. Enter 'anonymous' */
       /* for the password when prompted.                                     */
     $ cvs -d :pserver:anonymous@anoncvs.opensource.apple.com:/cvs/root co -P WebKitTools
       /* check out (download) the WebKitTools module */
     $ WebKitTools/checkout /* this script does the rest of the hard work */
    
    The last step will start a long string of onscreen updates, and when it's done, you'll have the WebKit files on your local machine. Once you've done this once, you can update your version at any point by running this command from the builds directory: WebKitTools/Scripts/update-webkit

  2. Now it's time to build the code. First, launch XCode (in /Developer/Applications), and open its preferences. In the Building section, click the 'Customized location' button in the 'Place Build Products in' section. You need to point it to a directory containing the files you're about to download. Given the number of files involved, it's best to create a new folder somewhere. Make sure that the path to the folder does not contain any spaces. I created a builds folder inside my user's home folder. As such, the path I entered here was /Users/robg/builds. Don't change anything else, click OK, and quit XCode.

  3. In the Terminal, make sure you're in your builds directory (cd ~/builds), then type WebKitTools/Scripts/build-webkit. Now sit back and wait. And, depending on the speed of your machine, wait some more. And maybe a bit longer. OK, just a touch more. Watch all the pretty text go flowing by. Doesn't it look nice? Almost done now. There! You finally have your Terminal prompt back.
At this point, congratulate yourself! If no errors came back that stopped the compile, you've now got the new WebKit frameworks installed on your machine. If you got errors, it's probably due to one of these things:
  1. You didn't install the full XCode package. This tripped me up at first, as I had chosen to not install some pieces of the Dev Tools that I didn't think I'd ever need. I re-ran the XCode installer and selected basically everything other than documentation, and my second attempt at compiling worked fine.
  2. You have version 2.0 of Bison installed via Fink or some other method. OS X includes Bison 1.28. Bison is a "parser generator" (whatever that may be) that's required for the compilation to work. I'm not sure of the workaround for this one; I think it involves removing the paths to Bison 2.0 from your PATH so that only the stock version 1.28 is seen by the scripts.
  3. You have a space somewhere in the path to your builds folder. Remove the space and everything will work fine. Make sure you manually update the setting in XCode's preferences, too!
  4. The path you set in XCode differs from the one you're actually using in the Terminal. Make sure XCode points to the same folder you're using in the Terminal.
At this point, you can theoretically launch the "new and improved" Safari from the Terminal by typing WebKitTools/Scripts/run-safari from the builds folder (or put the WebKitTools/Scripts folder into your $PATH so you can type it from anywhere). Try it and see if it works. If it does, Safari will open, and you can check you have the new frameworks running by loading the above-linked Acid2 Browser Test. If it looks basically right, you're running the new Safari.

However, when I tried the run-safari script, I got this error:
Can't find executable at /Users/robg/builds/Deployment/JavaScriptCore.framework/
 Versions/A/JavaScriptCore; have you built successfully?
Since I'd just watched the compile finish, I knew I'd built successfully. Thanks to nkuvu in this thread on the macosxhints' forums for finding the cure. For both he and I, a modification to the run-safari script was required. I haven't seen this mentioned elsewhere, so I'm not sure why. But the fix is quite simple. Navigate into the WebKitTools/Scripts folder, and open run-safari with your favorite editor. Jump to line 48, which will look like this:
$productDir = "$productDir/Deployment";
Change it to this:
$productDir = "$productDir";
Save the file, quit the editor, and try the script again. Bingo! Welcome to the new Safari. From now on, just use run-safari when you want to load Safari with the new frameworks, and double-click Safari's dock icon to run it with the old frameworks. The version I built last night seems quite stable, and I haven't found any obvious bugs yet (though I'm sure there may be some in there). I don't intend to build a new one every night, but I will keep an eye on Surfin' Safari, which is Safari lead engineer's Dave Hyatt's blog, for any notable updates to the source.
    •    
  • Currently 2.00 / 5
  You rated: 1 / 5 (4 votes cast)
 
[39,128 views]  

10.4: Build a better Safari | 40 comments | Create New Account
Click here to return to the '10.4: Build a better Safari' hint
The following comments are owned by whoever posted them. This site is not responsible for what they say.
Hurray
Authored by: Moo0 on Jun 08, '05 10:00:49AM

Works like a charm, thanks for the clear explanation.

Too bad it spits out so much debug-info - maybe slowing down Safari while it's doing so.



---
p0m



[ Reply to This | # ]
iCab did it before ;-)
Authored by: Herve5 on Jun 09, '05 04:48:07AM

FWIW, the last release of iCab 3 passes Acid2 like a charm...

Also, the format of iCab's 'complete page archives' is open (contrary to Safari's?)...

There is a life aside Safari ;-)
Herv



[ Reply to This | # ]
iCab did it before ;-)
Authored by: Spartacus on Jun 10, '05 05:55:54AM

I don't remember ever seeing a *release* of iCab. ;-)

If I remember correctly, it went from iCab 1 beta to iCab 2 beta a while ago because they reached the twentieth public beta. Is it the same with iCab 3?

Anyway, I used to like iCab but I dropped it in the days when it didn't render CSS1. Maybe it's time to have anogther go at it.



[ Reply to This | # ]
10.4: Build a better Safari
Authored by: djones on Jun 08, '05 10:06:56AM

This is incredible news! Now, the masses just need to unite, and spam the bug tracker with "Aqua widgets overwrite site specified form element styling" so they realize how much designers hate this aspect of Safari. Sure, use them if there's no CSS styling given, but when the designer has set specific styling for buttons and forms, it's downright retarded, and breaks the user experience on those sites.



[ Reply to This | # ]
They know
Authored by: multicolorzephyr on Jun 08, '05 05:49:20PM
http://webkit.opendarwin.org/projects/forms/index.html
For input fields and text areas, we plan to use HTML editing to implement these controls, and for the other controls custom renderers will be made. A new theme abstraction will be used to encapsulate the rendering of a native look on the platform with NSCells being used to determine the correct appearance of controls like checkboxes and buttons on OS X.


[ Reply to This | # ]
10.4: Build a better Safari
Authored by: Glitterchick on Jun 11, '05 05:03:52PM

Ugh, no. I'm a web designer, but I prefer the standard Aqua widgets. Having someone else's choice of colours/styles for things like scrollbars, drop-down lists etc breaks the user experience for me. Not all designers agree with you I'm afraid!



[ Reply to This | # ]
10.4: Build a better Safari
Authored by: restiffbard on Jun 08, '05 10:07:20AM

Also, be sure to join the IRC channel #webkit on irc.freenode.net. Nice bunch of folk in there.



[ Reply to This | # ]
Maybe stupid question...
Authored by: junkiesxl on Jun 08, '05 10:20:39AM

Whats keeping the linuxfans from using this webkit (instead of their KHTML holyness) ? Are their still major technical hurdles to overcome to make this compile on linux ?



[ Reply to This | # ]
Maybe stupid question...
Authored by: Moo0 on Jun 08, '05 12:12:48PM

besides the license, the ties with OS X's framework and code, and the fact that KHTML already exists on Linux?

Not much - it would be quite some work, but perhaps even easier then importing all fixes to KHTML.

---
p0m



[ Reply to This | # ]
10.4: Build a better Safari
Authored by: sparty3 on Jun 08, '05 10:22:04AM

OK, now that I've got it built...does anyone have an expansion on the "TODO: Talk about how to replace your system WebKit.framework, and why you probably don't want to, once we have scripts that help you do that." note in the build instructions?

In particular, I've been using Safari with the new framework for more than ten minutes now without noticing any problems, so I'd like to use the new WebKit, at least with Safari, by default. However, when I open new pages and such, the "normal" Safari install is getting the pages, not the updated one. Furthermore, I can't add the run-safari script to my Dock, which would make starting Safari harder.

Any thoughts?

(I'm rather close to finding the relevant .Framework dirs on my machine and moving stuff to see what happens, but I suppose I should wait at least another half hour before doing that.)



[ Reply to This | # ]
10.4: Build a better Safari
Authored by: jasenko on Jun 08, '05 10:26:25AM

That is easy, just replace the Webkit.framework in /System/Library/Frameworks and add other frameworks to the same folder (Javascript, Webcore...)
Run your newly built Safari and enjoy it



[ Reply to This | # ]
10.4: Build a better Safari
Authored by: Tony Arnold on Jun 08, '05 04:58:48PM

Ack, DON'T DO THIS!!!!

For one thing, this version of WebKit appears to crash Dashboard Widgets if they are run against the newly compiled framework. Seriously, stick with the script for your own safety.



[ Reply to This | # ]
10.4: Build a better Safari
Authored by: jasenko on Jun 08, '05 08:55:55PM

Yup, you are right, I found that Installer and Software Update are also crashing.
For me, it's a small price to pay to get usable Safari. If you are uncertain what's best for you, don't do this.



[ Reply to This | # ]
10.4: Build a better Safari
Authored by: kahless on Jun 08, '05 11:53:30AM
Check out this hint for creating a .term file and modify the hint so that it will execute run-safari. I am in the process of trying to do this now. Once the .term is done you should be able to put it in the Dock and have it launch the Development Safari.

[ Reply to This | # ]
10.4: Build a better Safari
Authored by: kahless on Jun 08, '05 01:36:48PM
I have a working .term called SafariDev.term that will launch Safari using run-safari but will not display a Terminal window. It is kind of long so I don't think I can post it but the general idea is to open a Terminal window and then do File -> Save. In the dialog box give the term file a name and under "When opening this file:" select "Execute this command" and paste in the path to run-safari. I also checked "Execute command in shell". The file should be saved to ~/Library/Application Support/Terminal/filename.term. If you would like to prevent a Terminal window from showing up then open filename.term in your favorite text editor and search for

<key>IsMiniaturized</key>
<string>NO</string>
and change NO to YES and save. You should now be able to put filename.term in the Dock and use it to launch the development version of Safari.

[ Reply to This | # ]
10.4: Build a better Safari
Authored by: LegoEvan on Jun 08, '05 12:00:49PM
Make an automator application that runs the shell script

/Users/name/builds/WebKitTools/scripts/run-safari
Then you can change the icon and everything. You can even set the application as the default .html program, etc. Evan

---
--
Give me a lever large enough and a place to stand, and I will make use of Fudd's Law.

[ Reply to This | # ]

10.4: Build a better Safari
Authored by: kuginomura on Jun 08, '05 02:47:02PM

nice hint. however, the script application seems to hang up everytime i run it...and i have to force quit the script application. but safari runs fine using the new WebKit.

it seems possible to also set an Automator workflow to do a new build...has anyone tried this yet?



[ Reply to This | # ]
10.4: Build a better Safari
Authored by: adrianm on Jun 08, '05 10:25:08AM

The change you make to the run-safari script is because the default build location for xcode changed between xcode 2.0 and 2.1

Hopefully Apple can make their script xcode version aware soon.



[ Reply to This | # ]
10.4: Build a better Safari
Authored by: robg on Jun 08, '05 11:00:40AM

But I'm not running 2.1, and I thought the script was setup for 2.0? Ah well; it's working now, and I'm happy :)

-rob.



[ Reply to This | # ]
10.4: Build a better Safari
Authored by: diamondsw on Jun 08, '05 10:58:29AM

Spaces don't affect the build directory. My build location was "~/Library/XCode Builds", and no problems at all.



[ Reply to This | # ]
10.4: Build a better Safari
Authored by: robg on Jun 08, '05 11:17:03AM

This was noted as a problem in some of the comments on Dave's blog; perhaps the script has been updated by now. Thanks for the clarification.

-rob.



[ Reply to This | # ]
10.4: Build a better Safari
Authored by: voldenuit on Jun 09, '05 12:32:34AM

Updated indeed, quote from the Webkit changelog:

2005-06-07 Darin Adler <darin@apple.com>

Change by Mark Rowe <opendarwin.org@bdash.net.nz>.
Reviewed by me.

- fixed the WebKit half of build failure with spaces in the path
http://bugzilla.opendarwin.org/show_bug.cgi?id=3291

* WebKit.pbproj/project.pbxproj: Quote DERIVED_FILE_DIR when it is substituted
into FRAMEWORK_SEARCH_PATHS, and SYMROOT when into HEADER_SEARCH_PATHS.



[ Reply to This | # ]
Is it 10.4 only?
Authored by: lamon on Jun 08, '05 11:23:58AM

I didn't look at this in detail, but would building for Panther fail? A better Safari on my old Tibook would be great...



[ Reply to This | # ]
Is it 10.4 only?
Authored by: qwerty denzel on Jun 09, '05 08:52:09AM

I'm too lazy, but yes, does anyone know?



[ Reply to This | # ]
Is it 10.4 only?
Authored by: mazatty on Jun 10, '05 01:35:33AM

yep it fails, looking for a string function only in Tiger.



[ Reply to This | # ]
10.4: Build a better Safari
Authored by: Frida's Boss on Jun 08, '05 11:35:14AM

    /bin/sh -c "\"/Users/whore/builds/WebCore/ /Users/whore/builds/WebCore.build/Deployment/WebCore.build/
     Script-932FC10B0824A4D4005B3C75.sh\"" /Users/whore/builds/WebCore/ /Users/whore/builds/WebCore.build/
     Deployment/WebCore.build/Script-932FC10B0824A4D4005B3C75.sh: line 2: /Users/whore/builds/WebCore/ 
     /Users/whore/builds/Deployment/JavaScriptCore.framework/PrivateHeaders/create_hash_table:
      No such file or directory
** BUILD FAILED **
any ideas for a new guy?

[ Reply to This | # ]
10.4: Build a better Safari
Authored by: LegoEvan on Jun 08, '05 12:02:16PM

Your user name is whore? Heh.

---
--
Give me a lever large enough and a place to stand, and I will make use of Fudd's Law.



[ Reply to This | # ]
10.4: Build a better Safari
Authored by: Frida's Boss on Jun 08, '05 12:03:29PM

Yes. My mother has an odd sense of humor.



[ Reply to This | # ]
10.4: Build a better Safari
Authored by: Frida's Boss on Jun 08, '05 06:05:00PM

Anybody have any suggestions? I get the same error at home on my PowerMac.



[ Reply to This | # ]
10.4: Build a better Safari
Authored by: koen on Jun 25, '05 06:46:58PM

I had a similar error. I solved it by copying JavaScriptCore.framework (from WebKitBuild) into WebCore/build.



[ Reply to This | # ]
10.4: Build a better Safari
Authored by: kuginomura on Jun 08, '05 03:11:52PM

i completed the build successfully, but when i run-script, i get the following:

Giant-G5:~/builds giant$ WebKitTools/Scripts/run-safari
Looking for frameworks in /Users/giant/builds ...
Built frameworks found in /Users/giant/builds
Start Safari with DYLD_FRAMEWORK_PATH set to point to built WebKit in /Users/giant/builds.
2005-06-08 11:33:34.653 Safari[3817] Taboo 0.3 loaded successfully
[3817] http://espn.go.com/:ReferenceError - Can't find variable: NewState


Safari funs fine and it's using the newly-built WebKit...but what's the above message? also, i made an Automator script application and the script seems to hang up forever so that i have to force quit it. any suggestions?



[ Reply to This | # ]
10.4: Build a better Safari
Authored by: kuginomura on Jun 08, '05 03:48:47PM

now Safari crashes when i attempt to access the acid2 test page. terminal says "Bus error"...any thoughts?



[ Reply to This | # ]
10.4: Build a better Safari
Authored by: xSmurf on Jun 08, '05 11:24:54PM

Would it be against the license for someone to post regular builds?
I'd be nice for the neophytes

---
PM G4 DP 800 / 1.25gb / 120Gb+80Gb / CD/DVD±RW/RAM/DL
- The only APP Smurf



[ Reply to This | # ]
10.4: Build a better Safari
Authored by: metiure on Jun 09, '05 09:23:57AM

I second that.



[ Reply to This | # ]
10.4: Build a better Safari
Authored by: voldenuit on Jun 08, '05 11:48:02PM

Just to complete the story, with 10.4.1 and XCode 2.1, I did not need to modify any scripts.
I think they silently assumed that people checking out the cvs version would also tend to use the most recent version of XCode.

Apple is well inspired to lessen the impact of the khtml-grudge by releasing the code.

Great hint !



[ Reply to This | # ]
Apple Has Grown Up, We're Scared Parents.
Authored by: kidventus on Jun 09, '05 03:54:16AM
OK, I am sitting here watching the new OPEN SOURCE webkit and Safari compile, and so is someone on an x86 I imagine with the news release to Slashdot already typed up waiting for the "build complete" to show. Also, we got news that Apple has always had OSX and all it's world class "switch to a Mac for it" Pro tools and iTools compiled on Intel, and it's only a few Swedish kids and a caffine drink binge away from running on un-modified Intel machines when the developer version of Mac OSX Preview gets leaked on to P2P. Gone are the excuses from Microsoft and Linux users about Apple's beautiful applications and operating system "their platform is closed, they sprinkle fary dust on their PowerPC processors".

Nope, you just suck.

All of this and Steve saying the heart of a Mac is not it's hardware (I had to wipe the tears from my Powerbook's aluminum case for hours) but it's operating system. Everyone in the media and on chat boards didn't get what "Just In Case" meant.. he wasn't talking about switching to Intel chips in his hardware, he was making sure he could shrink wrap it and sell it at Best Buy in case Apple didn't recover, folks. That was Just In Case. The fact the hardware side will still live and x86 came out of the closet for that reason is a sigh of deep relief.

So, we are witnessing a change for Apple, and it's a good one. But it's not ours anymore. The entrance fee is not thousands anymore. I think that's what we are mourning. There was no fary dust, and now everyone can eat.

As it was with iTunes, is now with Safari and forever shall be with x86 OSX.

Time to run the script



[ Reply to This | # ]
I've done the work for you!
Authored by: watersb on Jun 10, '05 06:55:48PM
I have built a copy of the new improved open-source WebKit on OpenDarwin and with some work I have built an application launcher that runs Safari with this WebKit.

Web developers who do not wish to build the WebKit from source, but want to test content against this version, can use this as easily as they might use any other Macintosh GUI application.

  1. Download the disk image
  2. md5sum 7367c911425d888b81cb66549bf62eb2 SafariOnAcid.dmg

I have tested this distribution on Tiger, but I believe it should work on OS X 10.3.9...

This launcher does not replace the default system WebKit, and you can run "standard" Safari at any time -- even at the same time -- by launching Safari the usual way.

The launcher is a simple perl script, adapted from the "run-safari" script that's included with the WebKit open-source. It tells the system to use the local, new copy of WebKit when it runs Safari.

The popular plug-in PithHelmet does not work with this application wrapper, but you can use the standard Safari with PithHelmet just fine.

[ Reply to This | # ]

I've done the work for you!
Authored by: s_evans on Jun 11, '05 10:50:06PM

Thanks for posting SafariOnAcid!

Just to confirm, does this mean when you perform a function that would result in Safari launching (e.g. clicking on a web page in an email) it will continue to run the original (10.4) Safari. In otherwords SafariOnAcid has no other impact on the system and if it's deleted eveything runs as before?

Thx...Steve



[ Reply to This | # ]
Optimized Safari
Authored by: Pedro Estarque on Jun 15, '05 04:18:45PM

Can anyone make a G4 optimized built ?
Similar to the Firefox ones



[ Reply to This | # ]
Released
Authored by: beccles on Nov 03, '05 02:46:26PM
Hey-hey! With the official release of Safari 2.0.2, it is now "the first (publicly-released, non-beta, non-preview) browser to successfully pass the Acid2 test." webstandards.org, 31 Oct 2005

[ Reply to This | # ]