Closed Bug 432017 Opened 18 years ago Closed 12 years ago

Selecting remove personal data description text should clearly state that it removes *all* Firefox personal data

Categories

(Firefox :: Installer, defect)

x86
Windows Vista
defect
Not set
critical

Tracking

()

VERIFIED FIXED
Firefox 31
Tracking Status
firefox31 --- verified

People

(Reporter: amir.aharoni, Assigned: robert.strong.bugs)

References

Details

(Keywords: dataloss)

Attachments

(2 files, 1 obsolete file)

User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.0; en-US; rv:1.8.1.14) Gecko/20080404 Firefox/2.0.0.14 Build Identifier: Mozilla/5.0 (Windows; U; Windows NT 6.0; en-US; rv:1.8.1.14) Gecko/20080404 Firefox/2.0.0.14 It is possible several versions of Firefox on one Windows computer. I usually use the stable version and sometimes install betas. When i uninstall a beta, i am asked: "Remove my personal data and customizations". If the checkbox is checked, all cookies, extensions, bookmarks etc. are removed and it pertains to all installed versions. This is confusing and desctructive. For example, a bookmark that is added in Fx 2 is not seen in Fx3, but when Fx3 is unistalled, it is deleted. It happened to me today - i uninstalled Firefox 3.0b5, and i thought that only the personal data for the beta will be removed, but when i came back to 2.0.0.14, all my bookmarks were gone. I mark this as critical, because it did cause me to lose data. I understand that betas can give you unpleasant surprises and i guess that i should have been more careful, but the installer should have notified me about the danger. Reproducible: Always Steps to Reproduce: 1. Install Firefox 2. 2. Install Firefox 3 beta on the same computer. 3. Add a bookmark in Fx 2. 4. Add a search engine to the search bar in Fx 2. 4. Open Firefox 3. The search engine is seen. The bookmark is not seen, which is probably OK, but kinda confusing. 5. Uninstall Firefox 3 and check "Remove my personal data and customizations". All bookmarks, search engines, cookies etc. are deleted. Actual Results: All bookmarks, search engines, cookies etc. are deleted. Expected Results: Something else. At least there should be a clearer warning: If you do this, then personal data for ALL VERSIONS OF FIREFOX installed on this computer will be destroyed.
Whoops, guess it's time for you to restore a backup or go fish things out with an undeleter... ;) This has nothing to do with beta; you could get the same effect with 2 released versions of Firefox installed. (and I don't think this really qualifies as "critical", though adding a "dataloss" keyword might be valid) I think a warning is all one could hope for here. Just make it clear that this selection removes all Firefox profile data for all versions installed. Though, it's on the user to not remove something they want to keep.
Yes, as i wrote - a clear warning would be OK. Doing something more clever has lower priority. In the particular case of bookmarks - i guess that the confusion stems from the fact that their handling is completely different in Fx3, but that's not something that you can expect every user to deduct. *I* am quite informed about Firefox versions history and i still made the mistake; most of other users are even less informed. To make a long story short: put up a big red warning saying "if you check this box, all your data from all Firefox versions will be deleted!".
Perhaps the current warning isn't enough for everyone...
> Perhaps the current warning isn't enough for everyone... I saw this warning. Call me silly, but i thought that it only deletes information that was created by the version that i am uninstalling.
(In reply to comment #3) > Perhaps the current warning isn't enough for everyone... It lists the program install directory and says it'll install all bookmarks, passwords, etc. Unless the users actually knows their Firefox profile is NOT in that stated directory, this text does imply that what's being removed is specific to the program installed here. Additionally, it calls it "my Minefield personal data", which also implies that this is separate, and not for Firefox too. Yes, not everyone has a problem with this, but I can see how it can be misunderstood. Rewording this to simply be more explicit, and tell the user that all versions of Firefox and Minefield can share the same profiles, makes sense. Either that, or beat them over the head with more "backup your profile before testing" warnings on Minefield install. (or both)
I agree that some people will interpret this in the way you state and actually that the current warning won't be enough for everyone... that is the nature of text in general. In regards to the 'Minefield' text - it is only applicable to nightly builds and we will always have issues like this in regards to nightly builds.
Target Milestone: --- → Future
Version: unspecified → Trunk
(In reply to comment #5) > Rewording this to simply be more explicit, and tell the user > that all versions of Firefox and Minefield can share the same profiles, makes > sense. Either that, or beat them over the head with more "backup your profile > before testing" warnings on Minefield install. Everybody will ignore recommendations to backup the profile. Hardly anyone knows what a profile is and how to back it up, even among people who are curious enough to install betas.
Summary: removing one version may destroy personal data for all versions → Selecting remove personal data description text should clearly state that it removes *all* personal data
Summary: Selecting remove personal data description text should clearly state that it removes *all* personal data → Selecting remove personal data description text should clearly state that it removes *all* Firefox personal data
I agree, a warning in uninstall for betas (and also a warning when you try to load a profile created with a stable version of Firefox) will be very user-friendly and will prevents data disasters.
Tested using a 20080512 RC1 installer build: That is not data removal for the named version, that is data destruction of everything the user ever saved in any version of Firefox after version 0.8. With the Profiles and the profiles.ini file in App Data instead of the program files directory like with K-Meleon, there is no way the un-installer knows exactly which Profile is associated with the program being un-installed. This feature should be removed because there isn't any way to make it work correctly, and the user is better off with "extra" data than to lose "everything".
(In reply to comment #9) > This feature should be removed because there isn't any way to make it work > correctly, and the user is better off with "extra" data than to lose > "everything". No, that's overkill. I very much want to be able to uninstall EVERYTHING if I so choose, leaving no litter behind. We just need to make it absolutely clear to users what they are telling it to do. Profiles do know when they've been loaded by an updated browser, so it might be possible to have the uninstaller ~try~ to figure out who's it is, but it may not be worth it.
I'm quite sure System Restore successfully undoes such changes.
(In reply to comment #11) > I'm quite sure System Restore successfully undoes such changes. That's a bit off topic, but let me say just this: If you're relying on Windows to fix things for you, you're screwed. :) Yes, there are ways to get this back. You should be backing this all up if you're beta-testing, anyway, and there's always undeleters. However, anyone who accidentally wiped their stuff because they didn't know what was going on isn't going to know what's going on enough to get it back.
Status: UNCONFIRMED → NEW
Ever confirmed: true
Current text: This will permanently remove your bookmarks, saved passwords, cookies and customizations. You may wish to keep this information if you plan on installing another version of $BrandShortName in the future. Suggested new text: This will permanently remove your bookmarks, saved passwords, cookies and customizations from all of your profiles. You may wish to keep this information if you plan on installing again in the future. I think there should be an additional sentence that states essentially, "When in doubt don't do this!"
Alex and Mike, can I get your input on what the text should state (see comment #15 for a suggestion). Thanks
(In reply to comment #15) > Suggested new text: > This will permanently remove your bookmarks, saved passwords, cookies and > customizations from all of your profiles. You may wish to keep this information > if you plan on installing again in the future. Looks good and "all of your profiles" should be bold!
Perhaps: [yellow warning icon] "This will permanently remove your bookmarks, saved passwords, history and customizations. You may wish to keep this information if you plan on installing $BrandShortName in the future. This action can not be undone." I would only mention "...from all of your profiles" if we detect that there is actually more than 1 (since multiple profiles is extremely rare). rationale for the other changes: -history is more valuable than cookies, and cookies are a subset -"installing $BrandShortName" seems more likely to trigger the thought "oh, I am going to install _Firefox_ again" -odds are the user will see the white space, read the end first: "this action can not be undone" and then think "well perhaps I should actually read this thing then"
Thanks Alex! The only concern I have with your recommendations is that by having $BrandShortName some nightly users will think this won't affect Firefox profiles... I believe we have had at least one person think this.
>The only concern I have with your recommendations is that by >having $BrandShortName some nightly users will think this won't affect Firefox >profiles... yeah, that would be really bad. I hate to go with a lot of strings and detecting, but we might want to include different text in the event that the $BrandShortName is not Firefox. We could simply drop: "You may wish to keep this information if you plan on installing Firefox in the future." That sentence might annoy nightly testers anyway even if fully disambiguated to cover all versions (since they are more likely to know when they should or should not delete all of their data).
Why not just directly address the problem? It's a little wordy, but I suggest: "This will permanently delete your bookmarks, saved passwords, history and customizations from all of your Firefox profiles. This applies to all versions of Firefox, including development builds. You may wish to keep this data if you plan on installing Firefox in the future or if you have multiple versions of Firefox installed. This action can not be undone!" I think in this instance it might be a good idea to just say "Firefox" in all instances. Be it Minefield, one of the branches, stable Firefox, or some other build, it is valid to say that wiping will apply to new Firefox installs or other versions of Firefox already installed. It only makes sense to restrict to the current $BrandShortName if the action itself is actually restricted too. It's not, hence some of the problems.
I agree for the most part though being wordy will likely cause a small subset of people to delete their data in the same way as a small subset of people delete their data currently so the shorter while still being clear the better. Another option I have considered is to just delete the cache data which won't have this risk and was one of the main reasons when we added offline storage for adding this functionality... mconnor, since you were the person that originally requested this what do you think about that?
(In reply to comment #18) > I would only mention "...from all of your profiles" if we detect that there is > actually more than 1 (since multiple profiles is extremely rare). It doesn't hurt even if there's only one profile. (In reply to comment #20) > "You may wish to keep this information > if you plan on installing Firefox in the future." > > That sentence might annoy nightly testers anyway even if fully disambiguated to > cover all versions (since they are more likely to know when they should or > should not delete all of their data). The developers and the testers are never more important than end users. The testers can get used to it.
With 20% less wordiness: "This will permanently delete your bookmarks, saved passwords, history and customizations. This applies to all profiles for all versions of Firefox, including development builds. Do not delete this if you wish to use it with another installation of Firefox. This action cannot be undone!" I know this thing is a rocket powered foot gun, but I really do think that it needs to be in the uninstaller somewhere, even if you have to add a compromise cache wipe and de-emphasize this. Uninstallers should always be able to uninstall everything. Maybe split into a standard and custom uninstall route and bury it in there instead? Though, I think that as long as it mentions everything, it's probably enough to just fix the description. The current problem is that it isn't really clear to those who read it. Users screwing up because they don't read it is another matter entirely that we can't completely avoid.
I personally believe that the trouble is that there is no way it will be clear to everyone and some people will always shoot themselves in the foot. Going with a cache / offline storage option removes the gun from their hands. Also, the vast majority of Windows uninstallers don't provide an option to do this likely for this very reason... it isn't that I would be against all uninstallers having this option but the reality is not everyone should be given this option.
I can't disagree with your logic, but I do hate programs leaving litter around that users aren't aware of. How about this: tell the user how to do this manually instead. Just a checkbox to wipe cache and then a box saying it'll leave the rest of the profile data in tact, with the path to them shown. Thus if the user really does want to kill it all then they know they can, but they have to go do the deed themselves.
Or, yet another possible idea: Keep the checkbox to delete all the profiles but back up everything other than the cache (and urlclassifier) in a ZIP archive saved to My Documents. This way the user could clear out stuff in hidden folders that they probably don't know about, but still keep the core important stuff and move it to a better location. If they want to then delete that, it's up to them.
Simply writing longer text about how dangerous the action is feels a little like blame the victim design. If we know the user isn't going to read long text at all, we are sort of setting them up to fail, but it's ok, because it is their fault.
I don't get the cache thing... ultimately, the reasons I cared about this are: * Giving users a way to delete their userdata (since anyone could install/run Firefox and capture all of their sweet sweet unencrypted data). As these files are hidden by default, it takes some real knowledge to purge private data after you uninstall. * Allowing users to make a clean start (many users uninstalled/reinstalled and didn't understand why their data was still there) * Making it so that the "uninstall, install in a year" case was more likely to hit the profile migration code and get a useful initial state I don't think wording will really make this much different. I don't know if we can do much with dynamic UI here, but I do think that removing/crippling the option hurts more than it helps. (Any clear all UI has the danger of misuse and dataloss, but the answer is not to make it impossible to clear all.)
>As these files >are hidden by default, it takes some real knowledge to purge private data after >you uninstall. On the topic of where the profile lives, I filed bug 532245, something I've been concerned with for awhile but never got around to filing.
Playing devil's advocate here (In reply to comment #29) > I don't get the cache thing... ultimately, the reasons I cared about this are: > > * Giving users a way to delete their userdata (since anyone could install/run > Firefox and capture all of their sweet sweet unencrypted data). As these files > are hidden by default, it takes some real knowledge to purge private data after > you uninstall. Windows uses user accounts / file permissions to protect data. If the user is not then these users' sweet sweet unencrypted data is available to others while they have Firefox installed which is IMO just as bad. > * Allowing users to make a clean start (many users uninstalled/reinstalled and > didn't understand why their data was still there) I highly doubt the majority of users check the checkbox on uninstall so this more likely would be extremely small / not worthwhile value. Educating users as to why would be an appropriate response to this problem and is also the behavior of the vast majority of Windows apps. Also, if clean starts are really valuable to users then it should be made available in the app itself (a safe mode option?) so it is available on all platforms. I suspect this is also suppose to fix the problem of corrupt profiles. I believe the appropriate response to that is to provide utilities to accomplish this instead of providing the user with a sledgehammer approach for only one platform that is available on every uninstall such as this current solution. * Making it so that the "uninstall, install in a year" case was more likely to > hit the profile migration code and get a useful initial state I highly doubt the majority of users check the checkbox on uninstall so this more likely would be extremely small / not worthwhile. Instead the migration code should detect / handle this. > I don't think wording will really make this much different. I don't know if we > can do much with dynamic UI here, but I do think that removing/crippling the > option hurts more than it helps. (Any clear all UI has the danger of misuse > and dataloss, but the answer is not to make it impossible to clear all.) Not sure how dynamic UI would really help this without hiding / disguising the option which would negate to a large extent the value statements. Having said that and keeping in mind that perfect is the enemy of good I'll work with Alex's reworded text and try to make the result of this option more prominent.
Attached patch patch in progress (obsolete) — Splinter Review
Still need to handle the single / multiple profile cases.
actually, the italian version of the notice says: "...Si potrebbe avere interesse a mantenere tali informazioni nel caso in cui si decida di installare un'altra versione di Firefox in futuro." which could be translated as "...You could be concerned in keeping these information if you will install another version of firefox in the future". since i wasn't going to install another version, but just discarding the beta and working with the previous version still installed in the system, your message IS misleading (or uncorrectly translated).
I just had my firefox profile wiped due to this bug. I installed the nightly build to test a bug, then uninstalled it. Because I wasn't planning on installing 'nightly' in the future I assumed it would be a good idea to let the uninstaller delete all the data associated with 'nightly', not realising it would delete my firefox 4 profile as well. I can think of 2 possible solutions: [1] Replace $BrandShortName with something else ('firefox products' or 'mozilla products' or just remove it completely). [2] Check to see if user has more than one version of firefox installed, and if so give a more explicit warning that it will delete profile data from ALL installed firefox versions. I think this would be the best solution, if it is possible.
We should make sure that each release channel uses a different local profile. If user's want the same data across different release channels they can set up sync, and then there won't be any chance of them losing data, or profiles getting corrupted due to forward/backward compatibility issues.
Alex, have you filed a bug?
cc'ing Limi, I believe that he's on it
> You may wish to keep this information if you plan on installing $BrandShortName > in the future I think we are missing a point: all major browsers has an "import" tool, so probably you will not remove all your _Firefox_ data, but all your data, point. Furthermore think about Firefox derivatives, as Seamonkey. IMO this sentence should be removed, or rephrased.
This has been going on for 3 years and *nothing* has changed...?! Just lost all my preferences, bookmarks (not such a big deal since I've been moving them over to cloud-based), and add-ons + configurations in Firefox after uninstalling Nightly. Seriously, just add the more comprehensive text to the uninstaller dialog. How hard can that be? Certainly easier than following this for 3 years...
cc'ing Gavin, Shaver, and Benjamin to get their take on this. Summary as I see it: 1. most Windows apps just don't provide an option to remove personal data. 2. the desire to provide an option to remove personal data is a good one but I strongly don't think it is a good thing to provide that option to all users which includes users that don't want or need to do this and some of them will just click the checkbox or misunderstand the text if for no other reason than the large number of Firefox users. 3. the ability to remove personal data as a security concern is not a good reason since the data is already protected by Windows file permissions and the same data is available when the user doesn't select this option. 4. no other platforms have this "feature". In case you can't tell, I strongly think this should just be removed.
(In reply to comment #43) Once upon a time, this issue fell under the category of "I told you to be careful, back up things, and read the manual". The checkbox does exactly what it says with the caveat that Minefield is Firefox, which generally people who were testing Minefield knew full well. Now is a different story. We've got way more people using Minefield and are encouraging even more, and they don't always know as much about things as one used to expect here. Personally, I'm against removing it outright, though it wouldn't be the end of the world. I don't like uninstallers that can leave litter around, especially private information and passwords in a profile a user may have thought they got rid of because the uninstaller didn't say fully what it was doing. I expect it to at least have the option to uninstall everything if the user wants to. It just needs to be damn more explicit, probably with an additional confirmation prompt explaining that there is only one Firefox profile(s) folder for all versions, regardless of naming. (In reply to comment #44) > 3. the ability to remove personal data as a security concern is not a good > reason since the data is already protected by Windows file permissions and > the same data is available when the user doesn't select this option. I'm sure I'm not the only one who thinks expecting Windows file permissions to protect anything is a bit far fetched, especially on Windows XP which is still very common. The primary use case I think this option is relevant for is for when someone gives/donates/sells their computer to someone else and want to get rid of what they know is their private Firefox data. Most people simply have no idea how to truly and securely format their HD and reinstall the OS, so this is better than nothing.
(In reply to Dave Garrett from comment #45) > The checkbox does exactly what it says with the caveat that Minefield is > Firefox... Yes and no. This is sort of a conceptual/ideology issue: what "is" is :)? Nightly and Aurora builds are Firefox, in that it is a development version of the same code base that will become a Firefox release, it is compiled by the ame developers, etc. However, it is also to say those builds are _not_ Firefox, at least under Windows, because if you have, say, a nightly and a release, or an Aurora and a beta, on the same PC, they are shown as two different items in the list of installed programs, etc. For this reason, in bug 680650 I submitted before seeing this one, I said that we have a situation "where one application's uninstaller is removing a (technically) different application's profile data without warning". I still believe it is unacceptable.
(In reply to Maksym Kozub from comment #48) > Nightly and Aurora builds are Firefox, in that it is a development version > of the same code base that will become a Firefox release, it is compiled by > the ame developers, etc. Read "...in that they are development versions..., they are compiled by the same developers, etc." :). > However, it is also to say those builds are _not_ Firefox... Read "...it is also possible to say...". Sorry for those typos.
Yeah this is a pretty serious dataloss issue. Users have a mental model that different release channels have different profiles (nightly, aurora, beta, Firefox), even though that isn't true. And this is of course significantly compounded by the fact that we state we are only deleting data for brandName (where it is one of those, but not all of those). Best fix is to actually give the channels different profiles, and let users access the same set of data with sync. In the meantime, as suggested we really need to add a warning string, like "This will delete your personal data for all different versions on your machine."
Keywords: dataloss
Alex, if you "bless" a string for communicating this then I'll make sure it gets changed during the installer rewrite that is planned to start next month. I still think we are putting a gun in people's hands and that some will still shoot themselves in the foot if for no other reason that to see what the checkbox does but hopefully there will be fewer of them with clearer text.
Modifications: UN_REMOVE_PROFILES=&Remove my personal data and customizations for all versions UN_REMOVE_PROFILES_DESC=This will permanently remove your bookmarks, saved passwords, cookies and customizations for all versions. You may wish to keep this information if you plan on installing another version in the future. Note that both references to &brandShortname were removed, since this was implying that Aurora data was different than Firefox data, etc. >I still think we are putting a gun in people's hands and that some will still >shoot themselves in the foot yeah I know, simply writing "gun" on it doesn't really help all that much. Ultimately we need to fix this with separate profiles for each release channel.
Giving all channels different profiles adds new complexity and probably also new kind of bugs. Most users currently "know" that all flavors of Firefox share the same profiles and there will likely be new ways to fool oneself while jumping between the channels. It will also be harder to find out for example whether a later version has solved a problem or not since sync doesn't replicate a profile byte by byte. Did the sync solve the problem, or the upgrade? I definitely agree that the current warning string must be changed, but I'm not sure "This will permanently remove your bookmarks, saved passwords, cookies and customizations for all versions[...]" is explicit enough. "Well, I just have one version of Aurora installed, so lets delete all those profiles before I go back to Beta again. *zap!*"
comment #54 is why I would very much like to just remove the option. The value provided by having this option is so minimal when compared to people accidentally shooting themselves in the foot.
Is there an easy way to add an additional string only to show in the uninstaller for non-release builds to very explicitly say "Release, Beta, Aurora, and Nightly builds of Firefox all share the same profile by default"?
We're trying to remove all changes between Release and Beta so Beta is the same as or as close as possible to what is released.
yep, let's just remove the option.
(In reply to Alex Faaborg [:faaborg] (Firefox UX) from comment #58) > yep, let's just remove the option. Remove it in just the development builds or release too? Removing the full option but just allowing the wiping of the cache to free up disk space with a quick explanation that the profile data will remain, with the path to it shown, would allow for the use case where this current method is actually needed to be done manually. (suggested in comment 26)
All builds. IMO the cache is safe to remove since it can be rebuilt... at worst an annoyance for people that uninstall often... so, the ui option shouldn't be necessary.
Still happening on the latest Nightly (10). Just wiped out over five years worth of settings, bookmarks and customizations. > yep, let's just remove the option. That doesn't really fix the problem. The setting needs to be changed, not removed. It should remove all data only for the Nightly build. Else the dialog should be changed to "remove the data you were using to test this build AND destroy all of your saved data from the version of Firefox that you use on a daily basis?"
(In reply to Josh from comment #61) > > yep, let's just remove the option. > > That doesn't really fix the problem. The setting needs to be changed, not > removed. It should remove all data only for the nightly build. This is the reason for removal; people don't understand the Nightly build is Firefox and that they necessarily share the same set of profiles. You can't just remove the data for one unless the user created a new profile just for it, in which case they would be deleting it themselves. At this point, one way to describe this issue is that it's a symptom of the fact that many of the people using nightlies were never intended to. You used to have to download after reading the boilerplate "backup your data and don't expect these to work" line, and we don't make much of an effort to explain this to people anymore. Instead, nobody expects to even be careful here, and if Mozilla wishes to keep expanding the nightly user base things like this need to be redesigned to be safer for those who don't know what they're doing. Just axing this is the simplest fix at this point.
Simple answer often is not the best answer. I think the better way is to not use %AppData/Mozilla/Firefox (or ~/.mozilla/firefox) but another folder for nightlies and the like, and ask user the first time if he want to import an Fx profile. But this is another bug. If it wasn't proposed before I open it. About this bug, personally I dislike programs that does not offer you the possibility to uninstall them completely.
(In reply to Lucas Malor (mail: c6kfnkn2uc AT snkmail DOT com) from comment #63) > Simple answer often is not the best answer. I think the better way is to not > use %AppData/Mozilla/Firefox (or ~/.mozilla/firefox) but another folder for > nightlies and the like, and ask user the first time if he want to import an > Fx profile. But this is another bug. If it wasn't proposed before I open it. This has been suggested many times before and rejected because it's basically not what nightlies are for. A nightly build is a test build of Firefox, and aside from the branded name, it's supposed to be exactly the same. You're not supposed to use it if you can't handle this part and make a new profile as needed. > About this bug, personally I dislike programs that does not offer you the > possibility to uninstall them completely. I said the same thing up top, but in a cost-benefit analysis it's not as important as avoiding dataloss, even if this only affects people who don't know what they're doing here and probably shouldn't have even installed a nightly.
Attached patch remove optionSplinter Review
Assignee: nobody → robert.strong.bugs
Attachment #415596 - Attachment is obsolete: true
Status: NEW → ASSIGNED
Attachment #8401564 - Flags: review?(netzen)
Attachment #8401564 - Flags: review?(netzen) → review+
Flags: in-testsuite-
Target Milestone: Future → Firefox 31
Status: ASSIGNED → RESOLVED
Closed: 12 years ago
Resolution: --- → FIXED
Verified on Windows 8 x64 and Windows 7 x64, using the latest Firefox 31 Beta 9 (BuildID: 20140710141843). Option to "Remove my Firefox personal data and customizations" shows in Firefox 30 and earlier, but NO longer shows in Firefox 31 Beta 9. Thus, the profiles are left intact and user can still use them with Firefox 32 Aurora, Firefox 33 Nightly, or older (already released) versions of Firefox, without any data loss.
Status: RESOLVED → VERIFIED
Keywords: verifyme
Depends on: 1180527
No longer depends on: 1180527
See Also: → 1644771
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Created:
Updated:
Size: