av9ash/GitBugs huggingface dataset:
Bug: implement reach for pbNewtab surface
Status: NEW
Priority: P3
Created: 2022-02-14 23:40:52+00:00
Resolved: 2024-03-21 15:26:02+00:00

Andrei, when we last talked about implementing reach telemetry for the pbNewtab private browsing surface, my understanding of your thoughts were that it would be redundant with other telemetry that we've already got, and that we shouldn't bother.  Can you unpack that a bit, either here or in https://docs.google.com/document/d/1wEQEXjcSZGE8VP5qLmfS9MRmbbLY02R_4Z8-TL8OG_I/edit#
.

I'm assuming we don't need this for the VPN 98 experiment, but if there's some reason we might, we should get it in right away so we can uplift.

Also, do we need to get a data scientist's thoughts here?
Bug: bookmarks are empty - all of them
Status: RESOLVED
Priority: --
Resolution: INCOMPLETE
Created: 2022-02-15 08:47:35+00:00
Resolved: 2022-03-12 14:05:45+00:00

User Agent: Mozilla/5.0 (X11; Fedora; Linux x86_64; rv:96.0) Gecko/20100101 Firefox/96.0

Steps to reproduce:

OS: Window 10
update to 97.0


Actual results:

no bookmarks are show in bookmarks tool / bar or elsewhere.

places.sqlite is filled with stuff, it's just not shown.
Recovering from booksmarksbackups folder is not working, with "the backupfile can't be processed"


Expected results:

list all bookmarks ofcourse ;)
Bug: could not apply userchrome.css rule on tab-icon-image
Status: RESOLVED
Priority: --
Resolution: INVALID
Created: 2022-02-15 09:37:47+00:00
Resolved: 2022-02-16 00:13:41+00:00

User Agent: Mozilla/5.0 (X11; Linux x86_64; rv:98.0) Gecko/20100101 Firefox/98.0

Steps to reproduce:

Version firefox 98.0b4

Add an userchrome.css rule for .tab-icon-image class e.g.

```
.tab-icon-image {
  display: none !important;
}
```
Additional note:

The same css rule worked before.
I guess it's broken after the following commit changed the element from <image> to <html:img>>
https://searchfox.org/mozilla-central/diff/488c7066edfaf7fc02b5c6e67e47b8b3945ee4f7/browser/base/content/tabbrowser-tab.js#21


Actual results:

css rule not applied


Expected results:

apply the rule
Bug: sync error
Status: RESOLVED
Priority: P3
Resolution: WONTFIX
Created: 2022-02-15 09:48:14+00:00
Resolved: 2022-11-10 16:33:41+00:00

User Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:98.0) Gecko/20100101 Firefox/98.0

Steps to reproduce:

Clicking on "sync now" (firefox pc). My account is valid (id and password) and everything is keeping working on my mobile device (firefox android).


Actual results:

Nothing. No sync process : I cannot sync neither my passwords nor my installed extensions...A bug report is generated on "about:sync-log" page...


Expected results:

Sync process : passwords, extensions...
Bug: Possible sleeping tab wake-up leading to high CPU and memory usage when sorting many (many) tabs
Status: UNCONFIRMED
Priority: --
Created: 2022-02-15 13:12:10+00:00
Resolved: 2024-07-10 09:47:16+00:00

User Agent: Mozilla/5.0 (X11; Ubuntu; Linux x86_64; rv:98.0) Gecko/20100101 Firefox/98.0

Steps to reproduce:

