FF 15.0 to 15.0.1 Internal Update adds extra Uninstall Entry in Windows 7 Programs and Features

VERIFIED FIXED in Firefox 16

Status

()

Toolkit
Application Update
VERIFIED FIXED
5 years ago
5 years ago

People

(Reporter: MarkRH, Assigned: bbondy)

Tracking

({regression, verifyme})

15 Branch
mozilla18
x86_64
Windows 7
regression, verifyme
Points:
---
Dependency tree / graph
Bug Flags:
in-testsuite ?

Firefox Tracking Flags

(firefox15- wontfix, firefox16+ verified, firefox17 verified, firefox18 verified)

Details

Attachments

(2 attachments, 1 obsolete attachment)

(Reporter)

Description

5 years ago
User Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:15.0) Gecko/20100101 Firefox/15.0.1
Build ID: 20120905151427

Steps to reproduce:

Updated Firefox 15.0 to 15.0.1 using the internal updater via Help > About Firefox.


Actual results:

I looked at Windows 7 Pro 64bit's Programs and Features list and notice an entry for Firefox 15.0 and Firefox 15.0.1. I went searching in the registry and found the following:

FF 15.0.1 Uninstall information was stored here:
HKEY_CURRENT_USER\Software\Microsoft\Windows\CurrentVersion\Uninstall\Mozilla Firefox 15.0.1 (x86 en-US)

FF 15.0 Uninstall information was stored here:

HKEY_LOCAL_MACHINE\SOFTWARE\Wow6432Node\Microsoft\Windows\CurrentVersion\Uninstall\Mozilla Firefox 15.0 (x86 en-US)

Wonder if it's related to the Mozilla Maintenance Service thing. Almost like FF 15.0.1 was handled like a User only install.

Following is a MozillaZine topic about it: http://forums.mozillazine.org/viewtopic.php?f=38&t=2538425


Expected results:

It should have replaced the original registry entry such that only a single item is listed in the Programs and Features list of Windows 7.
Component: Untriaged → Application Update
Keywords: qawanted
Product: Firefox → Toolkit

Comment 1

5 years ago
Just thought I'd confirm I've encountered the same issue in Windows 8 Release Preview x64 and Windows 7 x86. The registry situation is the same in 8, can't check 7 anymore since I uninstalled both entries and reinstalled via manual download.

My Firefox on Win8 updated itself in the background with no manual update check, if that helps rule anything out.

