Third-party themes cannot give about:support an original design. http://hg.mozilla.org/mozilla-central/annotate/dd3b6bdeb0f7/browser/base/content/aboutSupport.xhtml#l53 chrome://browser/skin/aboutSupport.css or chrome://global/skin/aboutSupport.css is made. And, it is necessary to write the style in that.

And, I hope to use xul:button for the "Copy all to clipboard" button if it is possible.

Any news on this?

Neither first making chrome://browser/skin/aboutSupport.css nor moving CSS style rules in aboutSupport.xhtml from aboutSupport.xhtml to aboutSupport.css has no risk. And, this change is easy and high return. This merely changes location. Now, there is no method of the third party theme's giving about:support the CSS style rules. Firefox users might look very strange this. Because about:crashes also uses button (not xul:button), the button issue is made another bug.

On top of the patch in bug 518607. Just copy-pasted out, other than adding license blocks and removing trailing whitespace.

Why should a Troubleshooting Information page have an original design? Making sure this as accessible as possible seems more important to me. After all, a theme could be the reason for opening that page in the first place. It's a bit like complaining about themes being unable to skin Safe Mode.

Not really, no. Safe Mode is explicitly about getting out from under your broken themes and extensions, while if about:support is supposed to have anything to do with themes it's doing a pretty crappy job of it, providing absolutely no information about them while using OS theme colors instead of hard-coding colors that will be readable even if you are using a broken OS theme. If it's supposed to be readable no matter what, then it ought to look just like it would to someone after the advice I'd give if they said that with their theme about:support was just solid black: View - Page Style - No Style. I'd say it's more like the About dialog, where nobody has ever really been able to successfully explain *why* we've chosen not to allow theming, only that we have, and that it should be more like the troubleshooting page about:plugins, where even though we've chosen not to do anything to make it fit, we still make it possible for third-party themes to make it look less alien.

