When I run a webapp by clicking its native icon on the Mac, it apparently registers itself with the OS as a handler for http: clicks, as some http clicks from other apps bring my webapp to the front rather than an actual browser.
This probably has something to do with the fact that we re-use the firefox-bin from the originating browser (which would have registered for http: clicks). The stand-alone app isn't really stand-alone in that it's not a different binary running the process that controls the app window.
It's enough to make this style of app effectively unusable, because it means that some set of URL clicks from other apps either need to be copy-pasted into the real Firefox, or, if that's not possible, they simply can't be viewed. This should be fixable, I think, with some preference tweaking in the profiles for those apps. http://mxr.mozilla.org/comm-central/source/mozilla/browser/app/profile/firefox.js#555 should help you get started. The code in Gecko that handles this stuff is extra ugly, feel free to ping me for help digging through it, as I served some time there. :-)
To be clear, I'd start by working with the "expose" preferences slightly below the link I pasted. That said, this stuff is all inter-related...
It's possible this may still be a issue. On Safari, I noticed that each web application was registered as a "browser" that you could default to. This sounds like incorrect behavior. Would this issue be linked to the bug specified here?
Open a new bug for comment 4. Confirm it does not happen?
Does this still happen? I have a number of native apps installed and none of them show up in Safari and launching some of them then clicking a link from TextEdit still results in my default browser.
I see three native apps in Safari's "Default web browser" dropdown menu. But they're all apps I installed a while ago, back when the runtime was under heavy development, and before we ripped out a bunch of Firefox from the runtime. And I'm unable to reproduce with new app installations on the latest nightly build. So I suspect that this was a problem with the original implementation, against which dmose filed this bug, and with early versions of the new implementation, but it isn't a problem anymore.