Archive for the 'Safari/WebKit' Category

Apple documentation search that works

Sunday, March 6th, 2011

You’ve probably tried searching Apple’s developer documentation like this:

The filter field on the ADC documentation library navigation page.

Edit: That’s the filter field, which is not what this post is about. The filter sucks. This isn’t just an easy way to use the filter field; it’s an entirely different solution. Read on.

You’ve probably been searching it like this:

Google.

(And yes, I know about site:developer.apple.com. That often isn’t much better than without it. Again, read on.)

There is a better way.

Better than that: A best way.

Setup

First, you must use Google Chrome or OmniWeb.

Go to your list of custom searches. In Chrome, open the Preferences and click on Manage:

Screenshot with arrow pointing to the Manage button.

In OmniWeb, open the Preferences and click on Shortcuts:

Screenshot of OmniWeb's Shortcuts pane.

Then add one or both of these searches:

For the Mac

Chrome OmniWeb
Name ADC Mac OS X Library
Keyword adcmac adcmac@
URL http://developer.apple.com/library/mac/search/?q=%s http://developer.apple.com/library/mac/search/?q=%@

For iOS

Chrome OmniWeb
Name ADC iOS Library
Keyword adcios adcios@
URL http://developer.apple.com/library/ios/search/?q=%s http://developer.apple.com/library/ios/search/?q=%@

Result

Notice how the results page gives you both guides and references at once, even giving specific-chapter links when relevant. You even get relevant technotes and Q&As. No wild goose chases, no PDF mines, no third-party old backup copies, no having to scroll past six hits of mailing-list threads and Stack Overflow questions. You get the docs, the right docs, and nothing but the docs.

For this specific purpose, you now have something better than Google.

Setting the iPhone API documentation to iPad display mode on your Mac

Monday, April 5th, 2010

Those who’ve bought iPads have noticed that the iPhone API documentation comes in a special iPad-optimized flavor:

Basically, like an iPhone app for viewing the iPhone documentation. Here's a screenshot of the page in Safari on my Mac.

Yes, that’s desktop Safari showing it.

Contrary to my expectation, it does not use user-agent sniffing to detect an iPad. In fact, it’s detected by a JavaScript script (credit) when you go to an iPad-specific front page.

The code has a debugging feature, which they left in and you can (for now) enable to use the iPad display mode in your WebKit-based browser. Here’s how to enable it:

  1. Open any page on developer.apple.com.
  2. Open this URL:

    javascript:localStorage.setItem('debugSawtooth', 'true')
  3. Go to the iPad documentation list.

There are actually two interfaces, corresponding to the two orientations of a physical iPad. The one I showed above, with the API tree in a sidebar, is the landscape orientation; portrait moves the API tree into a pop-over, under a button labeled “Library”. The page chooses one or the other by the aspect ratio of the window.

“Sawtooth” has some drawbacks:

  • On a Mac, your scroll wheel (or two fingers) won’t work; you must drag the interface instead, which corresponds to finger-dragging on the actual device.
  • Once the interface loads, its size and orientation are fixed; it won’t adapt to a window resize until you reload. This, too, is only a problem on a Mac (you can’t resize your iPad).
  • There’s no way to copy a link to a specific document, unless you can find an internal link (the API-tree table view doesn’t count). This can be a problem if you want to link to, say, a framework reference.
  • You can’t get the Sawtooth interface unless you go through the iPad front page. If you go to a framework reference, class reference, programming guide, or other more specific page, you’ll get the regular interface. Same thing when going through the regular front page.

Even so, it’s pretty spiffy. I wish I had a version with all of the above problems fixed for viewing Mac API documentation.

* Credit: JR Ignacio found the JavaScript code and excerpted it into a GitHub paste.

The trilogy is now complete

Saturday, January 23rd, 2010

The third video of last month’s meeting is now up. Here are three easy-to-remember links:

  1. http://bit.ly/CHLF2009Leaks1
  2. http://bit.ly/CHLF2009Leaks2
  3. http://bit.ly/CHLF2009WebInsp

You’ll notice that the third video is not CHLF2009Leaks3.

Unlike the other two, this one features Scott Ellsworth, our organizer, demonstrating the Web Inspector in WebKit. He starts off in Safari, then switches over to Chrome. He also talks about a profiling tool that’s part of Google Web Toolkit called Speed Tracer, although he wasn’t able to finish a demo of it in time for the meeting, so he talks about one of the examples instead.

I don’t think I’ll link these here anymore. If you want to find out about future CocoaHeads Lake Forest videos, subscribe to the CocoaHeads Lake Forest channel on Vimeo.

A note about ClickToFlash 1.2

Saturday, January 31st, 2009

Christopher Bowns pointed out (thanks!) that Jonathan Rentzsch released ClickToFlash 1.2 yesterday.

This is the first version that incorporates any significant features from my fork. Specifically:

  • It now loads the Flash movie on mouse-up, not mouse-down.
  • It now draws the ClickToFlash view as concave when the mouse is down and within its bounds.
  • It now has a separator item in the contextual menu.

