Despite all the hype about how everyone’s making advertising more targeted and therefore more useful to people, you still get gaffs like this one:

The advertising industry is booming and ads are popping up in more and more places, but the quality of ads are still really bad. It’s no wonder ad blocking technology has become so popular.

On a side note, it’s also somewhat worrying that there’s a minimum $10,000 investment for finding oil in the Gulf of Mexico – seems pretty easy to find at the moment…

Normally applets run in a security sandbox, much like JavaScript, but with signed applets those restrictions are lifted and the applet can do anything. At least, that’s the theory – in practice most implementations leave a security manager instance installed but with significantly reduced restrictions (such that most programs will never be affected by them). To get around these remaining restrictions, applets can remove or replace the security manager:

System.setSecurityManager(null);

Having set a null security manager though, you will start to get NullPointerExceptions in Firefox on OS X when you try to call Java methods from JavaScript (via LiveConnect). Basically, Firefox is assuming that there will always be a security manager in place. To get LiveConnect working again, rather than setting the security manager to null, simply create a new security manager that allows everything:

System.setSecurityManager(new SecurityManager() {
    @Override
    public void checkPermission(Permission perm) {
    }
});

No more exceptions from Firefox and LiveConnect is working again, but still no restrictions on what you can do. For the record, the exception Firefox will give is:

java.lang.NullPointerException
at netscape.oji.JNIUtils.checkClassAccess(JNIUtils.java:106)
at netscape.oji.JNIUtils.checkClassAccess(JNIUtils.java:68)
at java.lang.Class.getDeclaredMethods0(Native Method)
at java.lang.Class.privateGetDeclaredMethods(Class.java:2427)
at java.lang.Class.privateGetPublicMethods(Class.java:2547)
at java.lang.Class.getMethods(Class.java:1410)
at netscape.oji.JNIRunnable.run(Native Method)
at netscape.oji.LiveConnectProxy.run(LiveConnectProxy.java:48)

I’ve been trying to solve this problem pretty much since Aperture 3 came out with it’s Places/GPS support. Every time I added location information to a photo, it wound up being tagged as where I really took the photo but also a completely incorrect, but consistent location (for me it was always The House of Binns in Scotland). Location information pops up in so many different places in Aperture and displayed in so many different ways that it was really hard to track down what was going on – sometimes it would have the first part of the place name right, but then had the country incorrectly shown as Scotland.

Today I finally worked out what was happening. The key thing to understand is that your photos aren’t tagged with a place name, the photo metadata only includes GPS coordinates. Aperture then maintains a separate database of place names which includes the name, the GPS coordinate at the center and the size of the place (as a radius). So a place record for your home address would have a very small radius, but you could just as easily create a place for an entire country with a big radius. When Aperture wants to display location information, it simply finds a list of all the places it knows about whose location and radius includes the photo’s GPS coordinates. As such, a photo might be in any number of “places”.

So the reason the photos are being incorrectly labelled, is that somehow a place was created called “The House of Binns” with it’s central location at The House of Binns in Scotland, but it’s radius roughly big enough to include most of Europe. So any photo taken anywhere in the UK or half of Europe was within the range of this place called “The House of Binns”.

To view the places that you’ve defined, simply go to the “Metadata” menu and choose “Manage My Places…”. You’ll get a dialog very much like the one for Assign Location but when you click on a place name in the left column a little minus icon appears. Simply click that icon to remove the place from your database, or adjust the location and radius on the map. Deleting places in this dialog won’t remove the GPS coordinates from your photos – only the particular name mapping you’ve added.

Anyone who’s done much work with JavaScript has probably discovered that the selection APIs are completely different in Internet Explorer vs the rest of the world, what comes as a bit more of a surprise once you start using them in anger is that FireFox is actually quite different to all the other W3C compliant browsers in an important way as well.

If all you ever want to do is retrieve the selection or you only want to work with ranges rather than selection, you’ll probably never encounter this, but as soon as you use window.getSelection().addRange() you’re going to get bitten. The difference is that FireFox will preserve whatever range you give it precisely as you original created it. The other browsers won’t.

Start with a simple document with three paragraphs:

<body>
  <p>Paragraph 1</p>
  <p>Paragraph 2</p>
  <p>Paragraph 3</p>
</body>

Create a range where the startContainer and endContainer are the body element:

var range = document.createRange();
range.setStart(document.body, 0);
range.setEnd(document.body, 1);

The range now encompasses the entirety of the first paragraph element – including the actual P element itself, not just the text within. Now add that to a selection:

window.getSelection().addRange(range);

In FireFox this selects the paragraph element, but in Opera, Safari and Chrome the selection is now just the text within the paragraph. So in FireFox and only FireFox, the statements below are true:

var selected = window.getSelection().getRangeAt(0);
selected.startContainer === range.startContainer === document.body;
selected.endContainer === range.endContainer === document.body;

This isn’t an arbitrary change by Opera, Safari and Chrome – as far as I can tell, they really can’t select actual elements, only textual ranges. So if you add a range that includes elements, the selection winds up encompassing just the text of those elements and that’s correctly reflected in the range the selection returns. I’m unsure which behavior is correct or whether this is just a missing part of the standard altogether. It appears that the whole concept of a selection object is an old Netscape 4 thing that has never actually been defined1.

Unfortunately, selection is one of those surprisingly difficult concepts to get right in any rich text editor due to the complexity of what users want to select and how that affects the operations they will then perform. With these kinds of differences in browser behavior, JavaScript based editors really are fighting an uphill battle that they shouldn’t have to.

1 – Range has been defined by the W3C, but the selection object doesn’t appear to have been.↩

This has been said before but apparently even really smart people aren’t listening. So here’s my top two tips for job applications:

1. Tailor your résumé. If you’re applying for a JavaScript job, highlight the JavaScript experience you have first and foremost. Even something as simple as the order you list skills in makes a difference – if JavaScript is at the end of a list of skills, it’s probably not a priority, if it’s first it makes it seem more important to you, so you seem more qualified.
2. Get a blog, make it look good, fill it with good content.

The corollary to number 2 is that you should set your FaceBook page to private – it never seems to be what you want to have turn up. It’s surprising how many blogs have relatively good technical content but look terrible. Even if you’re not going to be applying for design jobs, having a decent layout without broken images is always helpful.

But really, tailor the résumé – it’s crazy that people don't do this.