I started writing this as a comment on a recent Beyond the Code blog post – though what I would like to say sometimes goes OT to the original post, and… Posting my comment (twice) ended-up with a blank page, pending POST, and 405 on the subsequent GET. Maybe somebody tripped on the lizard tail there and disabled comments, in a truly open-web fashion? 
Either way… This has been bugging me for quite some time, and I need to get it out of my system in order to get back to useful stuff.
Firefox’s javascript engine has a number of non-standard core extensions / features (just like some other browser). There seem to be a number of people who have grown used to these in the past (doing too much xul is bad for your health, you know?), and there also are a number of newbies who learn javascript using mdn, not necessarily paying attention to what is standard, deprecated, obsolete, and what not.
Having to refactor such codebases, written under the influence, may require a cheat sheet to quickly spot firefoxisms, and there doesn’t seem to be a good list out there.
So, let’s try establishing that list. If something is not there, add a comment on that post.
The purpose is not to list what might work, and where – just what is not standard among Firefox features (and using non-standard features is pretty bad, right?). In other words, what should just be avoided / removed, in a web context aiming at being cross-browser.
[UPDATE]
Just found Kangax great list.
The Asynchronous Module Definition pattern (or AMD for short – possibly one of the most clumsily nicked concept in computing history) is an attempt at “solving” javascript lack of a good, native, code modularization and dependency resolving solution.
Indeed, while javascript lets you organize your code in a fairly intuitive and malleable way (say: MyLibrary.someNamespace.someModule), there is no (native) way to express (nor “fetch”) dependencies, which leaves javascript developers with unsolved problems:
Apps that want a custom title bar on OSX usually have a NSBorderlessWindowMask on the NSWindow, with the drawbacks of:
But it’s possible to fix #2.
The trick is pretty much how to access the user preference:
NSString *const MDAppleMiniaturizeOnDoubleClickKey = @"AppleMiniaturizeOnDoubleClick";
NSUserDefaults *userDefaults = [NSUserDefaults standardUserDefaults];
[userDefaults addSuiteNamed:NSGlobalDomain];
bool shouldMinimize = [[userDefaults objectForKey:MDAppleMiniaturizeOnDoubleClickKey] boolValue];
And voilà. The rest is piece of cake: catch double click on your custom header, check the value of shouldMinimize, then call minimize on your window.
We implemented it successfully in Roxee (QT).
Credit goes to user NSGod on stackoverflow.
Applications on Mac that wish to have a “custom” title bar can go two roads.
The easiest IMO (and the one that allow seamless integration with the app body itself) is to go Qt::FramelessWindowHint (or NSBorderlessWindowMask).
This is what we do – and I’m pretty sure this is what Rdio does as well.
Usually, that means you have to implement moving yourself (and probably resizing as well).
There is one caveat: there is no Cocoa programmatic way (AFAIK) to make the app switch workspace (this is usually triggered when moving an app to the current space edge, and waiting a bit).
So, our Roxee client fails here…
Spotify works ok (but I’m pretty sure they don’t do NSBorderlessWindowMask, but rather have a custom title bar).
And Rdio fails, just like us.
At least, we are not alone.
And I would be glad to hear about any solution to this that doesn’t involve messing with private Cocoa API…
[UPDATE]
Rdio guys know about this
Wow, tricky bug … Let’s say you have a Facebook application in Sandbox mode. You are working as a connected Facebook user. You’re using FB.getLoginStatus() and everything is working fine.
Now you want to test your code with an unauthorized user. It works. With unlogged user, your callback is not fired, blackout, KABOOM !!!
You’re are NOT doing it wrong ! This a bug …
This bug is well known by their developers but flagged as “By design”. In other words “won’t fix” !
Here is my workaround.
We all know that awkward moment when your only ticket left is “Emailing / newsletter module”. Which basically means :
Fortunately, like so many things today, there’s an API for sending email and making your life easier ! As a lazy developer I started investigating plug-and-play solutions first. Here is a non exhaustive list of what came up.
QT 4.8.1 (and previous) has a nasty bug making mighty mouses, mac trackpads and other “sensitive” devices pretty much unusable. The WebView scrolling becomes jerky, irregular and very long-lasting.
The likely cause is that mighty mouses and the like dispatch a bigger number of events, with smaller deltas, causing the webview to literally choke trying to repaint.