We should decide when we want to show the Firefox branding and when the webapp branding. For example, in the case of the Plugin Blocklist we probably want to show the Firefox branding, as Firefix is the blocking agent. Mossop suggested a nice solution to selectively load different brandings in different toolkit modules: create two branding files, app-branding and ***-branding. app-branding would contain the app specific branding in the webapp runtime and Firefox's branding in Firefox. ***-branding would always contain Firefox's branding. So we would use app-branding in toolkit modules where we want the webapp branding and ***-branding where we want Firefox's branding.

In general, we should show Firefox branding on interfaces and affordances in which the runtime acts as the user agent, i.e. those in which the runtime is intervenes on behalf of the user, mediating the user's access to the app or the app's access to the user's system. An interface expressing that a plugin has been blocked is a good example of that, as are API permissions dialogs (dialogs that ask the user to confirm that an app should be able to access privileged APIs) and web forgery notices (bug 749519). Other interfaces and affordances, like the main application window, other windows opened by the app, and native touch points (desktop icon on Windows, /Applications item on Mac, entry in Programs & Features on Windows, etc.) should have app branding, so apps feel as native as reasonable. There may be some edge cases and gray areas (f.e. update interfaces, given that Windows and Mac have lacked system-wide update mechanisms until relatively recently, although they've been around for a while on Windows). Nevertheless, this general principle should guide us in most cases, and I don't think this needs further UI review in general (although specific cases may still benefit from it). So I'm going to resolve this bug, as the general approach seems reasonably well established. But please reopen if you intended the bug to track a particular aspect of the implementation, f.e. a selective loader of multiple branding files! Also note related bug 937654.

(In reply to Myk Melez [:myk] [@mykmelez] from comment #1) > There may be some edge cases and gray areas (f.e. update interfaces, given > that Windows and Mac have lacked system-wide update mechanisms until > relatively recently, although they've been around for a while on Windows). Erm, I meant to say that they've been around for a while on *Linux*.