Uninstall entries for Firefox Beta and Aurora have also moved to the current user registry branch (Aurora has left behind a duplicate, Beta was on 15.0 so the entry was overwritten when stable updated to 15.0). SeaMonkey stable/beta/aurora has remained in the local machine WoW64 branch, supporting the theory that the new maintenance service has started doing something different (at least, SeaMonkey doesn't appear to use the service).
Will and Mark, would you mind to check what happens when you upgrade from Firefox 14.0.1 to Firefox 15.0.1? Does it also happen in such a case?
Keywords: regression, regressionwindow-wanted

Comment 3

5 years ago
I've just completed a few experiments on the Windows 7 x86 machine I mentioned above whilst observing the registry for uninstall entries.

- 15.0.1 clean install: normal
- 14.0.1 clean install -> 15.0.1 about-box update: normal
- 14.0.1 clean install -> 15.0.1 installer update: normal
- 14.0.1 clean install -> 15.0 installer update -> 15.0.1 about-box update: duplicate
- 14.0.1 clean install -> 15.0 installer update -> 15.0.1 installer update: normal (but I was forced to reboot the computer after the 15.0.1 update on both occasions that I attempted this particular update sequence)

The "normal" results in all cases mean that at the end a single uninstall entry for Firefox was present in the local machine branch of the registry (alongside the entry for the maintenance service). The "duplicate" result is the one originally reported, an entry for 15.0 remains in the normal local machine branch and a new entry for 15.0.1 appears in the current user branch.

Comment 4

5 years ago
I don't know if it's any help but of those two uninstall entries, one triggered an UAC prompt, while the other brought up the uninstaller without a prompt.
(Reporter)

Comment 5

5 years ago
Here's some other info. The 15.0.1 Upgrade I did also added all this to the registry:

Windows Registry Editor Version 5.00

[HKEY_CURRENT_USER\Software\Mozilla]

[HKEY_CURRENT_USER\Software\Mozilla\Firefox]

[HKEY_CURRENT_USER\Software\Mozilla\Firefox\Crash Reporter]
"Email"=""
"IncludeURL"=dword:00000001
"EmailMe"=dword:00000000
"SubmitCrashReport"=dword:00000001

[HKEY_CURRENT_USER\Software\Mozilla\Mozilla Firefox]
@="15.0.1"
"CurrentVersion"="15.0.1 (en-US)"

[HKEY_CURRENT_USER\Software\Mozilla\Mozilla Firefox\15.0.1 (en-US)]
@="15.0.1 (en-US)"

[HKEY_CURRENT_USER\Software\Mozilla\Mozilla Firefox\15.0.1 (en-US)\Main]
"Install Directory"="C:\\Program Files (x86)\\Mozilla Firefox"
"PathToExe"="C:\\Program Files (x86)\\Mozilla Firefox\\firefox.exe"

[HKEY_CURRENT_USER\Software\Mozilla\Mozilla Firefox\15.0.1 (en-US)\Uninstall]
"Description"="Mozilla Firefox 15.0.1 (x86 en-US)"

[HKEY_CURRENT_USER\Software\Mozilla\Mozilla Firefox 15.0.1]
"GeckoVer"="15.0.1"

[HKEY_CURRENT_USER\Software\Mozilla\Mozilla Firefox 15.0.1\bin]
"PathToExe"="C:\\Program Files (x86)\\Mozilla Firefox\\firefox.exe"

[HKEY_CURRENT_USER\Software\Mozilla\Mozilla Firefox 15.0.1\extensions]
"Components"="C:\\Program Files (x86)\\Mozilla Firefox\\components"
"Plugins"="C:\\Program Files (x86)\\Mozilla Firefox\\plugins"


The Firefox 15.0 counterpart is still here:

Windows Registry Editor Version 5.00

[HKEY_LOCAL_MACHINE\SOFTWARE\Wow6432Node\Mozilla]

[HKEY_LOCAL_MACHINE\SOFTWARE\Wow6432Node\Mozilla\Firefox]

[HKEY_LOCAL_MACHINE\SOFTWARE\Wow6432Node\Mozilla\Firefox\Extensions]
"{22119944-ED35-4ab1-910B-E619EA06A115}"="C:\\Program Files (x86)\\Siber Systems\\AI RoboForm\\Firefox"

[HKEY_LOCAL_MACHINE\SOFTWARE\Wow6432Node\Mozilla\Firefox\TaskBarIDs]
"C:\\Program Files (x86)\\Mozilla Firefox"="E7CF176E110C211B"

[HKEY_LOCAL_MACHINE\SOFTWARE\Wow6432Node\Mozilla\Mozilla Firefox]
@="15.0"
"CurrentVersion"="15.0 (en-US)"

[HKEY_LOCAL_MACHINE\SOFTWARE\Wow6432Node\Mozilla\Mozilla Firefox\15.0 (en-US)]
@="15.0 (en-US)"

[HKEY_LOCAL_MACHINE\SOFTWARE\Wow6432Node\Mozilla\Mozilla Firefox\15.0 (en-US)\Main]
"Install Directory"="C:\\Program Files (x86)\\Mozilla Firefox"
"PathToExe"="C:\\Program Files (x86)\\Mozilla Firefox\\firefox.exe"

[HKEY_LOCAL_MACHINE\SOFTWARE\Wow6432Node\Mozilla\Mozilla Firefox\15.0 (en-US)\Uninstall]
"Description"="Mozilla Firefox 15.0 (x86 en-US)"

[HKEY_LOCAL_MACHINE\SOFTWARE\Wow6432Node\Mozilla\Mozilla Firefox 15.0]
"GeckoVer"="15.0"

[HKEY_LOCAL_MACHINE\SOFTWARE\Wow6432Node\Mozilla\Mozilla Firefox 15.0\bin]
"PathToExe"="C:\\Program Files (x86)\\Mozilla Firefox\\firefox.exe"

[HKEY_LOCAL_MACHINE\SOFTWARE\Wow6432Node\Mozilla\Mozilla Firefox 15.0\extensions]
"Components"="C:\\Program Files (x86)\\Mozilla Firefox\\components"
"Plugins"="C:\\Program Files (x86)\\Mozilla Firefox\\plugins"

So, there's more than just the Uninstall key that's duplicated/added to the Current User tree. I haven't tried various install/upgrade methods to see how the registry entries compare yet. Sort of curious what happens with the next upgrade if I just left it as is.
(In reply to Will Elwood (:Will) from comment #3)
> - 14.0.1 clean install -> 15.0 installer update -> 15.0.1 about-box update:
> duplicate

So can you just replicate this by installing 15.0 and updating through the about window? Means without having to install 14.0.1 first.
Duplicate of this bug: 790081
Status: UNCONFIRMED → NEW
Ever confirmed: true

Comment 8

5 years ago
(In reply to Henrik Skupin (:whimboo) from comment #6)
> So can you just replicate this by installing 15.0 and updating through the
> about window? Means without having to install 14.0.1 first.

I have done this and the result is the same: FF 15.0 and FF 15.0.1 are both listed.
Those are the changes between 15.0 and 15.0.1:
http://hg.mozilla.org/releases/mozilla-release/pushloghtml?fromchange=450143d2d810&tochange=0b774a1067fe

None of them have anything to do with the updater. So I wonder why that happens for 15.0->15.0.1. 

Could anyone please try if this is reproducible when upgrading 16.0b1 to 16.0b2? the 16.0b1 builds can be found here:

ftp://ftp.mozilla.org/pub/firefox/releases/16.0b1/
tracking-firefox15: --- → ?
> None of them have anything to do with the updater. So I wonder why that happens for 15.0->15.0.1.
14.0 -> 15.0 update will be performed by 14.0 updater.
15.0 -> 15.0.1 update will be performed by 15.0 updater.
So changes between 14.0 and 15.0 would have the regression.
Oh, right. Good catch! So here the updated pushlog (it will take a long time to load!):

hg.mozilla.org/releases/mozilla-release/pushloghtml?fromchange=e5728a4e106c&tochange=450143d2d810

So could someone please test individual 15.0 beta releases so that we can figure out which of those shows the issue first?
tracking-firefox16: --- → ?

Comment 12

5 years ago
(In reply to Henrik Skupin (:whimboo) from comment #9)
> 
> Could anyone please try if this is reproducible when upgrading 16.0b1 to
> 16.0b2? the 16.0b1 builds can be found here:
> 
> ftp://ftp.mozilla.org/pub/firefox/releases/16.0b1/

I did (removed 15 and double listing also first) and there is no double listing now, however: FF 16.0b1 and FF 16.0b2 have the same name in the Windows 7 Programs and Features list: Mozilla Firefox 16.0 (FF15 has different entry names: 15.0 vs 15.0.1)
tracking-firefox16: ? → ---

Comment 13

5 years ago
(In reply to Henrik Skupin (:whimboo) from comment #11)

> So could someone please test individual 15.0 beta releases so that we can
> figure out which of those shows the issue first?

Beta-versions have the same name in the Win7 "Program list", maybe that's why the bug didn't show up?
So I think that this issue is related to the background updates implemented on bug 307181 for Firefox 15. CC'ing Ehsan who mostly did all the work. He probably knows better which of the patches could have caused it. 

But given the helpful information from Mark on comment 5, it really looks like a dupe of bug 773077 now.
Flags: in-testsuite?

Comment 15

5 years ago
I am seeing the following in my "Uninstall or change a program" control panel in Windows 7 Professional 64 bit (Microsoft Windows Version 6.1 (Build 7601: Service Pack 1):


Aurora 16.0a2
Aurora 17.0a2

Also "Mozilla Maintenance Service" (What the heck is this one?).
Brian, do you have time to investigate this?
(Assignee)

Comment 17

5 years ago
(In reply to Ehsan Akhgari [:ehsan] from comment #16)
> Brian, do you have time to investigate this?

Not really, as we have a Metro preview due at the end of this month and I'll be reviewing the stub installer once it's ready.  But I may have to if no one else picks it up:)

Worcester12345 have you installed 2 versions of Aurora in the past? 
The Mozilla Maintenance Service is normal and is for silent updates without a UAC prompt.  It is an optional component.
(Reporter)

Comment 18

5 years ago
Here's some more information. I uninstalled FF 15.0 (kept my settings) and then made sure the extra registry entries were gone. I then installed 15.0 again along with Maintenance Service.  I then went into Tools > Options > Advanced > Update and unchecked the option to "Use a background service to install updates". 

I then went into Help > About Firefox and clicked the "Check for Updates" button. It found and transferred 15.0.1 and this time it prompted me with the UAC prompt asking permission and I granted it. This time I only have FF 15.0.1 listed in Programs. Other than the Crash Reporter part, everything is in HKLM now.

I do have Thunderbird 15.0.1 installed as well.. so some of the generic Mozilla entries could be from it.

So, this tells me it is definitely related to the update being performed by the Maintenance Service that suppresses the UAC prompt. Of course, changing entries in HKCU doesn't require the elevations that HKLM would.
(Assignee)

Comment 19

5 years ago
If anyone has time it would be helpful to know if this bug reproduces when app.update.stage.enabled is set to false.
(Assignee)

Comment 20

5 years ago
This can be set in about:config by the way.

Comment 21

5 years ago
(In reply to Brian R. Bondy [:bbondy] from comment #19)
> If anyone has time it would be helpful to know if this bug reproduces when
> app.update.stage.enabled is set to false.

Not reproducible by updating this way, now only FF 15.0.1 is listed.
(Assignee)

Comment 22

5 years ago
Thanks for the info, this helps narrow down the issue considerably.
Blocks: 307181
(Assignee)

Updated

5 years ago
Assignee: nobody → netzen
(Reporter)

Comment 23

5 years ago
(In reply to Brian R. Bondy [:bbondy] from comment #19)
> If anyone has time it would be helpful to know if this bug reproduces when
> app.update.stage.enabled is set to false.

FYI, when I did my update with the maintenance service disabled, this value was set to true and still is. My guess is app.update.service.enabled (set to false now) controls the Maintenance Service option.
(Assignee)

Comment 24

5 years ago
Thanks for the info MarkRH.  When the maintenance service is disabled it also disables background updates, so that's why you didn't see the issue with the service turned off.  In Comment 21 Coyote kept the service on but background updates off and Coyote could not reproduce the problem in that way.
It doesn't sound like this will warrant a new FF15 release, but we should track for including a fix in FF16.
tracking-firefox15: ? → -
tracking-firefox16: --- → +
(Assignee)

Comment 26

5 years ago
So to understand what the issue is....

For service updates we call PostUpdate from:
1) current user unelevated to get the HKCU user specific entries
2) the system account elevated to get the HKLM entries

When the update is not a bgupdate, there is no problem
When theupdate is a bgupdate the second call fails, leaving the last entries.

I noticed this in the log:
Launching post update process as the service in session 0.
***The post update process could not be launched.***

I haven't found the reason yet for why it can't be launched, but probably the path to helper.exe is being passed in wrong or something like that.
(Assignee)

Comment 27

5 years ago
Created attachment 660288 [details] [diff] [review]
Patch v1.

So the problem is that it's not executing the PostUpdate process when elevated, hence leaving the old uninstall entries. The reason it's not executing it is because it's trying to find helper.exe inside the /updated directory, but that is already moved out at this point. 

This error did show up in the logs of all channels btw, we just didn't notice it :(
Attachment #660288 - Flags: review?(ehsan)
(Assignee)

Updated

5 years ago
Keywords: regressionwindow-wanted
(Assignee)

Comment 28

5 years ago
I didn't test this yet btw, but I'll test on oak before pushing. I re-checked out oak for updater work since we have a few different updater tasks left (x64, limited user accounts, regressions, ...)
(Assignee)

Updated

5 years ago
Depends on: 790496
Comment on attachment 660288 [details] [diff] [review]
Patch v1.

Review of attachment 660288 [details] [diff] [review]:
-----------------------------------------------------------------

ouch!
Attachment #660288 - Flags: review?(ehsan) → review+
(Assignee)

Comment 30

5 years ago
Created attachment 660299 [details] [diff] [review]
Patch v2.

Noticed a missing comma, carrying forward r+
Attachment #660288 - Attachment is obsolete: true
Attachment #660299 - Flags: review+
Brian, is bug 773077 a dupe of this bug now? Or do we not fix the right registry keys usage with your patch?
(Assignee)

Comment 32

5 years ago
It looks like it's a dupe of bug 773077.  But we wrongly attributed that bug to bug 773077 Comment 13.  Since the patch is here already I'll mark that bug a dupe of this one.
(Assignee)

Updated

5 years ago
Duplicate of this bug: 773077
Assigning Juan as the QA contact for this bug. I want to make sure that we not only verify the fix, but also verify that the extra entry is removed.
QA Contact: jbecerra
(Assignee)

Comment 35

5 years ago
Sounds good, the fix should work for removing already affected users and ensure that future people won't be affected.
(Assignee)

Updated

5 years ago
Depends on: 790467
(Assignee)

Comment 36

5 years ago
Just wanted to mention that I don't feel comfortable landing this without testing it on Oak.  I've been trying to get Oak setup since Sept 11 but it is still pending. I would hate to see this not make beta, but it may come to that.
(Assignee)

Comment 37

5 years ago
The Oak setup bug is here: bug 790467
(Assignee)

Comment 38

5 years ago
Comment on attachment 660299 [details] [diff] [review]
Patch v2.

[Approval Request Comment]
Bug caused by (feature/regressing bug #): bug 307181 
User impact if declined: Users will have 2 uninstall entries with different versions, uninstalling either will uninstall Firefox.
Testing completed (on m-c, etc.): Tested silent updates with background updates and without on oak.  Both worked. Oak is a clone of m-c.  Landing directly on m-c now. 
Risk to taking this patch (and alternatives if risky): Low since testing was done
String or UUID changes made by this patch: none
Attachment #660299 - Flags: approval-mozilla-beta?
Attachment #660299 - Flags: approval-mozilla-aurora?
(Assignee)

Comment 39

5 years ago
http://hg.mozilla.org/mozilla-central/rev/abada9261f82
Status: NEW → RESOLVED
Last Resolved: 5 years ago
status-firefox18: --- → fixed
Resolution: --- → FIXED
Target Milestone: --- → mozilla18
(Assignee)

Updated

5 years ago
status-firefox16: --- → affected
status-firefox17: --- → affected
Since this is now fixed, swapping the qawanted keyword for verifyme to flag for verification.
Keywords: qawanted → verifyme
Comment on attachment 660299 [details] [diff] [review]
Patch v2.

[Triage Comment]
We believe this is a low risk fix for a top SUMO issue. Approving for Aurora/Beta uplift.
Attachment #660299 - Flags: approval-mozilla-beta?
Attachment #660299 - Flags: approval-mozilla-beta+
Attachment #660299 - Flags: approval-mozilla-aurora?
Attachment #660299 - Flags: approval-mozilla-aurora+
(Assignee)

Comment 42

5 years ago
http://hg.mozilla.org/releases/mozilla-aurora/rev/3ce58e4dd2a3
http://hg.mozilla.org/releases/mozilla-beta/rev/de5852044bfe
status-firefox15: --- → wontfix
status-firefox16: affected → fixed
status-firefox17: affected → fixed
I can reproduce this easily with Fx15.0 - 15.0.1, but I can't reproduce this with a nightly, beta or aurora prior to the fix having tried manual check for updates and also by waiting for it to download and apply in the background.

Let me know if there's another way to test this.
(Assignee)

Comment 44

5 years ago
I tested this by checking the c:\programdata\mozilla\logs, before they contained an error message as in comment 26.  A better way to test though would be to modify the HKLM and HKCU registry uninstall keys so that they differ.  Once they differ it will show 2 uninstall entries in your control panel.

Example location if you're on x64:
HKEY_LOCAL_MACHINE\SOFTWARE\Wow6432Node\Microsoft\Windows\CurrentVersion\Uninstall\Nightly
(Your location may differ).

You also need an equivalent HKCU entry.  The way to get both of them is to have an update occur through the service. 

After you have both entries you can reinstall the previous browser and update again. It should update both HKCU and HKLM registry locations.
Mozilla/5.0 (Windows NT 6.1; WOW64; rv:16.0) Gecko/20100101 Firefox/16.0

Verified by updating from Firefox 16 beta 5 to Firefox 16 beta 6 that the maintenanceservice.log does not contain the error message from Comment 26. 

"Launching post update process as the service in session 0.
updater.exe was launched and run successfully!"

Comment 46

5 years ago
Unfortunally FF15.0 still listed (with FF16); FF15.0.1 not listed.

Comment 47

5 years ago
Created attachment 669714 [details]
FF15.0 still listed with FF16

Sorry for double post, This is what I mean.
The fix landed for Firefox 16's release. I would expect that this will appear fixed with the first Firefox 16 update (ie. Firefox 17). In other words, when Firefox 16 updates to Firefox 17 in 6 weeks you will just have Firefox 17 in the Programs list. You might have to manually remove the Firefox 15 entry given that this is wontfix for Firefox 15.

Brian, please correct me if I am wrong.
Duplicate of this bug: 799568
(Assignee)

Comment 50

5 years ago
I think the problem that was suspected to have caused this was a fix in PostUpdate, which should run with the new code.  I'll re-open for now to investigate further.
Status: RESOLVED → REOPENED
Resolution: FIXED → ---
(Assignee)

Comment 51

5 years ago
Actually the problem was that PostUpdate wasn't running, but the place that executed the PostUpdate operation was inside the service, which would have been running old code.

So Anthony is correct that the next update should fix this.

It would be good for QA to verify though by manually staging the registry settings mentioned in bug 799568 to see if an update with the new service fixes it.

If we end up doing a chem spill it will also auto get fixed at that point.
Status: REOPENED → RESOLVED
Last Resolved: 5 years ago5 years ago
Resolution: --- → FIXED

Comment 52

5 years ago
Updated to FF 16.0.1 (from 16.0) and everything is fine now. This also is the case for Thunderbird: the error never occured there.
Thanks Coyote.
status-firefox16: fixed → verified

Comment 54

5 years ago
I am seeing this having just updated from 15 to 16.0.1. In control panel -> uninstall, firefox 15 is still listed along side 16.0.1; the registry contains the uninstall information for 16.0.1 under HKEY_CURRENT_USER rather than HKEY_LOCAL_MACHINE.

Comment 55

5 years ago
(In reply to sam morris from comment #54)
> I am seeing this having just updated from 15 to 16.0.1. In control panel ->
> uninstall, firefox 15 is still listed along side 16.0.1; the registry
> contains the uninstall information for 16.0.1 under HKEY_CURRENT_USER rather
> than HKEY_LOCAL_MACHINE.

Updating from 15 (to 16.0.1) occurs with the FF 15-updater. The bug was present in FF 15. The next update will happen with the FF 16-updater, the extra entry will remove itself during the update process.

What I did was updating from 15 to 16 and then again to 16.0.1. So the last update was with the FF 16-updater.

Comment 56

5 years ago
Got it. Sorry for the confusion.
(Assignee)

Comment 57

5 years ago
Based on Comment 52 marking this as verified.
Status: RESOLVED → VERIFIED
(Assignee)

Comment 58

5 years ago
Marking this back as Resolved since Verified is usually checked on the m-c branch.
Status: VERIFIED → RESOLVED
Last Resolved: 5 years ago5 years ago
(Assignee)

Comment 59

5 years ago
(In reply to Brian R. Bondy [:bbondy] from comment #58)
> Marking this back as Resolved since Verified is usually checked on the m-c
> branch.

.... err all branches that it lands on.
(Assignee)

Updated

5 years ago
Duplicate of this bug: 768378
Mozilla/5.0 (Windows NT 6.1; rv:17.0) Gecko/17.0 Firefox/17.0
Mozilla/5.0 (Windows NT 6.1; WOW64; rv:17.0) Gecko/17.0 Firefox/17.0

Verified that no extra Uninstall Entry is left after updating to Firefox 17 (in Windows 7 Programs and Features).

Verified by updating from:
- Firefox 17 beta 3 to Firefox 17 beta 6 - there is no error in the maintenanceservice.log as the one mentioned in Comment 26.
- Firefox 16.0.2 to Firefox 17 - there is no error in the maintenanceservice.log and no extra Uninstall entry in the Programs and Features list in Control Panel.

Verified as fixed on Windows 7 32-bit and Windows 7 64-bit.

Updated

5 years ago
status-firefox17: fixed → verified
Updating FF 18b4 to FF 18b5 works as expected. Based on this and on Comment 53 and Comment 60 I consider this issue Verified Fixed.
Status: RESOLVED → VERIFIED
status-firefox18: fixed → verified
You need to log in before you can comment on or make changes to this bug.