Many other about: pages are affected by this problem : about: about:about about:customizing about:downloads ... and many other. I can't make a full list, but you can check about:about.

(In reply to Tim Nguyen [:ntim] from comment #1) > Many other about: pages are affected by this problem : Confirmed 30.0a1 (2014-02-10), win 7 x64

Some about pages do show it properly though.

Thanks for the report, didn't notice this one before "hooking up" bug 970382 so duping forward :/

Oops, didn't realize you made this more generic. We should come up with a non-whitelist solution for "chromeWhitelist" (http://hg.mozilla.org/mozilla-central/annotate/d8d8fa98ee7d/browser/base/content/browser.js#l6421).

(In reply to :Gavin Sharp (email gavin@gavinsharp.com) from comment #5) > Oops, didn't realize you made this more generic. We should come up with a > non-whitelist solution for "chromeWhitelist" > (http://hg.mozilla.org/mozilla-central/annotate/d8d8fa98ee7d/browser/base/ > content/browser.js#l6421). Maybe a regex ?

A regex that matches what? The difficulty is that there are some pages that should be included (all the built-in Firefox ones that users are likely to encounter) and some that we felt shouldn't (pages added by add-ons, internal pages that aren't meant to be exposed, etc.), and there are no easy ways to distinguish them. A whitelist gets out of date, a blacklist wouldn't exclude all add-on pages. We could perhaps add a separate nsIAboutModule flag for pages to opt in to the special identity block behavior, but that is likely to be accidentally misused by add-ons just coping nsIAboutModule implementations from Firefox. The brute force solution is to just update the whitelist periodically as we add new about: pages (e.g. bug 970382).

(In reply to :Gavin Sharp (email gavin@gavinsharp.com) from comment #7) > A regex that matches what? > > The difficulty is that there are some pages that should be included (all the > built-in Firefox ones that users are likely to encounter) and some that we > felt shouldn't (pages added by add-ons, internal pages that aren't meant to > be exposed, etc.), and there are no easy ways to distinguish them. > > A whitelist gets out of date, a blacklist wouldn't exclude all add-on pages. > We could perhaps add a separate nsIAboutModule flag for pages to opt in to > the special identity block behavior, but that is likely to be accidentally > misused by add-ons just coping nsIAboutModule implementations from Firefox. > > The brute force solution is to just update the whitelist periodically as we > add new about: pages (e.g. bug 970382). For the add-on problem, Firefox could force the addons to use a new add-on:// or extension:// scheme. For the internal pages, maybe Firefox could use a new about-internal:// scheme or change to the current chrome:// scheme. Then a regex that would check for pages beginning with about: would be the solution.

It's hard, but I see no better choice.

this is probably feasible now that add-ons are out of the way.