VOOZH about

URL: https://support.mozilla.org/en-US/forums/contributors/713108

⇱ about:support Info to diagnose/troubleshoot user questions | SUMO community discussions | Forums | Mozilla Support

Windows 10 reached EOS (end of support) on October 14, 2025. If you are on Windows 10, see this article.

Search Support

SUMO community discussions

about:support Info to diagnose/troubleshoot user questions

  • 28 Replies
  • Last reply by cor-el

  1. The information contained in about:support is a useful resource to troubleshoot problems or spot common factors in the configuration for affected installations in case of newly emerging problems. the amount of stuff stored in there has grown over the past years, so much that it doesn't fit within the 10k character limit on replies in the support forum when we ask for it. So far pastebin.mozilla.org was a mozilla-operated alternative for asking users to submit their troubleshooting information but that will cease to exist at the end of the month. how should we deal with the problem after september? is it possible to just bump up the char limit of replies on sumo or is there another recommended 3rd-party service for sharing this kind of information...

    in addition, also the automatic submission of about:support data could do with some overhaul - here is a sample of what it contains currently once you click on more system details. there would be a number of additional useful info that we could catch that help in answering support questions:

    • Application basics now also contains sections about the number of Multiprocess Windows, Web Content Processes and Enterprise Policies
    • on new windows versions there is a Security Software section with details about the active antivirus and firewall software
    • the field "Accessibility Instantiator" would be useful to see which external software is switching on accessibility mode
    • the whole Internationalization & Localization and Sandbox sections
    The information contained in about:support is a useful resource to troubleshoot problems or spot common factors in the configuration for affected installations in case of newly emerging problems. the amount of stuff stored in there has grown over the past years, so much that it doesn't fit within the 10k character limit on replies in the support forum when we ask for it. So far pastebin.mozilla.org was a mozilla-operated alternative for asking users to submit their troubleshooting information but that will cease to exist at the end of the month. how should we deal with the problem after september? is it possible to just bump up the char limit of replies on sumo or is there another recommended 3rd-party service for sharing this kind of information... in addition, also the automatic submission of about:support data could do with some overhaul - [https://support.mozilla.org/en-US/questions/1228221 here] is a sample of what it contains currently once you click on more system details. there would be a number of additional useful info that we could catch that help in answering support questions: * Application basics now also contains sections about the number of Multiprocess Windows, Web Content Processes and Enterprise Policies * on new windows versions there is a ''Security Software'' section with details about the active antivirus and firewall software * the field "Accessibility Instantiator" would be useful to see which external software is switching on accessibility mode * the whole ''Internationalization & Localization'' and ''Sandbox'' sections

    Modified by philipp on

  2. I've brought this up with the dev resources we have. We will look at upping the character limit and making adjustments to the automatic submissions.

    I've brought this up with the dev resources we have. We will look at upping the character limit and making adjustments to the automatic submissions.

  3. Pmac filed a Github issue to discuss options here: https://github.com/mozilla/kitsune/issues/3284

    Pmac filed a Github issue to discuss options here: https://github.com/mozilla/kitsune/issues/3284
  4. more options

    If there are a download button in the "system details" page with the `about:support` data, will it work?

    If there are a download button in the "system details" page with the `about:support` data, will it work?

  5. a download button would be one way to go about it, but what technical problem would that solve?

    since only a minority of users provide their troubleshooting information at the time of writing up their question, we need to have some form of procedure in place to be able to gather about:support when the thread is already ongoing as well...

    a download button would be one way to go about it, but what technical problem would that solve? since only a minority of users provide their troubleshooting information at the time of writing up their question, we need to have some form of procedure in place to be able to gather about:support when the thread is already ongoing as well...

  6. Note that the API question data includes a more complete list of troubleshooting data, so it is merely the forum question pages that need to be adjusted to show more detail.

    It would prefer if the various setting could be collapsed in the System Details list with the collapsed state remembered since this list (especially the graphics section) can be quite large. 

    0	
