SUMO community discussions

[Attn: Everybody] Advanced configuration in the forum and KB

  • 34 Replies
  • Last reply by AliceWyman
  1. Kiki
    Kiki 1668 posts Mozilla Staff
    more options

    Hi everybody,

    In regard to the advanced customization topic (including about:config and UserChrome.css) that we’ve been discussing lately, I’d like to give you an update that we’re still looking into discussing potential re-alignment with the Firefox team for how we will be approaching this customization in SUMO as a long-term strategy.

    Here’s our recommendation in the meantime:

    Forum Try to avoid suggesting any userchrome.css solution unless first brought up by the user. In case there’s no other solution than the userchrome.css trick, please use the following common response to remind users of the risk of this action:

    Forum Response - userChrome.css warning (based on forum response created by Chris Ilias).

    On the other hand, about:config pref suggestions are ok as long as it has been used in the KB before or if there’s no alternative way to change the setting from the Preference menu. In addition, please keep in mind to also remind users to always proceed with caution by using the following common response:

    Forum Response - about:config warning.

    Note: Both common responses are still pending for approval. Feel free to review and send revisions as you see fit. Otherwise, I'll approve the current version by 21 Sept.

    KB No userchrome.css customization is allowed in the Knowledge Base. We may allow about:config customization only with recommendations/supervision from the product team (e.g. Disable or re-enable Pocket for Firefox).

    Here are some references about advanced customization in the KB:

    I hope this will clear some confusion that you might have. Let me know if you have any additional questions about this.

    On behalf of the Customer Experience Team, Kiki

    Hi everybody, In regard to the advanced customization topic (including about:config and UserChrome.css) that we’ve been discussing lately, I’d like to give you an update that we’re still looking into discussing potential re-alignment with the Firefox team for how we will be approaching this customization in SUMO as a long-term strategy. Here’s our recommendation in the meantime: '''Forum''' Try to avoid suggesting any userchrome.css solution unless first brought up by the user. In case there’s no other solution than the userchrome.css trick, please use the following common response to remind users of the risk of this action: [[Forum Response - userChrome.css warning]] (based on forum response created by [/user/Chris_Ilias Chris Ilias]). On the other hand, about:config pref suggestions are ok as long as it has been used in the KB before or if there’s no alternative way to change the setting from the Preference menu. In addition, please keep in mind to also remind users to always proceed with caution by using the following common response: [https://support.mozilla.org/en-US/kb/forum-response-aboutconfig-warning Forum Response - about:config warning]. ''Note: Both common responses are still pending for approval. Feel free to review and send revisions as you see fit. Otherwise, I'll approve the current version by 21 Sept.'' '''KB''' No userchrome.css customization is allowed in the Knowledge Base. We may allow about:config customization only with recommendations/supervision from the product team (e.g. [[Disable or re-enable Pocket for Firefox]]). Here are some references about advanced customization in the KB: * [[Configuration Editor for Firefox]] * [[Firefox advanced customization with CSS]] I hope this will clear some confusion that you might have. Let me know if you have any additional questions about this. On behalf of the Customer Experience Team, Kiki

    Modified by Kiki on

  2. Paul
    Paul 1289 posts
    more options

    Thank you for that.

    So if a user comes to the SUMO forum and says that they do not like a particular feature or design element of Firefox, do we recommend/help with a userChrome.css solution or not?

    Or (if the contributor wishes to) try to help them, but must include Chris's really good wording?

    I am just aware that helping people with this in these situations creates a population of users that may face future unhappiness when userChrome.css is reset to default in the future.

    Thank you for that. So if a user comes to the SUMO forum and says that they do not like a particular feature or design element of Firefox, do we recommend/help with a userChrome.css solution or not? Or (if the contributor wishes to) try to help them, but must include Chris's really good wording? I am just aware that helping people with this in these situations creates a population of users that may face future unhappiness when userChrome.css is reset to default in the future.
  3. Chris Ilias
    Chris Ilias 2448 posts
    more options

    Kiki said

    KB No userchrome.css customization is allowed in the Knowledge Base. We may allow about:config customization only with recommendations/supervision from the product team (e.g. Compact mode workaround in Firefox).

    As I understand it, the difference between this policy and the previous one is that troubleshooting articles are no longer allowed to point users to about:config. Is that intentional?

    Here are some references about advanced customization in the KB:

    I would remove both of those articles. They are advertisements, not warnings.

    ''Kiki [[#post-81993|said]]'' <blockquote> '''KB''' No userchrome.css customization is allowed in the Knowledge Base. We may allow about:config customization only with recommendations/supervision from the product team (e.g. [[Compact mode workaround in Firefox]]). </blockquote> As I understand it, the difference between this policy and the previous one is that troubleshooting articles are no longer allowed to point users to about:config. Is that intentional? <blockquote> Here are some references about advanced customization in the KB: * [[Configuration Editor for Firefox]] * [[Firefox advanced customization with CSS]] </blockquote> I would remove both of those articles. They are advertisements, not warnings.
  4. Kiki
    Kiki 1668 posts Mozilla Staff
    more options

    Seburo said

    Thank you for that. So if a user comes to the SUMO forum and says that they do not like a particular feature or design element of Firefox, do we recommend/help with a userChrome.css solution or not? Or (if the contributor wishes to) try to help them, but must include Chris's really good wording? I am just aware that helping people with this in these situations creates a population of users that may face future unhappiness when userChrome.css is reset to default in the future.

    At this point, whatever we say about the forum is only recommendation. At the end, it's up to the contributor to propose userChrome solution or not. However, if they decide to go down that path, they should at least remind the user of the risk of doing that (hence, the common response). This has always been the case all this time, so we leave it as it is until we have further alignment with the product team.

    Basically, our strategy at the moment is to increase education about these advanced customization. This may change in the future, whether we ban them completely, or embrace it in our platform, which still need to be decided.

    ''Seburo [[#post-81995|said]]'' <blockquote> Thank you for that. So if a user comes to the SUMO forum and says that they do not like a particular feature or design element of Firefox, do we recommend/help with a userChrome.css solution or not? Or (if the contributor wishes to) try to help them, but must include Chris's really good wording? I am just aware that helping people with this in these situations creates a population of users that may face future unhappiness when userChrome.css is reset to default in the future. </blockquote> At this point, whatever we say about the forum is only recommendation. At the end, it's up to the contributor to propose userChrome solution or not. However, if they decide to go down that path, they should at least remind the user of the risk of doing that (hence, the common response). This has always been the case all this time, so we leave it as it is until we have further alignment with the product team. Basically, our strategy at the moment is to increase education about these advanced customization. This may change in the future, whether we ban them completely, or embrace it in our platform, which still need to be decided.
  5. Kiki
    Kiki 1668 posts Mozilla Staff
    more options

    Chris Ilias said

    As I understand it, the difference between this policy and the previous one is that troubleshooting articles are no longer allowed to point users to about:config. Is that intentional?

    About:config is still allowed in the KB as long as the mandate is coming from the product team or when the usage has been approved by someone from the product team.

    I would remove both of those articles. They are advertisements, not warnings.

    The purpose of having both articles is to educate Firefox users of the risk of these advanced customization. I'm curious to understand which part of the article that make it sounds like endorsement. Care to elaborate?

    ''Chris Ilias [[#post-81997|said]]'' <blockquote> As I understand it, the difference between this policy and the previous one is that troubleshooting articles are no longer allowed to point users to about:config. Is that intentional? </blockquote> About:config is still allowed in the KB as long as the mandate is coming from the product team or when the usage has been approved by someone from the product team. <blockquote> I would remove both of those articles. They are advertisements, not warnings. </blockquote> The purpose of having both articles is to educate Firefox users of the risk of these advanced customization. I'm curious to understand which part of the article that make it sounds like endorsement. Care to elaborate?
  6. Chris Ilias
    Chris Ilias 2448 posts
    more options

    Kiki said

    About:config is still allowed in the KB as long as the mandate is coming from the product team or when the usage has been approved by someone from the product team.

    I guess your answer is yes. We'll need to do an inventory of all troubleshooting articles and what content needs to be removed.

    The purpose of having both articles is to educate Firefox users of the risk of these advanced customization. I'm curious to understand which part of the article that make it sounds like endorsement. Care to elaborate?

    Configuration Editor for Firefox: With the exception of a 2 sentence warning, that article is about how to use about:config. It's 95% tutorial (based on word-count). This article is usually used as an argument in favour of pointing users to about:config - If we're not supposed to use it, why is there a tutorial for it on the official website?

    Firefox Advanced Customization with CSS: The problem is both in sections of content and the phrasing. "What does userChrome.css do?" is advertising what you can do with the file. "Where can I get help with custom rules and userChrome.css?" is further encouraging the user to try it out, especially when you link to (i.e. endorse) places to find scripts. "How to revert Firefox back to its default state?" is saying Don't worry, there are no consequences.

    By the way, how are users going to arrive at these articles? Do you expect them to find them via search?

    ''Kiki [[#post-82002|said]]'' <blockquote> About:config is still allowed in the KB as long as the mandate is coming from the product team or when the usage has been approved by someone from the product team. </blockquote> I guess your answer is yes. We'll need to do an inventory of all troubleshooting articles and what content needs to be removed. <blockquote> The purpose of having both articles is to educate Firefox users of the risk of these advanced customization. I'm curious to understand which part of the article that make it sounds like endorsement. Care to elaborate? </blockquote> [[Configuration Editor for Firefox]]: With the exception of a 2 sentence warning, that article is about how to use about:config. It's 95% tutorial (based on word-count). This article is usually used as an argument ''in favour'' of pointing users to about:config - ''If we're not supposed to use it, why is there a tutorial for it on the official website?'' [[Firefox Advanced Customization with CSS]]: The problem is both in sections of content and the phrasing. "What does userChrome.css do?" is advertising what you can do with the file. "Where can I get help with custom rules and userChrome.css?" is further encouraging the user to try it out, especially when you link to (i.e. endorse) places to find scripts. "How to revert Firefox back to its default state?" is saying ''Don't worry, there are no consequences''. By the way, how are users going to arrive at these articles? Do you expect them to find them via search?
  7. AliceWyman
    AliceWyman 6313 posts
    more options

    Kiki said

    The purpose of having both articles is to educate Firefox users of the risk of these advanced customization.

    The original purpose of the Configuration Editor for Firefox article was to provide official documentation for users who wanted more information, rather than leaving it up to mozillaZine or other third-party sources to explain about:config, as mentioned here: https://support.mozilla.org/forums/knowledge-base-articles/710892 Proposal for Firefox about:config article ...

    Kiki, you might want to ask Mike Kaply if the article is useful as a Firefox for Enterprise article. If admin decides that this article is no longer wanted then it should be archived or edited to remove unwanted content, not deleted. We don't remove articles by deleting them, since we want to preserve links. Another possible option, if someone wants to take it on, is to move the content to a Mozilla Wiki Firefox page and redirect this article there.

    I think the content is useful for contributors, though, who are helping users when about:config preference modification is the right solution (see Firefox Support troubleshooting guide under Using about:config). It could be moved to the "How to Contribute" or "Administration" category, if you want to make it harder for users to find on their own.

    In any case, I edited the article Description to make it an Advanced Firefox topic.

    ''Kiki [[#post-82002|said]]'' <blockquote> The purpose of having both articles is to educate Firefox users of the risk of these advanced customization. </blockquote> The original purpose of the [[Configuration Editor for Firefox]] article was to provide official documentation for users who wanted more information, rather than leaving it up to mozillaZine or other third-party sources to explain about:config, as mentioned here: https://support.mozilla.org/forums/knowledge-base-articles/710892 Proposal for Firefox about:config article ... Kiki, you might want to ask Mike Kaply if the article is useful as a Firefox for Enterprise article. If admin decides that this article is no longer wanted then it should be archived or edited to remove unwanted content, not deleted. We don't remove articles by deleting them, since we want to preserve links. Another possible option, if someone wants to take it on, is to move the content to a [https://wiki.mozilla.org/Firefox Mozilla Wiki Firefox page] and redirect this article there. I think the content is useful for contributors, though, who are helping users when about:config preference modification is the right solution (see [[Firefox Support troubleshooting guide#w_using-aboutconfig|Firefox Support troubleshooting guide]] under Using about:config). It could be moved to the "How to Contribute" or "Administration" category, if you want to make it harder for users to find on their own. In any case, I edited the article Description to make it an [https://support.mozilla.org/en-US/products/firefox/advanced-and-experimental-features Advanced] Firefox topic.

    Modified by AliceWyman on

  8. cor-el
    cor-el 1494 posts
    more options

    I'm not really confident about the trustworthy in "if you are following trustworthy advice" wording on about:config. How would someone that doesn't know anything about the purpose of changing a pref know whether to trust the advice to change this pref or better not ?

    On internet that are a lot of articles that propose changing prefs to 'improve' or tweak Firefox that I would never write in a reply as I always check the source code to see what a pref is about and whether I think that it is worth the risk (i.e. changing the pref is very low risk and is sometimes suggested on Bugzilla as a workaround). Because of this I don't have suggested very often to modify browser.proton prefs because you could predict that issues would arise later. If another (trusted) contributor would propose modifying such a pref after reading about it on internet then I notice that users trust this advice and are more happy with changing prefs as this is easy done via about:config than with using userChrome.css that requires more effort, while making changes in about:config is usually more dangerous then code in userChrome.css (you already get a warning when you open about:config). You can know that when something is wrong with your CSS code, you have to look look for an update (or disable your userChrome.css) while hunting down about:config to figure what prefs have been changed is quite a challenge.

    Maybe Mozilla can consider to add to about:support whether userChrome.css and userContent.css are present, similar to user.js as that makes it easier to spot issues. It might also be a good idea to add buttons to inspect these files. I've been using these CSS files from the very start of Firefox and at that time it was quite hard to get the correct rules using the DOM Inspector. These days the devtools (Browser Toolbox) are so advanced that it so is much easier and sometimes only takes a few minutes or less to check rules and verify this via a source code lookup and check this out myself.

    There are two options, either we try to help them here at SUMO or we send them to a forum like Reddit. Since they are already here I always try to help them as much as possible to my knowledge and check out how they respond to suggestions to see whether they are confident and experienced enough to handle this.

    I know that there is a lot of good and bad about using userChrome.css, but there are lots of reports from users that aren't pleased with the changes that come with every new Firefox version and it doesn't feel good if we aren't allowed to help them because it isn't supported officially.

    EDIT: Here is an interesting example of a user who ended up on the Wiki firefox_about_config_privacy_tweeks page (that page could use a warning or be removed) and decided to apply all the proposed privacy tweaks and noticed that enabling RFP was causing 'zoom' issues.

    I'm not really confident about the ''trustworthy'' in "if you are following trustworthy advice" wording on about:config. How would someone that doesn't know anything about the purpose of changing a pref know whether to trust the advice to change this pref or better not ? On internet that are a lot of articles that propose changing prefs to 'improve' or tweak Firefox that I would never write in a reply as I always check the source code to see what a pref is about and whether I think that it is worth the risk (i.e. changing the pref is very low risk and is sometimes suggested on Bugzilla as a workaround). Because of this I don't have suggested very often to modify browser.proton prefs because you could predict that issues would arise later. If another (trusted) contributor would propose modifying such a pref after reading about it on internet then I notice that users trust this advice and are more happy with changing prefs as this is easy done via about:config than with using userChrome.css that requires more effort, while making changes in about:config is usually more dangerous then code in userChrome.css (you already get a warning when you open about:config). You can know that when something is wrong with your CSS code, you have to look look for an update (or disable your userChrome.css) while hunting down about:config to figure what prefs have been changed is quite a challenge. Maybe Mozilla can consider to add to about:support whether userChrome.css and userContent.css are present, similar to user.js as that makes it easier to spot issues. It might also be a good idea to add buttons to inspect these files. I've been using these CSS files from the very start of Firefox and at that time it was quite hard to get the correct rules using the DOM Inspector. These days the devtools (Browser Toolbox) are so advanced that it so is much easier and sometimes only takes a few minutes or less to check rules and verify this via a source code lookup and check this out myself. There are two options, either we try to help them here at SUMO or we send them to a forum like Reddit. Since they are already here I always try to help them as much as possible to my knowledge and check out how they respond to suggestions to see whether they are confident and experienced enough to handle this. I know that there is a lot of good and bad about using userChrome.css, but there are lots of reports from users that aren't pleased with the changes that come with every new Firefox version and it doesn't feel good if we aren't allowed to help them because it isn't supported officially. EDIT: Here is an interesting example of a user who ended up on the Wiki firefox_about_config_privacy_tweeks page (that page could use a warning or be removed) and decided to apply all the proposed privacy tweaks and noticed that enabling RFP was causing 'zoom' issues. *https://wiki.mozilla.org/Privacy/Privacy_Task_Force/firefox_about_config_privacy_tweeks *[/questions/1351033] how to set zoom level for individual pages (automatically)

    Modified by cor-el on

  9. cor-el
    cor-el 1494 posts
    more options

    Shouldn't this be extended to suggesting to use policies.json (or GPO) to disable features to a normal (single) user and not for deploying Firefox in an enterprise environment to multiple users?

    In some cases users do not want to update to newer Firefox versions because they dislike the changes and want to stay with an older release and then get the advice to use a policy. It might be possible to help them understand the changes and possibly offer a (userChrome.css) workaround instead of letting them vulnerable with an outdated Firefox version.

    Shouldn't this be extended to suggesting to use policies.json (or GPO) to disable features to a normal (single) user and not for deploying Firefox in an enterprise environment to multiple users? In some cases users do not want to update to newer Firefox versions because they dislike the changes and want to stay with an older release and then get the advice to use a policy. It might be possible to help them understand the changes and possibly offer a (userChrome.css) workaround instead of letting them vulnerable with an outdated Firefox version.
  10. Paul
    Paul 1289 posts
    more options

    The guidance seems to be that approach should not be offered.

    The danger with userChrome.css from a user happiness perspective is that sure, we might be solving the immediate concern, but as we have seen recently, it can break again (repeatedly), leading to more unhappiness for the user.

    The guidance seems to be that approach should not be offered. The danger with userChrome.css from a user happiness perspective is that sure, we might be solving the immediate concern, but as we have seen recently, it can break again (repeatedly), leading to more unhappiness for the user.
  11. Chris Ilias
    Chris Ilias 2448 posts
    more options

    I've created a list of articles that point users to about:config - https://docs.google.com/spreadsheets/d/1aMJVXWbHJ_VOihIgXqKqU7EX73OiYRvWi5qivuciMsM/edit#gid=1450465304

    Which instances are sanctioned by the product team?

    I've created a list of articles that point users to about:config - https://docs.google.com/spreadsheets/d/1aMJVXWbHJ_VOihIgXqKqU7EX73OiYRvWi5qivuciMsM/edit#gid=1450465304 Which instances are sanctioned by the product team?
  12. Chris Ilias
    Chris Ilias 2448 posts
    more options

    Also, if there are any articles I missed, let me know.

    Also, if there are any articles I missed, let me know.
  13. AliceWyman
    AliceWyman 6313 posts
    more options

    Chris Ilias said

    Also, if there are any articles I missed, let me know.

    I don't know if you intentionally left it out because it's not a user-facing article but, you missed the "How to contribute" Firefox Support troubleshooting guide (see the Using about:config section). P.S. The same goes for the "How to contribute" Answering questions on the Support Forum article (see the Posting replies section).

    ''Chris Ilias [[#post-82028|said]]'' <blockquote> Also, if there are any articles I missed, let me know. </blockquote> I don't know if you intentionally left it out because it's not a user-facing article but, you missed the "How to contribute" [[Firefox Support troubleshooting guide]] (see the ''Using about:config'' section). P.S. The same goes for the "How to contribute" [[Answering questions on the Support Forum]] article (see the ''Posting replies'' section).

    Modified by AliceWyman on

  14. Kiki
    Kiki 1668 posts Mozilla Staff
    more options

    Chris Ilias said

    Configuration Editor for Firefox: With the exception of a 2 sentence warning, that article is about how to use about:config. It's 95% tutorial (based on word-count). This article is usually used as an argument in favour of pointing users to about:config - If we're not supposed to use it, why is there a tutorial for it on the official website? Firefox Advanced Customization with CSS: The problem is both in sections of content and the phrasing. "What does userChrome.css do?" is advertising what you can do with the file. "Where can I get help with custom rules and userChrome.css?" is further encouraging the user to try it out, especially when you link to (i.e. endorse) places to find scripts. "How to revert Firefox back to its default state?" is saying Don't worry, there are no consequences. By the way, how are users going to arrive at these articles? Do you expect them to find them via search?

    I see.. Point taken. I'll discuss it with Fabi and the new content lead to see how we can improve those articles. For your last question, search is definitely one of them. In general, I hope that people who are looking for advanced customization can discover these articles first before they proceed.

    Also, thank you for starting the sheet. I requested edit access, can you grant it?

    ''Chris Ilias [[#post-82010|said]]'' <blockquote> [[Configuration Editor for Firefox]]: With the exception of a 2 sentence warning, that article is about how to use about:config. It's 95% tutorial (based on word-count). This article is usually used as an argument ''in favour'' of pointing users to about:config - ''If we're not supposed to use it, why is there a tutorial for it on the official website?'' [[Firefox Advanced Customization with CSS]]: The problem is both in sections of content and the phrasing. "What does userChrome.css do?" is advertising what you can do with the file. "Where can I get help with custom rules and userChrome.css?" is further encouraging the user to try it out, especially when you link to (i.e. endorse) places to find scripts. "How to revert Firefox back to its default state?" is saying ''Don't worry, there are no consequences''. By the way, how are users going to arrive at these articles? Do you expect them to find them via search? </blockquote> I see.. Point taken. I'll discuss it with Fabi and the new content lead to see how we can improve those articles. For your last question, search is definitely one of them. In general, I hope that people who are looking for advanced customization can discover these articles first before they proceed. Also, thank you for starting the [https://docs.google.com/spreadsheets/d/1aMJVXWbHJ_VOihIgXqKqU7EX73OiYRvWi5qivuciMsM/edit sheet]. I requested edit access, can you grant it?
  15. Kiki
    Kiki 1668 posts Mozilla Staff
    more options

    AliceWyman said

    The original purpose of the Configuration Editor for Firefox article was to provide official documentation for users who wanted more information, rather than leaving it up to mozillaZine or other third-party sources to explain about:config, as mentioned here: https://support.mozilla.org/forums/knowledge-base-articles/710892 Proposal for Firefox about:config article ... Kiki, you might want to ask Mike Kaply if the article is useful as a Firefox for Enterprise article. If admin decides that this article is no longer wanted then it should be archived or edited to remove unwanted content, not deleted. We don't remove articles by deleting them, since we want to preserve links. Another possible option, if someone wants to take it on, is to move the content to a Mozilla Wiki Firefox page and redirect this article there. I think the content is useful for contributors, though, who are helping users when about:config preference modification is the right solution (see Firefox Support troubleshooting guide under Using about:config). It could be moved to the "How to Contribute" or "Administration" category, if you want to make it harder for users to find on their own. In any case, I edited the article Description to make it an Advanced Firefox topic.

    Alice, that's an interesting idea to focus the content for contributors instead of end-users. I'll make a note on this for now. Also, thank you for moving the category for about:config article. I moved the userChrome one as well.

    ''AliceWyman [[#post-82012|said]]'' <blockquote> The original purpose of the [[Configuration Editor for Firefox]] article was to provide official documentation for users who wanted more information, rather than leaving it up to mozillaZine or other third-party sources to explain about:config, as mentioned here: https://support.mozilla.org/forums/knowledge-base-articles/710892 Proposal for Firefox about:config article ... Kiki, you might want to ask Mike Kaply if the article is useful as a Firefox for Enterprise article. If admin decides that this article is no longer wanted then it should be archived or edited to remove unwanted content, not deleted. We don't remove articles by deleting them, since we want to preserve links. Another possible option, if someone wants to take it on, is to move the content to a [https://wiki.mozilla.org/Firefox Mozilla Wiki Firefox page] and redirect this article there. I think the content is useful for contributors, though, who are helping users when about:config preference modification is the right solution (see [[Firefox Support troubleshooting guide#w_using-aboutconfig|Firefox Support troubleshooting guide]] under Using about:config). It could be moved to the "How to Contribute" or "Administration" category, if you want to make it harder for users to find on their own. In any case, I edited the article Description to make it an [https://support.mozilla.org/en-US/products/firefox/advanced-and-experimental-features Advanced] Firefox topic. </blockquote> Alice, that's an interesting idea to focus the content for contributors instead of end-users. I'll make a note on this for now. Also, thank you for moving the category for about:config article. I moved the userChrome one as well.
  16. Kiki
    Kiki 1668 posts Mozilla Staff
    more options

    cor-el said

    I'm not really confident about the trustworthy in "if you are following trustworthy advice" wording on about:config. How would someone that doesn't know anything about the purpose of changing a pref know whether to trust the advice to change this pref or better not ? On internet that are a lot of articles that propose changing prefs to 'improve' or tweak Firefox that I would never write in a reply as I always check the source code to see what a pref is about and whether I think that it is worth the risk (i.e. changing the pref is very low risk and is sometimes suggested on Bugzilla as a workaround). Because of this I don't have suggested very often to modify browser.proton prefs because you could predict that issues would arise later. If another (trusted) contributor would propose modifying such a pref after reading about it on internet then I notice that users trust this advice and are more happy with changing prefs as this is easy done via about:config than with using userChrome.css that requires more effort, while making changes in about:config is usually more dangerous then code in userChrome.css (you already get a warning when you open about:config). You can know that when something is wrong with your CSS code, you have to look look for an update (or disable your userChrome.css) while hunting down about:config to figure what prefs have been changed is quite a challenge.

    Valid point. I think we all have different interpretation of "trusted source" and that's what make the line sounds meaningless in the end. I agree that we might need to reconsider this part.

    Maybe Mozilla can consider to add to about:support whether userChrome.css and userContent.css are present, similar to user.js as that makes it easier to spot issues. It might also be a good idea to add buttons to inspect these files. I've been using these CSS files from the very start of Firefox and at that time it was quite hard to get the correct rules using the DOM Inspector. These days the devtools (Browser Toolbox) are so advanced that it so is much easier and sometimes only takes a few minutes or less to check rules and verify this via a source code lookup and check this out myself.

    Interesting! I think this will be really useful for those who use customization trick without understand the consequence. So it'll be easier for contributor to walk them through the solution.

    There are two options, either we try to help them here at SUMO or we send them to a forum like Reddit. Since they are already here I always try to help them as much as possible to my knowledge and check out how they respond to suggestions to see whether they are confident and experienced enough to handle this.

    Exactly. But as an official support platform, in the end, we should align with the direction of the product.

    I know that there is a lot of good and bad about using userChrome.css, but there are lots of reports from users that aren't pleased with the changes that come with every new Firefox version and it doesn't feel good if we aren't allowed to help them because it isn't supported officially.

    This point is probably not something that the product team understand when they make the call about these advanced customization at the beginning. That's why after all these years, I think we need to sit together with the product team once again to revisit this topic.

    ''cor-el [[#post-82013|said]]'' <blockquote> I'm not really confident about the ''trustworthy'' in "if you are following trustworthy advice" wording on about:config. How would someone that doesn't know anything about the purpose of changing a pref know whether to trust the advice to change this pref or better not ? On internet that are a lot of articles that propose changing prefs to 'improve' or tweak Firefox that I would never write in a reply as I always check the source code to see what a pref is about and whether I think that it is worth the risk (i.e. changing the pref is very low risk and is sometimes suggested on Bugzilla as a workaround). Because of this I don't have suggested very often to modify browser.proton prefs because you could predict that issues would arise later. If another (trusted) contributor would propose modifying such a pref after reading about it on internet then I notice that users trust this advice and are more happy with changing prefs as this is easy done via about:config than with using userChrome.css that requires more effort, while making changes in about:config is usually more dangerous then code in userChrome.css (you already get a warning when you open about:config). You can know that when something is wrong with your CSS code, you have to look look for an update (or disable your userChrome.css) while hunting down about:config to figure what prefs have been changed is quite a challenge. </blockquote> Valid point. I think we all have different interpretation of "trusted source" and that's what make the line sounds meaningless in the end. I agree that we might need to reconsider this part. <blockquote> Maybe Mozilla can consider to add to about:support whether userChrome.css and userContent.css are present, similar to user.js as that makes it easier to spot issues. It might also be a good idea to add buttons to inspect these files. I've been using these CSS files from the very start of Firefox and at that time it was quite hard to get the correct rules using the DOM Inspector. These days the devtools (Browser Toolbox) are so advanced that it so is much easier and sometimes only takes a few minutes or less to check rules and verify this via a source code lookup and check this out myself. </blockquote> Interesting! I think this will be really useful for those who use customization trick without understand the consequence. So it'll be easier for contributor to walk them through the solution. <blockquote> There are two options, either we try to help them here at SUMO or we send them to a forum like Reddit. Since they are already here I always try to help them as much as possible to my knowledge and check out how they respond to suggestions to see whether they are confident and experienced enough to handle this. </blockquote> Exactly. But as an official support platform, in the end, we should align with the direction of the product. <blockquote> I know that there is a lot of good and bad about using userChrome.css, but there are lots of reports from users that aren't pleased with the changes that come with every new Firefox version and it doesn't feel good if we aren't allowed to help them because it isn't supported officially. </blockquote> This point is probably not something that the product team understand when they make the call about these advanced customization at the beginning. That's why after all these years, I think we need to sit together with the product team once again to revisit this topic.
  17. Danny Colin
    Danny Colin 34 posts
    more options
    I know that there is a lot of good and bad about using userChrome.css, but there are lots of reports from users that aren't pleased with the changes that come with every new Firefox version and it doesn't feel good if we aren't allowed to help them because it isn't supported officially.

    I'd argue that there's nothing good about using userChrome.css for most of our end-users. They rely on third-party scripts that will eventually break. If it was just for me, I'd prohibit helping people with userChrome.css question on the official forum. However, I'm totally fine redirecting them to other resources like r/FirefoxCSS and I don't think we should bother with the level of trustworthiness of the source that much as long as we put a disclaimer that explicitly say that we don't officially endorse any of those sources.

    <blockquote> I know that there is a lot of good and bad about using userChrome.css, but there are lots of reports from users that aren't pleased with the changes that come with every new Firefox version and it doesn't feel good if we aren't allowed to help them because it isn't supported officially. </blockquote> I'd argue that there's nothing good about using userChrome.css for most of our end-users. They rely on third-party scripts that will eventually break. If it was just for me, I'd prohibit helping people with userChrome.css question on the official forum. However, I'm totally fine redirecting them to other resources like r/FirefoxCSS and I don't think we should bother with the level of trustworthiness of the source that much as long as we put a disclaimer that explicitly say that we don't officially endorse any of those sources.

    Modified by Danny Colin on

  18. Chris Ilias
    Chris Ilias 2448 posts
    more options

    None of the instances I listed were sanctioned by the product team?

    None of the instances I listed were sanctioned by the product team?
  19. Kiki
    Kiki 1668 posts Mozilla Staff
    more options

    @Chris I know that some of them were based on product team's recommendation. But we have to do a proper review to make sure. Thanks for starting the list. I think it'll be really helpful for us to do the checking.

    @Chris I know that some of them were based on product team's recommendation. But we have to do a proper review to make sure. Thanks for starting the list. I think it'll be really helpful for us to do the checking.
  20. Kiki
    Kiki 1668 posts Mozilla Staff
    more options

    Hi everybody,

    I'd like to thank everyone who gave with their feedback about this topic in this thread. We want you to know that we take your feedback seriously and therefore, we're able to make the following progress on this topic:

    1. We created a new KB article explaining Firefox advanced customization in general. We're hoping to use this article as a reference to help end-users understand the risk of these advanced customization.
    2. We also added a new contributor guide to learn more about CSS configuration in more detail. We changed the focus of the initial draft to contributors instead of end-users, following feedback from this thread. If you need reference for end users, please use the Firefox Advanced Customization and Configuration Options instead.
    3. New common responses were created for about:config and css customization. Forum contributors and moderators can now add these warning easily into their reply. Although this is not mandatory, we highly recommend adding the warning on a reply that contains these customizations options.

    Next, we'd like to audit the list that Chris Ilias has created to collect KB articles that recommend about:config changes to make sure that they're safe.

    We're hoping that this will help mitigate some of the issues in the meantime, while we look into a long-term strategy for this matter.

    Thanks once again for all of you, and please let us know if you have further feedback about these changes.

    Keep rocking the helpful web, Kiki

    Hi everybody, I'd like to thank everyone who gave with their feedback about this topic in this thread. We want you to know that we take your feedback seriously and therefore, we're able to make the following progress on this topic: # We created [https://support.mozilla.org/kb/firefox-advanced-customization-and-configuration a new KB article] explaining Firefox advanced customization in general. We're hoping to use this article as a reference to help end-users understand the risk of these advanced customization. # We also added [https://support.mozilla.org/kb/contributors-guide-firefox-advanced-customization a new contributor guide] to learn more about CSS configuration in more detail. We changed the focus of the initial draft to contributors instead of end-users, following feedback from this thread. If you need reference for end users, please use the [[Firefox Advanced Customization and Configuration Options]] instead. # New common responses were created for [https://support.mozilla.org/en-US/kb/forum-response-aboutconfig-warning about:config] and [https://support.mozilla.org/kb/forum-response-userchromecss-warning css customization]. Forum contributors and moderators can now add these warning easily into their reply. Although this is not mandatory, we highly recommend adding the warning on a reply that contains these customizations options. Next, we'd like to audit [https://docs.google.com/spreadsheets/d/1aMJVXWbHJ_VOihIgXqKqU7EX73OiYRvWi5qivuciMsM/edit#gid=1450465304 the list] that [/user/Chris_Ilias Chris Ilias] has created to collect KB articles that recommend about:config changes to make sure that they're safe. We're hoping that this will help mitigate some of the issues in the meantime, while we look into a long-term strategy for this matter. Thanks once again for all of you, and please let us know if you have further feedback about these changes. Keep rocking the helpful web, Kiki

    Modified by Kiki on

  1. 1
  2. 2