The first two of these came from my tree, a fact that I am very happy about. The last one he pulled from Troy Gaul’s tree instead, but it makes no difference, as it’s just an element in a xib document.

If you’re using 1.1+boredzo, you don’t need to upgrade. My version of 1.1 has all the features of his 1.2, plus the “Copy Address” contextual menu item and, of course, my own click-to-play symbol.

ClickToFlash 1.1+boredzo

Thursday, January 29th, 2009

My fork of Jonathan Rentzsch’s adopted WebKit plug-in lives on, as I release my version of ClickToFlash 1.1.

So far, he has not pulled any of my changes into his tree, so the list of features unique to my version has only grown:

  • It loads the Flash movie on mouse-up, not mouse-down, giving you a chance to back out by moving your mouse cursor off of the movie placeholder.

  • It changes to a concave appearance when you press the mouse on the placeholder, making it look, as well as act, more like a button.

  • It has a better (IMO) click-to-play image. (Screenshots on the other post.)

  • It adds a separator menu item to the contextual menu. (New in 1.1+boredzo, and the menu itself is new in 1.1)

  • It adds a “Copy address” menu item to the contextual menu (along with another separator). (New in 1.1+boredzo)

  • It incorporates Jason Foreman’s fix for websites such as thedailyshow.com. According to him, that simple change fixes ClickToFlash on a lot of websites; I can vouch for it on thedailyshow.com, at least. (New in 1.1+boredzo)

File: ClickToFlash-1.1+boredzo.zip

The installer application, source code, and MIT license.

How ClickToFlash works

Thursday, January 29th, 2009

Speaking of everybody’s favorite WebKit plug-in, here’s how it works. This should help you understand how it fails on some sites, and maybe aid you in contributing to its development.

First off, it is a WebKit plug-in; it’s written in Cocoa and uses WebKit’s own plug-in API. It does not use the Netscape plug-in API.

A WebKit plug-in declares a list of MIME media types in its Info.plist bundle. It does this by way of a dictionary of dictionaries:

<key>WebPluginMIMETypes</key>
<dict>
    <key>application/x-shockwave-flash</key>
    <dict>
        <key>WebPluginTypeDescription</key>
        <string>ClickToFlash</string>
    </dict>
</dict>

WebKit only loads a WebKit plug-in when it first encounters some content that it needs the plug-in for. It uses these Info.plist dictionaries to know which plug-in it needs to load. So, in the case of ClickToFlash, it only loads ClickToFlash when it encounters something that is of type application/x-shockwave-flash.

Here’s the brilliant part. Adobe’s Flash Player plug-in actually declares* two MIME media types: application/x-shockwave-flash and application/futuresplash.

You will notice that ClickToFlash only declares one of these.

As it turns out, everybody only uses application/x-shockwave-flash. ClickToFlash exploits this.

When you click on the ClickToFlash view, it modifies the object or embed element that the view represents, changing its type attribute to the other type—the one ClickToFlash doesn’t declare; the one no webpages actually use. WebKit notices this change and looks again for a plug-in to handle the movie. This time, it comes up with only one handler: the real Flash Player plug-in.

There are several reasons why a site may not work with ClickToFlash. I suspect one reason is that they try to interact with the movie via JavaScript; ClickToFlash doesn’t export a script object and wouldn’t be able to communicate with the real Flash Player anyway. The script finds itself talking to a wall, and breakage happens.

So now that you know how ClickToFlash works, maybe you can help fix its bugs?


* Flash Player doesn’t declare its MIME types in its Info.plist; it declares them in a resource file, in ‘STR#’ resource 128. Thanks to WebKit developer Mark Rowe for reminding me to look for a resource.

ClickToFlash: Visible edition

Tuesday, January 27th, 2009

The WebKit plug-in ClickToFlash has been an instant hit over the past 24 hours. The original version was on a Google Code project, but that project is now closed to the public. Before the Google Code project went 0600, Jonathan Rentzsch set up a fork on GitHub to gather changes submitted by Gus Mueller and Jean-François Roy.

Unfortunately, both the original and Rentzsch’s current version have one immediately-noticeable deficiency: In place of the Flash movie, the plug-in displays only a blank gray gradient background. It’s easy to think that there’s simply nothing there, or that the page is not done loading.

I decided to solve the problem myself. I forked the fork and posted my own version (along with a binary installer).

My interpretation of the plug-in adds three features:

  1. Swap in the Flash movie on mouse-up, not mouse-down. This gives you a chance to back out by moving the mouse out of the view.
  2. Invert the gradient when the mouse is down. This makes the view look (as well as act) more like a button.
  3. Fixes the blank-background problem. A number of people have done this in other forks, but I think my solution is best:

My click-to-play symbol is a play symbol (right-pointing triangle) with a florin (ƒ), emulating the Flash logo, cut out of it.

The symbol's gradient inverts along with the background gradient.