(In reply to comment #5) Extensions can change Troubleshooting Information page. If the change is not permitted, Troubleshooting Information should open the Web page like Plugin Check. However, the Web page might also change Greasemonkey and Jetpack Feature. Actually, third party themes are not displayed in Troubleshooting Information page. Themes doesn't become the source of troubles compared with Extensions. When I use third party theme, I cannot distinguish whether Troubleshooting Information page is correct or imitation now. Because other about:* and this are different appearances. This cannot be easily judged that Firefox gave it. People understand that themes change all appearances. Most main about:* can theming by third party themes. The security warning page is included in that. Most third party themes might change the color scheme of Troubleshooting Information page. The user can make the Page Style off. In that case, information on Troubleshooting Information page can be read. In a word, the risk doesn't change, except when Troubleshooting Information page is designed as third party themes developers has malice.

(In reply to comment #7) > Extensions can change Troubleshooting Information page. Sure, but we'd probably not encourage them to do so. > If the change is not permitted, Troubleshooting Information should open the Web > page like Plugin Check. The troubleshooting information we're talking about isn't accessible to unprivileged content, so this isn't an option. (By the way, I think it's preferable to have this page available without connectivity, but we've already given up on this in the case of the Help menu item.) > Actually, third party themes are not displayed in Troubleshooting Information > page. Maybe they should. Themes can and sometimes do break parts of the browser. > The user can make the Page Style off. In that case, information on > Troubleshooting Information page can be read. Most users don't have a clue what this is. Sounds like an unnecessary complication to me.

What are you trying to protect against?

I can't see any problem making this page skinnable at all. It seems the changes are not difficult to make, and it will have no impact, on accessibility or any other issue. Am I missing something here? Of course it is not so important, but we would really love to have this possibility. I've skinned all the about pages until now and this one looks simply bad and "out". So, please?

(In reply to comment #9) > What are you trying to protect against? First of all, I'm trying to protect against fixing what isn't broken. So, what's the point of this bug? This page doesn't contribute to the user experience in an ordinary way. It's meant to be used once in a blue moon if there's a problem with the browser. Pleasing the user means to get this job done with minimum pain. Seamless integration with a customized UI isn't really on the agenda for this page. It's seems like there's little to no gain with the admittedly small risk of making it harder to solve the user's problem. A theme could mess up the colors and cause problems with exotic OS themes, for instance. Yes, it could do this on about:neterror as well, but this exactly could be a reason for opening about:support.

(In reply to comment #11) > (In reply to comment #9) > > What are you trying to protect against? > > First of all, I'm trying to protect against fixing what isn't broken. This is a request from third-party themes authors. On the default theme it's not broken, but on third-party themes. > So, > what's the point of this bug? This page doesn't contribute to the user > experience in an ordinary way. It's meant to be used once in a blue moon if > there's a problem with the browser. Pleasing the user means to get this job > done with minimum pain. Seamless integration with a customized UI isn't really > on the agenda for this page. Like this page there are a lot of other pages that will be probably never opened from normal users. Nevertheless theme authors make efforts to style those pages as well.

(In reply to comment #12) > (In reply to comment #11) > > (In reply to comment #9) > > > What are you trying to protect against? > > > > First of all, I'm trying to protect against fixing what isn't broken. > This is a request from third-party themes authors. On the default theme it's > not broken, but on third-party themes. There's nothing default theme specific on that page.

This screenshot makes a comparison between two similar pages (about:plugins and about:support) showed with the default theme and charamel

You're confusing "default theme" with "OS theme". about:support uses native theming like any other web page may do. You need to create an OS theme if you want control over this. A Firefox theme's power is limited to the chrome, and I don't think we need to consider this page part of the chrome just because it's local.

1. Present externals confuse the user. 2. Extensions can change Troubleshooting Information page. I think that it is meaningless to prohibit only Troubleshooting Information page theming. Do we write in Troubleshooting Information page like this? "This page is protected from third-party themes. However, this page is not protected from Extensions." When this bug becomes WONTFIX, third-party themes developers will use em:type="32". And, overlay or override does aboutSupport.xhtml. I do not think this to be preferable. I think that "More secure Troubleshooting Information page" and "More better Troubleshooting Information page" are another discussions. And, I think that there is no problem, except when third-party themes developers intentionally deteriorates the display of Troubleshooting Information page. The user will not use such theme. Moreover, it can be easily confirmed by AMO review.

Extensions are not supposed to mess with this page. The fact that they can is not a convincing argument for letting themes mess with it as well. AMO reviews can't possible cover all parts of the browser, nor can they cover all edge cases like OS dependent theme issues.

(In reply to comment #17) > Extensions are not supposed to mess with this page. The fact that they can is > not a convincing argument for letting themes mess with it as well. > Hey! Why do you think that themes want to "mess up" with that page? Do you think theme authors are malicious? Or incompetents? What is your point? That themes "can maybe" mess up this page or any other part of the UI (and they can really mess up on such a way that the browser will not open at all; but extensions can also do this...) is reason to prohibit themes to be able to skin that page? What is the further consequences of your thoughts? To not permit that themes be able to skin the other "about:" pages? Or to prohibit that themes in general can modify any aspects of the browser?

(In reply to comment #18) > Do you think theme authors are malicious? Or incompetents? Well, yes, I couldn't rule that out. But that wasn't my point. Even competent people aren't immune to messing something up. > That themes "can maybe" mess up this page or any other part of the UI This isn't a random part of the UI. It's a page that support folks can point users to in order to figure out what the cause of the user's problem might be. What makes you believe that a theme couldn't be such a cause and that the problem couldn't affect this very page?

(In reply to comment #19) > This isn't a random part of the UI. It's a page that support folks can point > users to in order to figure out what the cause of the user's problem might be. The about:plugins page is also such a page and it is skinnable though. > What makes you believe that a theme couldn't be such a cause and that the > problem couldn't affect this very page? You are right, but it has nothing to do with this page being skinnable or not. I think the current used theme should also be listed in this page.

(In reply to comment #20) > > This isn't a random part of the UI. It's a page that support folks can point > > users to in order to figure out what the cause of the user's problem might be. > The about:plugins page is also such a page and it is skinnable though. Well, it's unlikely that someone would be asked to open about:plugins in order to identify a third-party theme problem. > > What makes you believe that a theme couldn't be such a cause and that the > > problem couldn't affect this very page? > You are right, but it has nothing to do with this page being skinnable or not. It is directly linked to whether that page should be skinnable.

I'm somewhat ambivalent about the themeing issue. I don't think the ability to theme this page is particularly important, but I also don't think the "theme breaks about:support" scenario is something we should really be concerned about (it seems quite unlikely to actually occur in practice, and also unlikely to matter much even if it does, given Phil's reasoning in comment 6). (Though the about dialog not being themeable is just a bug.)

Comment on attachment 432066 [details] [diff] [review] Unrotted fix v.1 >diff --git a/toolkit/content/aboutSupport.js b/toolkit/content/aboutSupport.js >+# The Initial Developer of the Original Code is >+# Mozilla Corporation nit: "Mozilla Foundation", per gerv-post Let's just go with this. I don't think this is something we should be spending much time debating. (And I apologize for taking this long to get to the request...)