graphics	{…}
lockedPreferences	{}
media	{…}
javaScript	{…}
intl	{…}
accessibility	{…}
application	{…}
sandbox	{…}
extensions	[…]
libraryVersions	{…}
modifiedPreferences	{}
securitySoftware	{…}
userJS	{…}
features	[…]
    Note that the API question data includes a more complete list of troubleshooting data, so it is merely the forum question pages that need to be adjusted to show more detail. It would prefer if the various setting could be collapsed in the System Details list with the collapsed state remembered since this list (especially the graphics section) can be quite large. *https://support.mozilla.org/api/2/question/1228221/ <pre><nowiki>0 graphics {…} lockedPreferences {} media {…} javaScript {…} intl {…} accessibility {…} application {…} sandbox {…} extensions […] libraryVersions {…} modifiedPreferences {} securitySoftware {…} userJS {…} features […]</nowiki></pre>

  7. philipp said

    So far pastebin.mozilla.org was a mozilla-operated alternative for asking users to submit their troubleshooting information but that will cease to exist at the end of the month. how should we deal with the problem after september?

    Use Etherpad! ☺

    I understand the concerns about putting more load on the DB. For a short-term replacement of pastebin.m.o, I think any pastebin web-tool should suffice, like https://pastebin.com/

    In addition, cloud drives are a lot more common these days compared to when we first set up the forum. Depending on the user, I think we can be more willing to ask users to self-host content.

    ''philipp [[#post-74426|said]]'' <blockquote> So far pastebin.mozilla.org was a mozilla-operated alternative for asking users to submit their troubleshooting information but that will cease to exist at the end of the month. how should we deal with the problem after september? </blockquote> Use Etherpad! ☺️ I understand the concerns about putting more load on the DB. For a short-term replacement of pastebin.m.o, I think any pastebin web-tool should suffice, like https://pastebin.com/ In addition, cloud drives are a lot more common these days compared to when we first set up the forum. Depending on the user, I think we can be more willing to ask users to self-host content.
  8. I've also filed [https://bugzilla.mozilla.org/show_bug.cgi?id=1483302 Bug 1483302 - Add copy to pastebin in about:support]

  9. So pastebin.mozilla.org is being decommissioned on Sept 1, 2018 and will no longer work. The wiki page suggests docs, github, and post-its on the bathroom wall in the meantimes. The bug had a few better suggestions:

    They all seem to require a bit more development. One that is built in and easy to use I might propose: what would it look like to change the common response to include Firefox Screenshots of about:support info?

    Firefox Notes in Test Pilot has a feature request to include a share link - https://github.com/mozilla/notes/issues/1163

    Are there any suggestions that you might have for a work around to update the common response - https://support.mozilla.org/en-US/kb/forum-response-get-troubleshooting-information

    So pastebin.mozilla.org is being decommissioned on Sept 1, 2018 and will no longer work. The wiki page suggests docs, github, and post-its on the bathroom wall in the meantimes. The bug had a few better suggestions: *https://dpaste.de (code: https://github.com/bartTC/dpaste docs: http://dpaste.readthedocs.io/) *Firefox Notes and Firefox Screenshots *PrivateBin: https://github.com/PrivateBin/PrivateBin They all seem to require a bit more development. One that is built in and easy to use I might propose: what would it look like to change the common response to include Firefox Screenshots of about:support info? Firefox Notes in Test Pilot has a feature request to include a share link - https://github.com/mozilla/notes/issues/1163 Are there any suggestions that you might have for a work around to update the common response - https://support.mozilla.org/en-US/kb/forum-response-get-troubleshooting-information

  10. guigs said

    They all seem to require a bit more development. One that is built in and easy to use I might propose: what would it look like to change the common response to include Firefox Screenshots of about:support info?

    That occurred to me as an option as well, until I tried it. Screenshots is not available on about:support. :(

    My current clipping is this...

    1. Go to [=] > Help > Troubleshooting Information then click Copy text to Clipboard.
    2. Go to https://pastebin.com/ and go to Edit > Paste to paste the info from your Troubleshooting Information page.
    3. In Firefox, click on the three dots to the right of the address, and select Copy Link.
    4. Open a reply to this post, and go to Edit > Paste to paste the link to your troubleshooting information.

    If there's a pastebin tool that will automatically add the URL to your clipboard, we can eliminate step 3.

    ''guigs [[#post-74504|said]]'' <blockquote> They all seem to require a bit more development. One that is built in and easy to use I might propose: what would it look like to change the common response to include Firefox Screenshots of about:support info? </blockquote> That occurred to me as an option as well, until I tried it. Screenshots is not available on about:support. :( My current clipping is this... <blockquote> # Go to '''[=] > Help > Troubleshooting Information''' then click '''Copy text to Clipboard'''. # Go to https://pastebin.com/ and go to '''Edit > Paste''' to paste the info from your Troubleshooting Information page. # In Firefox, click on the three dots to the right of the address, and select '''Copy Link'''. # Open a reply to this post, and go to '''Edit > Paste''' to paste the link to your troubleshooting information. </blockquote> If there's a pastebin tool that will automatically add the URL to your clipboard, we can eliminate step 3.

  11. Hey folks,

    I brought this up with the admin a few hours ago and I wanted to ping this thread that we are opening a bug to get an official review on the security of using a few 'pastebin' like alternatives. I will post back with the tools that were used.

    Hey folks, I brought this up with the admin a few hours ago and I wanted to ping this thread that we are opening a bug to get an official review on the security of using a few 'pastebin' like alternatives. I will post back with the tools that were used.

  12. What about Firefox Send?

    I saw the Sync team was already using this to request sync logs - the feature is also password protected.

    What about Firefox Send? I saw the Sync team was already using this to request sync logs - the feature is also password protected.

  13. As I posted in the github issue I don't think we need a pastebin in the majority of cases. It seems that users can add all the about:support data to a question when asking, and they should be able to attach it when editing a question, but that appears to be broken. So we just need to fix attaching about:support info on the question edit form, and make access to the troubleshooting data better and easier on the question page. It does seem like a good idea to have a recommended pastebin should we need any other data, but for the about:support stuff specifically I think we can handle it with Kitsune.

    As I posted in [https://github.com/mozilla/kitsune/issues/3284#issuecomment-410825549 the github issue] I don't think we need a pastebin in the majority of cases. It seems that users can add all the about:support data to a question when asking, and they should be able to attach it when editing a question, but that appears to be broken. So we just need to fix attaching about:support info on the question edit form, and make access to the troubleshooting data better and easier on the question page. It does seem like a good idea to have a recommended pastebin should we need any other data, but for the about:support stuff specifically I think we can handle it with Kitsune.

  14. There was an evaluation requested for the dpaste tool as a work around for the other data. It is almost concluded, but we may have a recommended work around. What are thoughts on using Firefox Send since the raw data is considered private information?

    Bug 1484295

    There was an evaluation requested for the dpaste tool as a work around for the other data. It is almost concluded, but we may have a recommended work around. What are thoughts on using Firefox Send since the raw data is considered private information? [https://bugzilla.mozilla.org/show_bug.cgi?id=1484295 Bug 1484295]

  15. guigs said

    There was an evaluation requested for the dpaste tool as a work around for the other data. It is almost concluded, but we may have a recommended work around. What are thoughts on using Firefox Send since the raw data is considered private information? Bug 1484295

    From the bug report:

    guigs [:guigs] PST (please needinfo me!) Comment 8 • 2018-08-21 17:30 EDT

    Just to follow up here, I agree that the currently displayed data in a user question is anonymized, the raw data from about:support does include private info - like the file path to the profile folder on the user's computer. <snip>

    That would be an issue if we are asking people to use the right-click/ select all and right-click/copy method to copy/paste information from the about:support page. When I do that, the file path to the profile folder is copied and will show up when I paste it to a text document.

    However, when I click either the [Copy raw data to clipboard] or the [Copy text to clipboard] button, the file path to the profile folder doesn't appear when I paste it. If we ask users to use one of the copy ... to clipboard buttons (as we do in Forum Response - Get troubleshooting information) then the file path to the profile folder isn't an issue.

    ''guigs [[#post-74546|said]]'' <blockquote> There was an evaluation requested for the dpaste tool as a work around for the other data. It is almost concluded, but we may have a recommended work around. What are thoughts on using Firefox Send since the raw data is considered private information? [https://bugzilla.mozilla.org/show_bug.cgi?id=1484295 Bug 1484295] </blockquote> From the bug report: ----- guigs [:guigs] PST (please needinfo me!) Comment 8 • 2018-08-21 17:30 EDT Just to follow up here, I agree that the currently displayed data in a user question is anonymized, the raw data from about:support does include private info - like the file path to the profile folder on the user's computer. <snip> ----- That would be an issue if we are asking people to use the right-click/ select all and right-click/copy method to copy/paste information from the about:support page. When I do that, the file path to the profile folder is copied and will show up when I paste it to a text document. However, when I click either the [Copy raw data to clipboard] or the [Copy text to clipboard] button, the file path to the profile folder doesn't appear when I paste it. If we ask users to use one of the copy ... to clipboard buttons (as we do in [[Forum Response - Get troubleshooting information]]) then the file path to the profile folder isn't an issue.

  16. Since Chris Ilias referred to it in today's meeting, I want to reiterate what I wrote in my earlier post about copying information from about:support: when I click either the [Copy raw data to clipboard] or the [Copy text to clipboard] button, the file path to the profile folder doesn't appear when I paste it.

    As for the other information in about:support already being private, here is what Chris posted in IRC #sumo from https://mozilla.logbot.info/sumo/20180822

    mozilla #sumo 22 Aug 2018

    01:23 cilias guigs: I'm confused about the security review for dpaste. 01:29 cilias If I want about:support to include specific information, that info has to go through a security review. The preferences section only includes prefs from a whitelist. That's why we don't see "browser.download.lastDir" in about:support. It's set up that way because it is understood that the information is going to be posted in public. Why does dpaste require a security review? Why does it matter where the information is hosted? If the information were 01:29 cilias sensitive, we wouldn't be asking users to post it in a public forum to begin with.

    Here's an old discussion thread on the about:support preferences whitelist: https://support.mozilla.org/en-US/forums/contributors/708157 What prefs should be added to about:support whitelist?

    Since Chris Ilias referred to it in today's meeting, I want to reiterate what I wrote in my earlier post about copying information from about:support: '''''when I click either the [Copy raw data to clipboard] or the [Copy text to clipboard] button, the file path to the profile folder doesn't appear when I paste it.''''' As for the other information in about:support already being private, here is what Chris posted in IRC #sumo from https://mozilla.logbot.info/sumo/20180822 ----- mozilla #sumo 22 Aug 2018 01:23 cilias ''guigs: I'm confused about the security review for dpaste.'' 01:29 cilias ''If I want about:support to include specific information, that info has to go through a security review. The preferences section only includes prefs from a whitelist. That's why we don't see "browser.download.lastDir" in about:support. It's set up that way because it is understood that the information is going to be posted in public. Why does dpaste require a security review? Why does it matter where the information is hosted? If the information were 01:29 cilias ''sensitive, we wouldn't be asking users to post it in a public forum to begin with.'' ----- Here's an old discussion thread on the about:support preferences whitelist: https://support.mozilla.org/en-US/forums/contributors/708157 What prefs should be added to about:support whitelist?
  17. See also: *https://dxr.mozilla.org/mozilla-release/source/toolkit/modules/Troubleshoot.jsm

  18. guigs said on August 16, 2018

    What about Firefox Send? I saw the Sync team was already using this to request sync logs - the feature is also password protected.

    guigs said on August 21, 2018

    There was an evaluation requested for the dpaste tool as a work around for the other data. It is almost concluded, but we may have a recommended work around. What are thoughts on using Firefox Send since the raw data is considered private information? <snip>

    I've never used Firefox Send but this is from a related bug: Bug 1480438 Consider alternatives to pastebin.mozilla.org

    (quote) Clément Lefèvre Comment 31 • 2018-08-20 22:30 EDT

    (In reply to Jonathan Claudius [:claudijd] (use NEEDINFO) from comment #30) > <snip> > TLDR: Perhaps we could use Firefox::Send (https://send.firefox.com/), which > has strong security properties, is actively managed, and is already the > defacto standard for sync log support.

    <snip> I see several flaws to using send.firefox.com as a paste service… starting with the fact it isn't a paste service. Which means, if I'm not mistaken because it changed, that you can't see the content directly online and need to download the file, you're here losing the quickness advantage of such service. Plus expiration time seems to be only short, and content can be seen only once, here again it seems out of topic for many use cases, including the support you're talking about, it's likely that not only one person will want to look at it. <snip>

    Rachel, I made some edits to your pending revision to Forum Response - Get troubleshooting information (see the history).

    ''guigs [[#post-74510|said]]'' on August 16, 2018 <blockquote> What about Firefox Send? I saw the Sync team was already using this to request sync logs - the feature is also password protected. </blockquote> ''guigs [[#post-74546|said]]'' on August 21, 2018 <blockquote> There was an evaluation requested for the dpaste tool as a work around for the other data. It is almost concluded, but we may have a recommended work around. What are thoughts on using Firefox Send since the raw data is considered private information? <snip> </blockquote> I've never used Firefox Send but this is from a related bug: [https://bugzilla.mozilla.org/show_bug.cgi?id=1480438 Bug 1480438] Consider alternatives to pastebin.mozilla.org ----- (quote) Clément Lefèvre Comment 31 • 2018-08-20 22:30 EDT ''(In reply to Jonathan Claudius [:claudijd] (use NEEDINFO) from comment #30)'' > <snip> > ''TLDR: Perhaps we could use Firefox::Send ([https://send.firefox.com/]), which'' > ''has strong security properties, is actively managed, and is already the'' > ''defacto standard for sync log support.'' <snip> ''I see several flaws to using send.firefox.com as a paste service… starting with the fact it isn't a paste service. Which means, if I'm not mistaken because it changed, that you can't see the content directly online and need to download the file, you're here losing the quickness advantage of such service. Plus expiration time seems to be only short, and content can be seen only once, here again it seems out of topic for many use cases, including the support you're talking about, it's likely that not only one person will want to look at it.'' <snip> ----- Rachel, I made some edits to your pending revision to [[Forum Response - Get troubleshooting information]] (see the [https://support.mozilla.org/en-US/kb/forum-response-get-troubleshooting-information/history history]).

  19. If Send would be used then how would we deal with the password that is used to protect its content?

    Send seems meant to be used to transfer sensitive data to specific person(s) and post a link and pass the password via other means (email or otherwise) securely so only selected people can access this content. If Send would be used at SUMO then either the password would have been supplied in the thread what would defeat the security/privacy purpose or the OP would have to pass the password to involved contributors via PM. There would have to be a way to make this password only available to trusted users to make this work easier. Dpaste seems to use only a very short random ID to generate a link instead of a rather long random link (16 chars or more) that would be preferable. Optimally would be a service that doesn't require a login, but would work with an identifier that could be used by the OP to access and remove the upload at any time if necessary or when to time frame to keep is set too long.

    If Send would be used then how would we deal with the password that is used to protect its content? Send seems meant to be used to transfer sensitive data to specific person(s) and post a link and pass the password via other means (email or otherwise) securely so only selected people can access this content. If Send would be used at SUMO then either the password would have been supplied in the thread what would defeat the security/privacy purpose or the OP would have to pass the password to involved contributors via PM. There would have to be a way to make this password only available to trusted users to make this work easier. Dpaste seems to use only a very short random ID to generate a link instead of a rather long random link (16 chars or more) that would be preferable. Optimally would be a service that doesn't require a login, but would work with an identifier that could be used by the OP to access and remove the upload at any time if necessary or when to time frame to keep is set too long.

  20. I wanted to follow up here, as you are all making very good points. I followed up on the bug to see if we can re-evaluate dpaste - it looks like the follow up is happening in these two bugs:

    I asked for a feature enhancement in Firefox Send to have multiple downloads available for the password protected link - and included the SUMO community use case, please feel free to add to that conversation as well, there are plans to keep Firefox Send around and maybe put it into the browser.

    In the meantime I am hoping we can reach a better work around before the release.

    I wanted to follow up here, as you are all making very good points. I followed up on the bug to see if we can re-evaluate dpaste - it looks like the follow up is happening in these two bugs: *[https://bugzilla.mozilla.org/show_bug.cgi?id=1484295#c13 Bug 1484295] *[https://bugzilla.mozilla.org/show_bug.cgi?id=1480438#c31 Bug 1480438 Consider alternatives to pastebin.mozilla.org] I asked for a feature enhancement in Firefox Send to have multiple downloads available for the password protected link - and included the SUMO community use case, please feel free to add to that conversation as well, there are plans to keep Firefox Send around and maybe put it into the browser. *[https://github.com/mozilla/send/issues/914] In the meantime I am hoping we can reach a better work around before the release.

    Modified by guigs on

  1. 1
  2. 2
  3. Next