I would like to add a section to about:support that can list version numbers of dynamically loaded libraries. At this time, I'm interested in NSPR and NSS version numbers. I think about:support would be a good place for that. (Please move this bug to the right component, if about:memory is wrong. Thanks)

This patch depends on the other patch, which I'll attach in a second.

Forward NSS library versions to XPCOM.

The patch creates a new section that looks like the attached screenshot.

removed the "alert" that I used during testing

FYI, the code in the toolkit patch was pretty much copied from the graphics info code.

I think this is a typical case where using ctypes would be recommended.

As a side note, is there really an added value in having versions for the four different nss components, which basically are always at the same version?

(In reply to Mike Hommey [:glandium] from comment #7) > As a side note, is there really an added value in having versions for the > four different nss components, which basically are always at the same > version? Yes, because they are individual shared libraries. The idea is to be able to diagnose whether a running Firefox uses a mix of libraries, loaded from different places of the system. Also, I'd like to know if a user messed up his installation by manually mixing libraries, for whatever intentions the user might have had in mind. In future bug reports I could ask for this information, and rule out that difficult to explain bugs are caused by a unsupported mix of libraries.

(In reply to Mike Hommey [:glandium] from comment #6) > I think this is a typical case where using ctypes would be recommended. If using ctypes involves that I must use a full path to a system library inside of JS, then I don't like your proposal. I want to make very very sure that the information shown in about:support is exactly the software versions linked to our XPCOM engines, and not a potentially different library that the different loading of jstypes found.

(In reply to Kai Engert (:kaie) from comment #9) > (In reply to Mike Hommey [:glandium] from comment #6) > > I think this is a typical case where using ctypes would be recommended. > > If using ctypes involves that I must use a full path to a system library > inside of JS, then I don't like your proposal. No, you just get the library that was loaded by using its name only (and with the helpers in js-ctypes, you don't even need to care about prefix and suffix)

(In reply to Kai Engert (:kaie) from comment #8) > (In reply to Mike Hommey [:glandium] from comment #7) > > As a side note, is there really an added value in having versions for the > > four different nss components, which basically are always at the same > > version? > > Yes, because they are individual shared libraries. > > The idea is to be able to diagnose whether a running Firefox uses a mix of > libraries, loaded from different places of the system. > > Also, I'd like to know if a user messed up his installation by manually > mixing libraries, for whatever intentions the user might have had in mind. > In future bug reports I could ask for this information, and rule out that > difficult to explain bugs are caused by a unsupported mix of libraries. While this may be true for softokn, and maybe freebl, i doubt you'll find mixes of nssutil and nss, for instance.

(In reply to Mike Hommey [:glandium] from comment #11) > While this may be true for softokn, and maybe freebl, i doubt you'll find > mixes of nssutil and nss, for instance. ... and you don't display the version of softokn and freebl.

(In reply to Mike Hommey [:glandium] from comment #12) > > ... and you don't display the version of softokn and freebl. In the future I want to. But it was more difficult to do, and I wanted to get started.

Comment on attachment 598682 [details] [diff] [review] Patch v1-b - PSM part [checked in] Review of attachment 598682 [details] [diff] [review]: ----------------------------------------------------------------- r=honzab

Comment on attachment 598687 [details] [diff] [review] Patch v2 - toolkit part I don't think this info is actually going to be useful, and just adds more noise to the already-cluttered about:support. IE, when would this info be helpful in solving a problem and who would be looking at it? If Cww thinks it would help, though, I'll reconsider. I'd think it more useful to have, say, a wiki page mapping FF/TB/SM releases to NSS/NSPR releases. Perhaps easy enough to scrape from the FTP servers with a small shell script?

Justin, you're totally frustrating me. You're rejecting my work, even before you have heard my answers to my your question? You're rejecting to add troubleshooting information to a troubleshooting information page? Who would be looking at this information? I would, because it's my job to analyze bug reports. If you're rejecting this info, you're making my life harder, and having to live with a situation where such information is unavailable might result in less bug analyis happening. With the rapid release of Mozilla it has become more complicated to keep track of Mozilla. Yes, we try. I indeed have already created such wiki pages. But we don't know what's happening on a user's system. We don't know what library might be installed on a Linux distribtion.

I apologize for my rant. I personally believe that about:support would be the most natural place for this information. But as you disagree, I will find a place in some security dialog for that information (although that doesn't make a lot of sense for the NSPR version.) I hope that no UI person will disagree to a new button in one of the security dialogs...

Ok, I believe a good place would be the "device manager". That can already be readed from the security preferences, and the code for that dialog is completely in PSM. That dialog has plenty of buttons, and I could add a button there for "Security software version" (although that information is misplaced there, but better somewhere than nowhere).

Changing bug component to PSM.

Comment on attachment 598687 [details] [diff] [review] Patch v2 - toolkit part Actually, let's try to hear additional opinions, before I give up on this.

Comment on attachment 598682 [details] [diff] [review] Patch v1-b - PSM part [checked in] Checked in the backend part. https://hg.mozilla.org/integration/mozilla-inbound/rev/2bf0c6213e91 UI part still pending.

Comment on attachment 598687 [details] [diff] [review] Patch v2 - toolkit part Uh, this bug inflamed in a hurry. I suspect dolske was r-'ng with questions to ensure you got an answer quickly, rather than having it linger in his review queue forever. I think he's quite amenable to discussion on the point. If the mapping is actually difficult to maintain I certainly have no problem making it accessible somewhere, though I do wonder if about:buildconfig might make more sense. Clearing the ui-r request, though - about:support (or :buildconfig!) doesn't have much of a UI per se, this is more of a "do we want this" call than an "is this the right UI" call.

Just to understand the problem here, is the main issue that for linux distros we may end up using some version of nss/nspr different to that which we expect?

(In reply to Dave Townsend (:Mossop) from comment #24) > Just to understand the problem here, is the main issue that for linux > distros we may end up using some version of nss/nspr different to that which > we expect? It's not just Linux. This had also happened with a Mac user who had played with system libraries.

(In reply to Kai Engert (:kaie) from comment #25) > (In reply to Dave Townsend (:Mossop) from comment #24) > > Just to understand the problem here, is the main issue that for linux > > distros we may end up using some version of nss/nspr different to that which > > we expect? > > It's not just Linux. > > This had also happened with a Mac user who had played with system libraries. ... and forget about it, reported a bug, and I tried to understand why he got unpexpected results. (In a future step I also intend to add another version number to the list, which I currently have not available from JS: the version of the builtin trust module (root CAs), which helps us in analyzing trust problems with web sites. IIRC the Mac user's problem was related to that.)

(In reply to Kai Engert (:kaie) from comment #25) > (In reply to Dave Townsend (:Mossop) from comment #24) > > Just to understand the problem here, is the main issue that for linux > > distros we may end up using some version of nss/nspr different to that which > > we expect? > > It's not just Linux. > > This had also happened with a Mac user who had played with system libraries. Ok, one other thing that springs to mind, is it possible for us to know at runtime if we're using an unexpected version? That way we could only show the version number if it isn't expected, it'd give you the info you want without having to include it for the normal case. We do basically the same thing for the preferences section. This might also help the support guys immediately see a potential red-flag whenever it is there without needing to know what the right versions are.

Your proposal in comment 27 is not helping me. With Mozilla's version number inflation, I must be able to find out which version exactly is being used in a Mozilla version. I shouldn't have to remember whether the version of NSS changed between Firefox 14.0 and 14.0.1

If you'd like to get the proposal from comment 27 implemented (giving a red flag to support people), then I'd ask for three columns, name of library, expected version number, actual version number, optionally highlighting an unexpected version.

(In reply to Kai Engert (:kaie) from comment #28) > Your proposal in comment 27 is not helping me. > > With Mozilla's version number inflation, I must be able to find out which > version exactly is being used in a Mozilla version. I'm not sure I understand. I'm suggesting we could only show the version number if it isn't the library we expect so you can tell immediately if the user is using the wrong version without having to remember which version is expected for each Firefox version. Am I missing something?

Also note that using a newer version number is always fine. Mixing some versions is a problem. Using versions older than expected is a problem. I would please like to avoid inventing an algorithm to derive which combinations are fine and which are not. All I'm asking is a little bit of information to make my life much simpler, in all those scenarios where we are facing a bug that is tricky to analyze. (I cannot understand why NSS software library versions should be less important than a graphics card driver version.)

(In reply to Dave Townsend (:Mossop) from comment #30) > (In reply to Kai Engert (:kaie) from comment #28) > > Your proposal in comment 27 is not helping me. > > > > With Mozilla's version number inflation, I must be able to find out which > > version exactly is being used in a Mozilla version. > > I'm not sure I understand. I'm suggesting we could only show the version > number if it isn't the library we expect so you can tell immediately if the > user is using the wrong version without having to remember which version is > expected for each Firefox version. Am I missing something? This isn't helpful, because a Linux distribution might ship a newer version of NSPR/NSS than expected. Also a Linux distribution might deliberately decide to ship an older NSS crypto core because of US GOV FIPS certifications, which isn't usually a problem, but it's still very helpful information for problem diagnosis.

I presume your next proposal might be to suggest: "Only show version number if it's smaller than expected". Doesn't work either, because NSS versions of the same number can differ by a crypto cipher support indicator (such as with ECC, basic or extended, or without), and this is also very helpful information for diagnosis.

(In reply to Kai Engert (:kaie) from comment #32) > (In reply to Dave Townsend (:Mossop) from comment #30) > > (In reply to Kai Engert (:kaie) from comment #28) > > > Your proposal in comment 27 is not helping me. > > > > > > With Mozilla's version number inflation, I must be able to find out which > > > version exactly is being used in a Mozilla version. > > > > I'm not sure I understand. I'm suggesting we could only show the version > > number if it isn't the library we expect so you can tell immediately if the > > user is using the wrong version without having to remember which version is > > expected for each Firefox version. Am I missing something? > > This isn't helpful, because a Linux distribution might ship a newer version > of NSPR/NSS than expected. > > Also a Linux distribution might deliberately decide to ship an older NSS > crypto core because of US GOV FIPS certifications, which isn't usually a > problem, but it's still very helpful information for problem diagnosis. Ok but in both those cases what I suggested would include exactly the same information as if we just always showed the versions so you'll need to figure out whether they are newer or older either way, but with my suggestion you'll have an additional piece of information, that the version number is different so you know it is worth figuring out how they are different and if that might be the cause of the issue you are investigating.

about:support shows the IP address of my printers and which paper sizes they each accept taking up a huge number of rows. Why shouldn't it include the version numbers of core Firefox components, which are useful to people looking into bug reports and harmful to precisely no-one? This back and forth around a piece of UI that most people don't ever see is such a waste of resources and frustrating for an onlooker, let alone someone who's written a patch to fix things.

Dave, if I enhance the patch to show three columns, expected version and actual version, will you r+ it? Thanks

(In reply to Kai Engert (:kaie) from comment #16) > You're rejecting my work, even before you have heard my answers to my your > question? No, I r-'d the patch and asked some questions. As Johnath noted, getting a prompt answer instead of a lingering ambivalent review is something there's been a widespread push for. I'm not sure why you think that is some kind of personal attack. It's not. > You're rejecting to add troubleshooting information to a troubleshooting > information page? Yes, because this is a page used by support, and I'd like to keep it useful to them and avoid dumping in random info if we can help it. For the vast, vast, majority of the cases where support is asking for this info to help a user, NSS/NSPR library info is not going to be relevant or useful. I'm not saying it can't be exposed _anywhere_, but about:support does not seem like a good place for it. Somewhere (crashreporter) there's already code for gathering module info (.so/.dylib/.dll) at runtime. And we certainly have lots of libraries in-process, many of which have the exact same issues... Assuming module info is of such importance, I'd think we should fix this in a way that lists this info for all modules. about:buildconfig would be a suitable home, given that it's much more developer focused. [And issues involving problems like this are quite likely to require intervention from someone like a developer.]

(In reply to Justin Dolske [:Dolske] from comment #37) > > this is a page used by support, and I'd like to keep it useful > to them and avoid dumping in random info if we can help it. My about:support page shows about 500 changed preferences (mostly because of printers). > For the vast, > vast, majority of the cases where support is asking for this info to help a > user, NSS/NSPR library info is not going to be relevant or useful. The printer info is probably even less useful. > I'm not > saying it can't be exposed _anywhere_, but about:support does not seem like > a good place for it. In my opinion, about:support makes more sense, because it contains dynamic information from runtime, while buildconfig contains only static information from buildtime. > Somewhere (crashreporter) there's already code for gathering module info > (.so/.dylib/.dll) at runtime. And we certainly have lots of libraries > in-process, many of which have the exact same issues... Assuming module info > is of such importance, I'd think we should fix this in a way that lists this > info for all modules. about:buildconfig would be a suitable home, given that > it's much more developer focused. [And issues involving problems like this > are quite likely to require intervention from someone like a developer.] This makes it more complicated to solve my problem, by suggesting additional work that nobody has asked for. The information I want to add cannot be added using general purpose code.

Ok, let's get constructive. Dave has proposed to display both "expected version" and "actual version". I'm willing to make this enhancement, under the assumption that Dave will support me in getting this information added. Justin has proposed to move this information to about:buildconfig. I'm willing to change the bug to do that, too. However, I would like to kindly ask in advance, will you r+ the patch if I implement both changes? Thanks

(In reply to Justin Dolske [:Dolske] from comment #37) > (In reply to Kai Engert (:kaie) from comment #16) > > > You're rejecting my work, even before you have heard my answers to my your > > question? > > No, I r-'d the patch and asked some questions. As Johnath noted, getting a > prompt answer instead of a lingering ambivalent review is something there's > been a widespread push for. I'm not sure why you think that is some kind of > personal attack. It's not. > > > You're rejecting to add troubleshooting information to a troubleshooting > > information page? > > Yes, because this is a page used by support, and I'd like to keep it useful > to them and avoid dumping in random info if we can help it. For the vast, > vast, majority of the cases where support is asking for this info to help a > user, NSS/NSPR library info is not going to be relevant or useful. I'm not > saying it can't be exposed _anywhere_, but about:support does not seem like > a good place for it. I think for the time being about:support is the place we have. about:buildconfig is generated at build time and does not have the privileges it would need to do this, we'd have to go through the security review process to flip that bit which seems over the top for this. > Somewhere (crashreporter) there's already code for gathering module info > (.so/.dylib/.dll) at runtime. And we certainly have lots of libraries > in-process, many of which have the exact same issues... Assuming module info > is of such importance, I'd think we should fix this in a way that lists this > info for all modules. about:buildconfig would be a suitable home, given that > it's much more developer focused. [And issues involving problems like this > are quite likely to require intervention from someone like a developer.] I think this might be a fine future page (about:libraries?) but again we have a patch here that covers two extremely important libraries to us so I don't see a need to slow down landing this to wait for that. (In reply to Kai Engert (:kaie) from comment #36) > Dave, if I enhance the patch to show three columns, expected version and > actual version, will you r+ it? Yes I would. I should mention that I spoke a little with Cww last night and it's actually extremely rare that users provide the contents of this page to us, so right now changes to it are less of a big deal to the support team (though we should still avoid overloading it). There is the potential of allowing some kind of auto-submission though which might cause us to re-evaluate what is and isn't on this page in the future.

This patch adds the ability to query the build time NSPR/NSS library versions from JS.

>> Dave, if I enhance the patch to show three columns, expected version and >> actual version, will you r+ it? >Yes I would. Dave, thanks a lot for your support and thanks in advance for looking at this new patch, see also the updated screenshot.

Dave, thanks for the r+ Does the toolkit patch need superreview?

(In reply to Kai Engert (:kaie) from comment #44) > Dave, thanks for the r+ > > Does the toolkit patch need superreview? Nope

Comment on attachment 603864 [details] [diff] [review] Additional patch v3 for PSM [checked in] Requesting an additional review for the PSM portion, in an attempt to get it done by tomorrow.

Comment on attachment 603864 [details] [diff] [review] Additional patch v3 for PSM [checked in] r+ rrelyea

Comment on attachment 603864 [details] [diff] [review] Additional patch v3 for PSM [checked in] https://hg.mozilla.org/integration/mozilla-inbound/rev/20c9cd87856b

Comment on attachment 603869 [details] [diff] [review] Patch v4 - toolkit part [checked in] https://hg.mozilla.org/integration/mozilla-inbound/rev/336b0c09d2d6

https://hg.mozilla.org/mozilla-central/rev/20c9cd87856b https://hg.mozilla.org/mozilla-central/rev/336b0c09d2d6