My solution has two advantages:

  • Its drawing is fully vector-based, which means that that it will scale to fit the would-be movie’s area and will look good no matter how big the would-be movie is.
  • I designed the implementation so that you can replace it with different drawing code if you’d prefer a different click-to-play symbol.

The original, Jonathan Rentzsch’s fork, and my fork are all under the MIT license. And, of course, he is welcome to pull my changes upstream.

A note about your WordPress blog’s tagline

Tuesday, September 11th, 2007

On the general options pane, there is a field labeled “Tagline”:

Tagline: cd prh && dd if=brain of=blog

The value shown in that field is WRONG WRONG WRONG!

You see, that’s actually supposed to be HTML—or at least, such is the implication of the Atom template’s use of bloginfo_rss to get the description. The difference between {get_,}bloginfo_rss and {get_,}bloginfo is that the _rss versions call strip_tags to take out any HTML and escape any non-HTML characters, such as &.

That wouldn’t be so bad if strip_tags worked properly, but it doesn’t—not on this host, at least. It leaves the second & in the above example unescaped. (“OK, I escaped that one. It must be the only one. I’m off to Subway!”)

As if that wasn’t bad enough, WordPress doesn’t escape the tagline field’s value when putting it back into the field the next time you load up the Options pane. (It does if it’s plain text, but not if it’s HTML. Go figure.) So if you click “Update Options” again, your HTML goes bye-bye. You need to remember to re-escape it every time you save the General Options.

(Given that, maybe it’s not supposed to be HTML after all, and the use of bloginfo_rss in the Atom 0.3 template is a bug.)

Want to know how I found this out? Because the RSS reader in Safari 2 (I don’t use 3) was critically failing on the Atom feed. It was slurring posts together once it saw that an ampersand was not escaped.

Relevant versions:

  • WordPress 2.1.3
  • PHP 5.1.4 or so (I have no idea what version is actually running the blogs)
  • Safari 2.0.4/419.3

WWDC 2007 session videos are out

Monday, July 30th, 2007

If you attended WWDC, you can head over to ADC on iTunes and see what you missed.

Apple Bug Friday! 48

Friday, March 9th, 2007

I missed a couple of weeks of ABF, so I’m going to run the missed Fridays’ bugs today in addition to today’s.

This bug is Feed button does not use the standard feed icon. It was filed on 2007-02-16 at 12:27 PST.

(more…)

Report-an-Apple-bug Friday! 25

Friday, April 14th, 2006

This bug is Allow folder menu items in Bookmarks menu to open the Bookmarks view. It was filed on 2006-04-14 at 23:05 PDT.


Summary:

Safari should allow you to click on a folder item in the Bookmarks menu to open the Bookmarks view to that folder.

Steps to Reproduce:

  1. Click on the Bookmarks menu.
  2. Click on any folder item.

Expected Results:

The Bookmarks view opens, with that folder and all its superfolders expanded.

Actual Results:

Nothing happens.

Regression:

None known.

Notes:

None.


Technorati tags: ,

Report-an-Apple-bug Friday! 22

Friday, April 14th, 2006

This bug is Navigation keys don’t work in Bookmarks view. It was filed on 2006-04-14 at 22:12 PDT.


Summary:

The page-up, page-down, home, and end keys don’t work in Safari’s bookmarks view.

Steps to Reproduce:

  1. Choose “Show All Bookmarks” from the Bookmarks menu.
  2. Press page-up, page-down, home, or end, in an attempt to scroll the bookmarks view.

Expected Results:

The view scrolls.

Actual Results:

The view stands fast.

Regression:

None known.

Notes:

None.


Technorati tags: , .

On the Safari shell script exploit

Wednesday, February 22nd, 2006

reading John Gruber’s account, I had a couple of ideas on what to do about it.

  1. in Finder, when a file has a custom “Open With” assocation on it, badge the file’s icon with the application icon. in this case, it would have the Terminal icon badged onto it.
  2. in Safari, add a new warning when a file contains an “Open With” that points to an application that wouldn’t normally handle that type of file. in this case, Terminal does not normally open JFIF files, and this should cause a warning.

discuss.

Safari feed icon, continued

Sunday, January 1st, 2006

Mac OS X Hints has an article on adding the standard feed icon to Safari. Of course, I already created one and put it on my website. I also sent in my own hint linking to my icon; my hint was not accepted.

The Mac OS X Hints post has several mentions of different Safari feed icons in the comments, including me mentioning my own. One problem with the hint’s instructions is that the generated TIFF file will not have an alpha channel, leading to the ugly black corners that you see in the screenshot. AFAIK, none of the other renditions have this. Another problem is that it doesn’t affect the “Hide” button—when you go to a feed page, the button will change to say “RSS” again.

You should try all the versions, as everybody seems to have a different taste for how the “Hide” button should work. If you can’t find one you agree with, feel free to make your own interpretation.

Standard feed icon for Safari

Friday, December 23rd, 2005

Matt Brett recently created a vector-based reproduction of the standard feed icon of Firefox and IE 7. I just created a version of the standard feed icon for Safari, based on his work. Instructions included. Enjoy.