I discovered this bug while sorting tabs with two different add-ons (one of which is Mozilla's "Firefox Multi-Account Containers"), and I have already filed a bug in their repositories:

https://github.com/mozilla/multi-account-containers/issues/2289

But, I have reason to think that this is an "upstream" bug.

As I mentioned in the extension's repository's issue tracker, I had accumulated a bit more than 2000 open tabs (I thought it must've been around 200, but---after deduplication---OneTab reported 1994 tabs ... plus the 9 pinned ones I had).  I decided to tackle my tab problem by sorting the tabs first.


Actual results:

When sorting by container with Multi-Account Container, I noticed that there was a lot of intensive resource usage.  I even decided to take a couple of screenshots.

I think I may have interrupted the process by closing Firefox... but I think it had actually completed sorting by container.

However, when sorting with FoxyTab by ascending URL, I reached maximum memory and swap usage and had to do a hard reset.

I think tabs were being woken up (I do have `browser.tabs.unloadOnLowMemory` set to `true`) in order to be re-ordered.


Expected results:

Tabs shouldn't have needed to be woken up, and re-ordering tabs shouldn't have required a lot of memory and CPU.
Bug: PDF pictures is showing black
Status: VERIFIED
Priority: P1
Resolution: FIXED
Created: 2022-02-15 16:05:27+00:00
Resolved: 2022-04-07 19:41:59+00:00

User Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:97.0) Gecko/20100101 Firefox/97.0

Steps to reproduce:

I tried to open PDF file here:
https://curriculum.harmonytx.org/WebShare/Math/Curriculum/Geometry/1o_u-IgNsIkr7j8P3jH-lJjnHhIMeqYPSmXgDeAg9VHyFlNJMK3MfrexOvdXWoxQ16oDkTV3RoPAXM9wzE-_rp47Yl9lejsPuEkb4cq8W8TNV9q/Homework_Helper/12-1.pdf#page=2


Actual results:

The pictures won't show properly.


Expected results:

You can compare how it show in Chrome and Firefox in the attached image.
Bug: Back not working
Status: UNCONFIRMED
Priority: --
Created: 2022-02-15 16:06:22+00:00
Resolved: 2023-06-20 12:55:31+00:00

User Agent: Mozilla/5.0 (X11; Linux x86_64; rv:99.0) Gecko/20100101 Firefox/99.0

Steps to reproduce:

OS: Void Linux

- Firefox open and used for hours
- I left the house for a few hours
- Came back (my PC was asleep, so I woke it up, but Firefox was still running and not closed)
- I continued to use Firefox for a bit
- I opened youtube, searched, click on a video (currently that window history should be - about:blank, youtube.com, some video)
- I closed that window
- A few seconds later a pressed Ctrl+Shift+N to open the recently closed window
- Pressing back button or mouse back seems to 'refresh' the page and does not go back to youtube.com, but is stuck on the video

I don't think the "open closed window" has anything to do with this because I have had this happen for a while like this issue and my dupe. Sometimes a page refresh/F5 will allow back to work, sometimes not. Not sold on sleep mattering either but other issues I've seen mentioned they thought sleep may be involved.

Maybe something else to note? Most likely just extra info. When I open a new window I use my window manager's hotkeys, which runs `firefox-bin`, not Ctrl+N. Not sure if there's some weirdness in that.

Dont have the video I clicked on, but it has happened on multiple sites

Possible related bugs

my original - https://bugzilla.mozilla.org/show_bug.cgi?id=1728842

https://bugzilla.mozilla.org/show_bug.cgi?id=1729545

https://bugzilla.mozilla.org/show_bug.cgi?id=1729532

tldr - press back


Actual results:

page 'refreshes' (as if it is loaded instead of the actual previous page)

Reloading the page or pressing F5, or going forward and then back again _MAY_ allow for back to work as expected


Expected results:

Page goes back to proper page in history.
Bug: Blob urls for PDFs not immediately revoked after downloading/saving PDFs
Status: NEW
Priority: P3
Created: 2022-02-15 16:07:51+00:00
Resolved: 2022-03-22 10:16:06+00:00

See Jonas' comment in https://phabricator.services.mozilla.com/D138607#4517768.

:Gijs, should this block setting the pref to true? Should I mark this as blocking bug 1733587 or bug 1744297?
Bug: Firefox in KDE Plasma as default application
Status: RESOLVED
Priority: --
Resolution: WORKSFORME
Created: 2022-02-16 10:54:35+00:00
Resolved: 2022-09-26 14:44:39+00:00

```
Operating System: Arch Linux
KDE Plasma Version: 5.24.0
KDE Frameworks Version: 5.91.0
Qt Version: 5.15.2
Graphics Platform: X11
```
Click `make default` in Firefox settings.
Select *Firefox* in KDE Plasma settings → Applications → Default applications.

```
$ xdg-settings get default-web-browser
firefox.desktop
```
But Firefox still does not detect that it is the default browser.
![Firefox settings](https://imgur.com/9A9EoOL.png)
Bug: Delete Download availability
Status: RESOLVED
Priority: P2
Resolution: FIXED
Created: 2022-02-16 15:30:40+00:00
Resolved: 2022-03-17 13:39:48+00:00

**Affected versions**
* Firefox 98 beta 4 
* Nightly 99.0a1

**Affected platforms**
* all

**Steps to reproduce**
1. Download a small file from [link](https://archive.mozilla.org/pub/firefox/candidates/98.0b4-candidates/build1/win64/en-US/)
2. Wait for the download to complete, then right click and delete.
3. Download a bigger file [link](https://archive.mozilla.org/pub/firefox/candidates/98.0b4-candidates/build1/win64/en-US/)
4. While downloading, cancel the download, then right click and delete.
5. Download a bigger file [link](https://archive.mozilla.org/pub/firefox/candidates/98.0b4-candidates/build1/win64/en-US/)
6. While downloading, pause the download, then right click and delete.
7. On one of the above deleted downloads, right click and delete.


**Expected result**
2. Download is deleted, the download panel states that successfully - see enh. [File deleted from Downloads Panel contextual menu should have a different UI from the one deleted from disk](https://bugzilla.mozilla.org/show_bug.cgi?id=1755570)
4. Delete is not available.
6. Download is deleted, the download panel states that successfully - see enh. [File deleted from Downloads Panel contextual menu should have a different UI from the one deleted from disk](https://bugzilla.mozilla.org/show_bug.cgi?id=1755570)
7. Delete is not available for already deleted (file missing/moved) downloads.

**Actual result**
2. `File moved or missing` is displayed under the file name, same as when the file is removed from disk (see [bug 1755570](https://bugzilla.mozilla.org/show_bug.cgi?id=1755570)).
4. Nothing happens, delete option shouldn’t be available in this case.
6. Download is paused with this scenario, resume won’t work. -> Logging this separately since maybe we might want to have a retry for a deleted download ?!?
7. Nothing happens, delete option shouldn’t be available in this cases.

**Regression range**
* Not a regression
Bug: Resume/Retry doesn’t work in case of deleted inprogress downloads
Status: VERIFIED
Priority: P2
Resolution: FIXED
Created: 2022-02-16 15:32:53+00:00
Resolved: 2022-04-20 14:37:20+00:00

**Note**
* Not sure if we want to have a retry available for a deleted download, but in case we don’t then fixing bug 1755728, automatically removes the scenario causing this one.

**Affected versions**
* Firefox 98 beta 4 
* Nightly 99.0a1

**Affected platforms**
* all

**Steps to reproduce**
1. Download a big file [link](https://archive.mozilla.org/pub/firefox/candidates/98.0b4-candidates/build1/win64/en-US/)
2. While downloading, right click and delete.
3. Download is set into a pause state, proceed to delete again or just cancel.
4. Retry download.


**Expected result**

2. Download is deleted, the download panel states that successfully - see enh. [File deleted from Downloads Panel contextual menu should have a different UI from the one deleted from disk](https://bugzilla.mozilla.org/show_bug.cgi?id=1755570)
3. This case is not hit.
.4 Download is restarted.

**Actual result**
 2. Download is paused
3. Download is deleted (canceled)
4. Retry doesn’t work.


**Regression range**
* Although this is a narrow edge case to reach in, this regresses the retry download.
Bug: Search Engine Removal Info bar is showing up when default engine is unchanged
Status: RESOLVED
Priority: P1
Resolution: FIXED
Created: 2022-02-16 17:06:33+00:00
Resolved: 2022-02-25 14:48:23+00:00

A Nightly user has reported the removal of search engine info bar shows up when their default engine is still duck duck go. 
Ddg was still working as the user's default search engine. 

Questions 
1. Was it on startup or whilst FF was already running?
The infobar appeared on browser startup after a new version had been installed.

2. Is it reproducible?
Yes. This was reproducible on engineering side. The bug is caused by a race condition, sometimes the `add-on manager` would start up after the `Search Service` initialization. However, `add-on manager` should start up **before** the `Search Service` initialization. That's why we see this bug sometimes but not all the time due to the race condition. 

In order to reproduce this on the engineering side, we had to modify the code and force `add-on manager` start up after Search Service initialization. When `add-on manager` started after the search service initialization, we will see the infobar appear. 

More information on the logs and race condition can seen in Bug 1691706.
Bug: The tab title isn't always updated when loading a local file
Status: NEW
Priority: --
Created: 2022-02-16 17:12:23+00:00
Resolved: 2022-03-03 12:11:23+00:00

STR:
1. Go to bug https://bugzilla.mozilla.org/show_bug.cgi?id=1755498
2. Save locally the attachment.
3. Open the attachment in a new tab (with ctrl + click)
4. Open the attachment as a file

=> the tab title should be updated to a file:// URL but instead the previous URL is still displayed.

I tried variations of this STR (like opening the attachment in the same window, or opening it directly) but the bug wouldn't happen in that case.
Bug: Intermittent browser/components/places/tests/browser/interactions/browser_interactions_typing_dom_history.js | Should have saved the keypresses into the database - 87 == 88 - JS frame :: chrome://mochitests/content/browser/browser/components/places/tests
Status: RESOLVED
Priority: P5
Resolution: INVALID
Created: 2022-02-16 19:43:34+00:00
Resolved: 2022-02-21 06:32:35+00:00

**Filed by:** abutkovits [at] mozilla.com
**Parsed log:** https://treeherder.mozilla.org/logviewer?job_id=368119021&repo=autoland
**Full log:** https://firefox-ci-tc.services.mozilla.com/api/queue/v1/task/ME1oGNy4SWuAj-JlTv1Bmw/runs/0/artifacts/public/logs/live_backing.log

---
```
[task 2022-02-16T19:17:38.585Z] 19:17:38     INFO - TEST-PASS | browser/components/places/tests/browser/interactions/browser_interactions_typing_dom_history.js | Should have saved the page into the database - "https://example.com/browser/browser/components/places/tests/browser/keyword_form.html" == "https://example.com/browser/browser/components/places/tests/browser/keyword_form.html" - 
[task 2022-02-16T19:17:38.586Z] 19:17:38     INFO - Buffered messages finished
[task 2022-02-16T19:17:38.588Z] 19:17:38     INFO - TEST-UNEXPECTED-FAIL | browser/components/places/tests/browser/interactions/browser_interactions_typing_dom_history.js | Should have saved the keypresses into the database - 87 == 88 - JS frame :: chrome://mochitests/content/browser/browser/components/places/tests/browser/interactions/head.js :: assertDatabaseValues :: line 107
[task 2022-02-16T19:17:38.589Z] 19:17:38     INFO - Stack trace:
[task 2022-02-16T19:17:38.590Z] 19:17:38     INFO - chrome://mochitests/content/browser/browser/components/places/tests/browser/interactions/head.js:assertDatabaseValues:107
[task 2022-02-16T19:17:38.592Z] 19:17:38     INFO - TEST-PASS | browser/components/places/tests/browser/interactions/browser_interactions_typing_dom_history.js | Should have stored at least this amount of typing time. - 388 > 0 - 
```
Bug: Intermittent browser/components/sessionstore/test/browser_ignore_updates_crashed_tabs.js | Test timed out -
Status: RESOLVED
Priority: P5
Resolution: DUPLICATE
Created: 2022-02-17 08:01:21+00:00
Resolved: 2022-07-26 22:18:02+00:00

**Filed by:** ctuns [at] mozilla.com
**Parsed log:** https://treeherder.mozilla.org/logviewer?job_id=368198491&repo=autoland
**Full log:** https://firefox-ci-tc.services.mozilla.com/api/queue/v1/task/Zl7JpM9LTCatDYmY8-XxOA/runs/0/artifacts/public/logs/live_backing.log

---
```
[task 2022-02-17T07:15:12.976Z] 07:15:12     INFO - TEST-PASS | browser/components/sessionstore/test/browser_ignore_updates_crashed_tabs.js | browser is not in the crashed set - 
[task 2022-02-17T07:15:12.976Z] 07:15:12     INFO - Console message: [JavaScript Error: "remote browser crashed while on https://example.com/
[task 2022-02-17T07:15:12.976Z] 07:15:12     INFO - " {file: "chrome://mochikit/content/mochitest-e10s-utils.js" line: 10}]
[task 2022-02-17T07:15:12.976Z] 07:15:12     INFO - e10s_init/<@chrome://mochikit/content/mochitest-e10s-utils.js:10:10
[task 2022-02-17T07:15:12.976Z] 07:15:12     INFO - 
[task 2022-02-17T07:15:12.978Z] 07:15:12     INFO - Console message: [JavaScript Error: "NS_ERROR_NOT_AVAILABLE: Component returned failure code: 0x80040111 (NS_ERROR_NOT_AVAILABLE) [nsIPropertyBag2.getPropertyAsAString]" {file: "resource://testing-common/BrowserTestUtils.jsm" line: 1871}]
[task 2022-02-17T07:15:12.978Z] 07:15:12     INFO - observer@resource://testing-common/BrowserTestUtils.jsm:1871:28
[task 2022-02-17T07:15:12.978Z] 07:15:12     INFO - 
[task 2022-02-17T07:15:12.978Z] 07:15:12     INFO - Buffered messages finished
[task 2022-02-17T07:15:12.979Z] 07:15:12     INFO - TEST-UNEXPECTED-FAIL | browser/components/sessionstore/test/browser_ignore_updates_crashed_tabs.js | Test timed out - 
[task 2022-02-17T07:15:12.979Z] 07:15:12     INFO - GECKO(3456) | MEMORY STAT | vsize 2112671MB | vsizeMaxContiguous 66433416MB | residentFast 331MB | heapAllocated 94MB
[task 2022-02-17T07:15:12.980Z] 07:15:12     INFO - TEST-OK | browser/components/sessionstore/test/browser_ignore_updates_crashed_tabs.js | took 45067ms
[task 2022-02-17T07:15:12.981Z] 07:15:12     INFO - Not taking screenshot here: see the one that was previously logged
[task 2022-02-17T07:15:12.981Z] 07:15:12     INFO - TEST-UNEXPECTED-FAIL | browser/components/sessionstore/test/browser_ignore_updates_crashed_tabs.js | Found a tab after previous test timed out: https://example.com/ - 
[task 2022-02-17T07:15:12.982Z] 07:15:12     INFO - checking window state
[task 2022-02-17T07:15:12.982Z] 07:15:12     INFO - TEST-START | browser/components/sessionstore/test/browser_merge_closed_tabs.js
```
Bug: focus is NOT set when an element with the autofocus attribute is inserted into the document
Status: RESOLVED
Priority: --
Resolution: DUPLICATE
Created: 2022-02-17 10:27:00+00:00
Resolved: 2022-02-17 10:47:20+00:00

User Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10_15_7) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/98.0.4758.87 Safari/537.36

Steps to reproduce:

Consider the attached snippet, the autofocus attribute of the inserted input should cause the .

Motivation: better accessibility for alerts and SPAs


Actual results:

Firefox does not set focus to the new element.


Expected results:

Safari, Chrome, Edge are all setting focus to the added element.

Therefore Firefox should also set focus to the added element.
Bug: Crash when sending tab to a different device
Status: RESOLVED
Priority: --
Resolution: WORKSFORME
Created: 2022-02-17 12:23:13+00:00
Resolved: 2022-02-23 12:18:09+00:00

User Agent: Mozilla/5.0 (X11; Linux x86_64; rv:97.0) Gecko/20100101 Firefox/97.0

Steps to reproduce:

Right click on tab, "Send Tab to Device", then choose any of other available devices.
Sometimes it sends without crash, but after repeating 2-3 times it crashes.
Ubuntu 21.10 (Wayland) as host OS (If that's important), tab sending function was working perfectly at Firefox 96 (previous release).


Actual results:

Firefox forcefully closes itself.


Expected results:

Firefox should send tab to a different device and not to crash.
Bug: Domain group builder can incorrectly clear URLs in a group if update runs before rebuild
Status: RESOLVED
Priority: P2
Resolution: FIXED
Created: 2022-02-17 13:57:00+00:00
Resolved: 2022-02-18 21:57:01+00:00

Domain groups are incorrectly querying the current list of snapshots stored in the database. As a result the incremental update is broken if they haven't been rebuilt since restart.
Bug: Different default actions for xml/svg for improvements on/off depends on FX version starting point
Status: NEW
Priority: P5
Created: 2022-02-17 15:16:43+00:00
Resolved: 2023-03-31 14:01:17+00:00

(In reply to :Gijs (away until Feb 21; he/him) from comment #22)

> Expected (post-patch): we should save to disk by default (with the improvements pref on; with it off, a dialog will show up with the "save to disk" item pre-selected)

a. For the main update path Fx 97(-- bug 1753004) to Fx 99(++ bug 1753004), the default action for svg/xml will be and remain save, regardless of the value of the improve preference. 
b. If the update path is done starting from Firefox version that already contains bug 1753004, the default actions will be correctly switched betwen save - improvements pref on and ask - improvements pref off.

 Looking at the handler.json differences betwen Fx97 and Fx99 (or containing bug 175300), the handler.json created in Fx99 (or containing bug 175300) doesn't have entries for xml/svg, while the Fx97(or version which does not contain bug 175300) has entries for xml/svg, which implies that we do the default action switch based on improvements preference for svg/xml from code in absence of said entries, which won't be able to with the main update path(97->98) we're going to have once Fx98 graduates to release, since all Fx97 will have values for xml/svg.
Bug: make https the default protocol
Status: RESOLVED
Priority: --
Resolution: DUPLICATE
Created: 2022-02-17 15:39:51+00:00
Resolved: 2022-03-09 17:09:57+00:00

User Agent: Mozilla/5.0 (X11; Linux x86_64) AppleWebKit/605.1.15 (KHTML, like Gecko) Version/15.0 Safari/605.1.15

Steps to reproduce:

If the user enters a web address manually without explicitly stating the protocol Firefox should default to https rather than http. Today most websites redirect from http to https for this reason. However this just hides the security issue. The http redirect response could be spoofed and so that the user continues to use insecure http. 99% of users won´t even notice that. If a website does really offer different content for http and https the user can still enter the desired protocol manually.
  In deed it is an issue that most shared hosting providers have started to force customers into a http->https redirect even if that does not make sense for various reasons:
  * XML processing like schema validation and XML includes do still require http as the XML standard does not know https
  * Downloads should function with http rather than https. This does not only save valuable resources and improves the cachability of downloads but it also even can improve security: Downloads are normally verified with SHA-256/512 sums or GnuPG signatures so https only is an overload. More than this possible programming mistakes in the https/SSL layer can pose a security threat.
  * Sometimes https is not required and http adds a simpler alternative also supported by legacy systems. If the https certificate is currently invalid then also http can provide a reasonable alternative
  If providers of web browser defaulted to https rather than http then there was no reason to force a redirection of http to https, so that web site maintainers still can keep their choice on a file per file basis which protocols to support.
Bug: Timestamp from the export login feature is unreadable
Status: RESOLVED
Priority: --
Resolution: FIXED
Created: 2022-02-18 06:01:56+00:00
Resolved: 2022-02-18 13:04:57+00:00

Mozilla/5.0 (Macintosh; Intel Mac OS X 10.15; rv:97.0) Gecko/20100101 Firefox/97.0

Steps to reproduce:
When we export login data into csv file, the timestamp data is not readable. 

Initial report: https://support.mozilla.org/en-US/kb/export-login-data-firefox/discuss/10423
Bug: Firefox Developer fails to upgrade with the command "winget upgrade --id Mozilla.Firefox.DeveloperEdition"
Status: RESOLVED
Priority: --
Resolution: INVALID
Created: 2022-02-18 07:04:04+00:00
Resolved: 2022-02-18 18:15:38+00:00

Steps:
Try to upgrade Firefox Developer with this command in a cmd.exe window:

winget upgrade --id Mozilla.Firefox.DeveloperEdition

Actual result:
The upgrade fails per the log attached.

Expected result:
The upgrade succeeds.
Bug: Firefox Developer fails to uninstall with the command "winget uninstall --id Mozilla.Firefox.DeveloperEdition  --verbose-logs"
Status: RESOLVED
Priority: --
Resolution: INVALID
Created: 2022-02-18 07:11:13+00:00
Resolved: 2022-02-18 16:36:26+00:00

Steps:
Try to uninstall Firefox Developer with this command in a cmd.exe window:

winget uninstall --id Mozilla.Firefox.DeveloperEdition  --verbose-logs

Actual result:
The uninstall process stalls per the log attached.

Expected result:
The uninstall succeeds.