av9ash/GitBugs huggingface dataset:
Bug: WER Crash reporting for MSIX installs.
Status: NEW
Priority: --
Created: 2022-11-07 15:27:51+00:00
Resolved: 2024-07-03 18:53:32+00:00

It looks like we might not be getting any crash reports for our MSIX builds into our normal crash reporting infrastructure.
https://crash-stats.mozilla.org/search/?distribution_id=~msix

We do get at least some reports through "Partner Center", but we would have much more chance of catching MSIX related issues if everything was coming through the normal channel.

Idea from Slack (nalexander):
"Maybe we need to register our WER handler in https://searchfox.org/mozilla-central/source/browser/installer/windows/msix/AppxManifest.xml.in?"

The lack of WER handler registration might explain the lack of some reports, but it is not clear why the old-style internally caught crashes are not being reported.
Bug: The Star icon (“Bookmark this page/Edit this bookmark”) can’t be reached using keyboard navigation
Status: VERIFIED
Priority: --
Resolution: FIXED
Created: 2022-11-07 16:36:42+00:00
Resolved: 2023-06-02 15:23:50+00:00

**Found in**
* 108.0a1 (20221107094526)

**Affected versions**
* 108.0a1 (20221107094526)

**Affected platforms**
* Windows 10
* macOS 12
* Ubuntu 20.04

**Steps to reproduce**
1. Open any website
2. Using keyboard navigation (Tab, right/left arrow)  try to reach the Star icon button inside the search bar 

**Expected result**
* The star button can be reached and focused. 

**Actual result**
* The star button is skipped.

**Regression range**
* First bad: aa325161aae5e555cab4d44b6662bbe029d26a5d
* Last good:  4ff88d45f59c4357dcc71ddf4ad5344a38f9944d
* Pushlog: https://hg.mozilla.org/integration/autoland/pushloghtml?fromchange=4ff88d45f59c4357dcc71ddf4ad5344a38f9944d&tochange=aa325161aae5e555cab4d44b6662bbe029d26a5d
* Potentially regressed by: 1790616

**Additional notes**
* Screen reader navigation is also affected by this behavior
Bug: Restart to continue using firefox loses tabs (Session Restore doesn't save)
Status: NEW
Priority: --
Created: 2022-11-07 20:28:13+00:00
Resolved: 2022-11-09 22:21:20+00:00

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

Steps to reproduce:

Open two links in new tabs (in background)
Go to one of the new tabs.
See "Restart to continue using firefox"
Click restart.


Actual results:

After restart, the new tabs that were opened "which say restart to continue using firefox" are now blank tabs and have lost the URL


Expected results:

After restart, session restore should have saved the URLs (even though the tabs hadn't fully loaded) and restored them.

I believe this bug also affects tabs opened via "send tab to another device"
Bug: Hover states of Cancel and Copy buttons do not have enough contrast
Status: VERIFIED
Priority: P2
Resolution: FIXED
Created: 2022-11-07 21:27:58+00:00
Resolved: 2023-06-02 15:23:50+00:00

STR:
1. Set `screenshots.browser.component.enabled` to true
1. Navigate to https://bugzilla.mozilla.org/home (or any webpage)
1. Use keyboard shortcut (Ctrl + Shift + S) to take a screenshot
1. Hover over the Cancel and Copy buttons

Expected:
- I am able to visually determine a difference between the hovered and unhovered states

Actual:
- I am unable to determine any visual difference between the hovered and unhovered states

The default background color is currently #f9f9fa and the hovered color is #ededf0, which look near identical to me when the smaller button is 40px by 40px.
Bug: The Cancel, Copy, and Download buttons have no focus styling when taking a screenshot
Status: RESOLVED
Priority: P2
Resolution: WORKSFORME
Created: 2022-11-07 21:38:22+00:00
Resolved: 2023-12-05 23:40:12+00:00

I don't know if this will block enabling the component on Nightly or not, since I'm not sure if this is a valid case or not; but bugs are cheap.

STR:
1. Set `screenshots.browser.component.enabled` to true
2. Navigate to https://bugzilla.mozilla.org/home (or any webpage)
3. Use keyboard shortcut (Ctrl + Shift + S) to take a screenshot
4. Select a portion on screen with your mouse to bring up the Cancel, Copy, and Download buttons for this section

Expected:
- If I focus the Cancel, Copy, or Download buttons, I would expect styling similar to the hover state plus a focus outline

Actual:
- No change in visual display when focused, no focus outline appears.

I'm not sure how common this use case is, using both mouse and keyboard to take a screenshot. If we take a screenshot via the save visible/save full page buttons, then the buttons that appear have the correct styles when focused. In other words, I don't know how you would control the mouse pointer via keyboard input...I'm sure there is software to make this happen though. Like if you're controlling the pointer via keyboard, would focus states be a concern then? I'm not sure and I don't have a good answer to that question at the moment...but again, bugs are cheap so might as well have this on file.
Bug: i info button on Protections dialog does not work
Status: RESOLVED
Priority: P3
Resolution: WORKSFORME
Created: 2022-11-08 00:28:15+00:00
Resolved: 2024-03-25 17:36:30+00:00

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

Steps to reproduce:

start Fx
start a private window
browse to a location (in either window)
click the shield icon in the address bar (in either window)
click the "i" to the right of "Protections for bugzilla.mozilla.org"


Actual results:

Nothing happens.


Expected results:

The "Browse without being followed" panel should expand open.
Bug: Feature callout resize test broken due to not zooming
Status: RESOLVED
Priority: --
Resolution: DUPLICATE
Created: 2022-11-08 05:05:12+00:00
Resolved: 2022-11-09 23:39:18+00:00

The first task in [browser_feature_callout_resize.js](https://searchfox.org/mozilla-central/source/browser/components/firefoxview/tests/browser/browser_feature_callout_resize.js) set the zoom level and the other tasks depended on it. Bug 1792505 moved this task to another test, so the zoom level is not being set. We need to add zooming back to the resize test
Bug: edit bookmark dialog still clipped in 107 release
Status: VERIFIED
Priority: --
Resolution: FIXED
Created: 2022-11-08 08:17:39+00:00
Resolved: 2022-11-14 08:56:23+00:00

https://bugzilla.mozilla.org/show_bug.cgi?id=1795901
did not fix it properly.

The window is now a bit wider, but still clips a full button
Bug: Open previous windows and tabs is not working
Status: RESOLVED
Priority: --
Resolution: WORKSFORME
Created: 2022-11-08 09:28:57+00:00
Resolved: 2022-11-16 16:39:29+00:00

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

Steps to reproduce:

In settings the "Startup: Open previous windows and tabs" checkbox is checked.

Windows. 106.0.5 (64-bit). The problem is happening since 2 days or so.

Reproduce: Firefox, bunch of tabs open. Close window. Wait a few seconds (in case it takes a while for processes to terminate fully). Restart Firefox.


Actual results:

Firefox does not startup with all previous windows and tabs, but starts up with 1 blank tab.


Expected results:

Firefox should startup with all previous windows and tabs.
Bug: Downloading a PDF opens Firefox PDF Viewer instead of just downloading it, disregarding 'Always ask you where to save files'
Status: RESOLVED
Priority: --
Resolution: DUPLICATE
Created: 2022-11-08 09:39:19+00:00
Resolved: 2022-11-08 11:08:32+00:00

I know that I am creating a new report for a closed bug which technically is against the guidelines, however I accidentally confirmed the bug #1795874 as closed, which was a mistake on my part and I have not got any new feedback on the previous closed bug report.

I want to stress that I don't think that the current behavior of Firefox works as intended. Especially since having 'Open in Firefox' set for PDFs will disregard the 'Always ask you where to save files' for downloading a PDF. Furthermore, this disregards intended behavior of websites that serve a PDF file to be specifically downloaded (see example of original bug report below).

Also tested with FF Nightly 108.0a1, where this issue still persists.


+++ This bug was initially created as a clone of Bug #1795874 +++

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

Steps to reproduce:

This Bug was introduced in version 98.0 and still persists in current nightly build 107.0a1. This was tested in Fedora 36 with multiple Firefox Versions always with a clean profile with default settings.
Open Firefox and go to https://sogo-demo.de/SOGo/ (that was the easiest way for me to compare PDF preview and download behavior).
Login using the demo credentials.
Go to the 'Drafts' folder, the latest draft includes a PDF attachment.
There you can click on `View Attachment` and `Save Attachment`.


Actual results:

'View Attachment' works as intended, a new tab is opened containing the PDF in the default Firefox PDF Viewer.
However, clicking on 'Save Attachment', instantly starts downloading the PDF (disregarding the 'Always ask you where to save files' option) and opening the Firefox PDF Viewer.


Expected results:

'Save Attachment' should just download the PDF file as it would with any other file type, and it shouldn't show the PDF Viewer.
Bug: Customize mode gets jumbled up when trying to reduce the window size vertically (and to a lesser degree, horizontally)
Status: NEW
Priority: P3
Created: 2022-11-08 11:04:52+00:00
Resolved: 2022-11-22 12:11:52+00:00

This is effectively 2 issues:

1. when reducing the window **height**, the bottom toolbar in customize mode (with the title bar control, UI density, done / restore default button etc.) gets jumbled up with the content area. I'm not sure how to fix this - we probably don't want to increase the minimum size of the window at all times, as that would break web content, but we should ensure a slightly larger minimum size for customize mode.
2. when reducing the window **width**, we hit a [min-width of 450px](https://searchfox.org/mozilla-central/rev/b6d0ad6ba24b3d075e357e52160cd8fc7f911ba9/browser/base/content/browser.css#27), but at that point the overflow menu's representation in customize mode is already slightly cut off on the right hand side (on macOS, on current nightly, ymmv)
Bug: While dragging a normal tile into the second position, the Sponsored tile via Pocket changes its position
Status: VERIFIED
Priority: --
Resolution: FIXED
Created: 2022-11-08 12:43:12+00:00
Resolved: 2022-11-10 12:31:27+00:00

**[Notes]:**
- This issue is reproducible only if there are no Sponsored tiles via Contile, only Sponsored tile via Pocket is displayed. 
- If the page is refreshed or another tile is dragged, the Sponsored tile jumps back to its position.

**[Affected versions]:**
- Nightly 108.01a (Build ID: 20221107212933)

**[Affected Platforms]:**
- Mac 12.4
- Windows 10 x64
- Linux Mint 20

**[Prerequisites]:**
- Have the Sponsored tiles via Pocket configured and displayed.
- Have no other Sponsored tiles displayed.

**[Steps to reproduce]:**
1. Open the Nightly browser with the profile from prerequisites.
2. Click and hold a normal tile.
3. While holding the normal tile move it to the second position.
4. Release the mouse and observe the behavior.

**[Expected result]:**
- The normal tile cannot be moved into the second position.
- The Sponsored tile via Pocket doesn't change its position.

**[Actual result]:**
- The normal tile can be moved into the second position until another action is performed.
- The Sponsored tile via Pocket changes its position.

**[Aditional Notes]:**
- Attached is a screen recording of the issue.
Bug: Address bar content persists in new tabs
Status: VERIFIED
Priority: P1
Resolution: FIXED
Created: 2022-11-08 12:53:07+00:00
Resolved: 2022-11-22 10:45:17+00:00

**Affected versions**
* Fx 108.0a1

**Affected platforms**
* all

**Preconditions**
Have the persist feature enabled (_browser.urlbar.showSearchTerms.featureGate_ set to true).

**Steps to reproduce**
1. Launch Firefox.
2. Perform a search using the address bar or load any website.
3. Open a new tab.

**Expected result**
* Address bar is empty.

**Actual result**
* The search term or website address is displayed in the new tab.

**Regression range**
* This is regressed by bug 1798938.
Bug: No way to restore the popups browser message from Preferences once dismissed
Status: NEW
Priority: P5
Created: 2022-11-08 13:23:28+00:00
Resolved: 2022-11-08 15:51:52+00:00

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

Steps to reproduce:

1. Clicked a web page link which wanted to open a window as a popup
2. Saw the banner at the top of the page reading "Firefox prevented this site from opening a pop-up window"
3. Accidentally clicked "don't show this message when popups are blocked" in that banner's Preferences menu
4. Tried to get that message back and was unable to


Actual results:

In Firefox's Settings > Privacy and Security > Permissions there is a "Block pop-up windows" checkbox and an "Exceptions" button. The checkbox, being a checkbox, offers two options:
1. allow all popups
2. don't allow popups, and put an icon in the URL bar indicating that the popup was blocked

There is no way, in the standard UI, to re-enable the banner message once you've chosen "don't show this message when popups are blocked". To re-enable that banner, you have to set "privacy.popups.showBrowserMessage" to "true" in about:config, which is considerably more difficult to do, and users are warned away from about:config for good reasons.


Expected results:

The Settings should make the "Block pop-up windows" checkbox actually be a three-option dropdown, with "block", "don't block", and "ask every time" options, where "block" does what the ticked checkbox does now, "don't block" does what the unticked checkbox does now, and "ask every time" brings the message banner back if disabled. It should default to "ask every time", as it does at the moment. (The wording of these options can of course be changed to fit in with other Firefox UI wording; the point is that it's easy to (accidentally!) turn off the banner and not possible to reverse that.)
Bug: New empty content asset looks funny with default OS theme
Status: VERIFIED
Priority: --
Resolution: FIXED
Created: 2022-11-08 14:05:59+00:00
Resolved: 2022-11-18 13:23:55+00:00

In latest nightly 108.0a1, the empty content asset for Recently Closed Tabs doesn't look right. I'm on macOS and have my theme set to "System theme - auto" (set to "light" at the OS level). It looks fine when I set my OS theme to "dark", however. I'm not sure if this is also the case for Tab Pickup's empty content asset.

Expected:
The assets look the same in "System theme - auto" as they do in fx "light" theme

Actual:
Per the screenshot, there's some filled in areas that look odd.
Bug: Inconsistencies in WebRTC permissions in identity panel with Page Info or multiple same-origin tabs
Status: NEW
Priority: P3
Created: 2022-11-09 08:03:29+00:00
Resolved: 2023-03-09 00:19:20+00:00

1. Load testcase.
2. Click "getUserMedia".
3. "Allow" microphone use.
4. Tools -> Page Info -> Permissions -> deselect "Use Default" under "Use the microphone", and select "Block".
5. Click "getUserMedia".  Microphone is blocked.
6. Check the "You have granted this website additional permissions." identity permission panel.

Expect: Microphone "Blocked".
Actual: Microphone "Allowed Temporarily".

7. Permissions -> select "Always Ask" under "Use the microphone".
8. Reload page.

Expect: no "You have granted this website additional permissions." identity permission panel.
Actual: panel exists and says "Allowed Temporarily".

9. Click getUserMedia

Expect: prompt/ask for microphone permission.
Actual: microphone allowed.
Bug: Top right minimize, maximise and close buttons are faded out
Status: RESOLVED
Priority: --
Resolution: DUPLICATE
Created: 2022-11-09 13:03:13+00:00
Resolved: 2022-11-15 08:00:46+00:00

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

Steps to reproduce:

Opened Firefox


Actual results:

In non-troubleshoot mode, my Firefox browser's top right buttons are all faded out and do not look consistent with the rest of the browser. I am not running any skins or extensions. 


Expected results:

Top-right buttons should look normal
Bug: Add bookmark dialog from the Library History view is cut
Status: VERIFIED
Priority: P2
Resolution: FIXED
Created: 2022-11-09 13:48:53+00:00
Resolved: 2022-12-22 16:36:36+00:00

The tip text under the fields is not wrapping and the dialog contents end up being wrapped.
Additional height of the dialog is "broken" (too much, doesn't adapt to content)

STR:
1. open the library window and go to history
2. right click on an history entry and pick Bookmark Page

Expected:
contents are not cut and the window is properly sized

Actual:
contents are cut, the window height is excessive
Bug: PDF rendering broken (exchanged letters, C displayed as 8 and similar)
Status: VERIFIED
Priority: P3
Resolution: FIXED
Created: 2022-11-09 17:13:16+00:00
Resolved: 2022-12-19 09:24:17+00:00

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

Steps to reproduce:

Open the attached PDF in Firefox (tried 106.0.5 and 107.0b9, happens since early this year though IIRC)


Actual results:

The displayed content is wrong in many aspects, in this example both the letters "B" and "C" are displayed as "8", some letter blocks have wrong alignment, etc.
Changing the source and regenerating the PDF can result in slightly different problems (different letters affected, different alignment problems).


Expected results:

Correct display as for example in Acrobat Reader or Chrome.
Bug: Forced restart to upgrade with minimal (15 minute) notice
Status: RESOLVED
Priority: --
Resolution: INVALID
Created: 2022-11-09 18:31:23+00:00
Resolved: 2022-11-09 19:31:32+00:00

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

Steps to reproduce:

Nothing


Actual results:

Firefox produced a notification stating:

> Firefox will quit in 15 minutes so that Mozilla Firefox can be updated. Save anything you are working on and quit the app(s).

15 minutes later, Firefox exited.


Expected results:

If I ever encountered a forced restart before, I guarantee I immediately disabled it. So this either ignored a previous preference setting, or is a brand new "feature" that gave incredibly short notice before exiting the application. I was merely away from my desk for a few minutes, but otherwise actively using Firefox.

If you're going to do this (and you shouldn't), you should give the user more than 15 minutes notice, as that is not remotely enough time to be able to respond.
Bug: After forced quit for upgrade, Firefox requests upgrade
Status: RESOLVED
Priority: --
Resolution: INVALID
Created: 2022-11-09 18:34:54+00:00
Resolved: 2022-11-09 20:19:42+00:00

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

Steps to reproduce:

Nothing


Actual results:

After a forced quit that was supposedly to perform an upgrade (see #1799948), Firefox restarts and immediately requests another restart so that it can upgrade.


Expected results:

If you're going to force Firefox to exit in order to upgrade, it should actually perform the upgrade and not require that the user perform the action upon restart.
Bug: Firefox wants to install helper application without description
Status: RESOLVED
Priority: --
Resolution: DUPLICATE
Created: 2022-11-09 18:40:13+00:00
Resolved: 2022-11-18 09:27:27+00:00

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

Steps to reproduce:

I didn't do anything, but Firefox exited by itself supposedly to perform an upgrade. (See #1799948)


Actual results:

When Firefox was started by the user, a notification was displayed requesting that the user enter his password so that a helper application could be installed.

There was no indication of what the helper application was for. (I failed to capture a screenshot, but it was a typical MacOS authentication dialog.)


Expected results:

If starting Firefox is going to invoke the installation of a helper application, Firefox should notify the user what the helper application is for. That said, Firefox should probably not install additional applications at all.
Bug: New Tab Page has layout shift from article source appearing a bit later than other contnet
Status: VERIFIED
Priority: --
Resolution: FIXED
Created: 2022-11-09 20:42:22+00:00
Resolved: 2022-12-20 13:04:03+00:00

STR:
1. Reload the new-tab page, and watch the layout afterwards.
2. Repeat.

(Or equivalently: Open a new tab or new window, watch the layout, and then open a new tab/window again.)

ACTUAL RESULTS:
As the new tab page renders, the layout shifts a few times, which is a bit distracting & feels a bit broken.
The most noticeable (and avoidable) shift that I see is when the single-line domain name & reading-time-estimate appears, and the blurb shifts down (and the tile grows taller) to accommodate it.

EXPECTED RESULTS:
We should aim to avoid layout shift here. Specifically for the domain name & reading-time-estimate, we could just allocate some space there for that empty line, and populate it with text when the text is ready, without impacting the layout.
Bug: Intermittent browser/components/urlbar/tests/browser/browser_UrlbarInput_searchTerms_moveTab.js | single tracking bug
Status: RESOLVED
Priority: P5
Resolution: FIXED
Created: 2022-11-09 21:20:11+00:00
Resolved: 2022-11-18 15:49:11+00:00

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

---
```
[task 2022-11-09T20:10:10.975Z] 20:10:10     INFO - TEST-PASS | browser/components/urlbar/tests/browser/browser_UrlbarInput_searchTerms_moveTab.js | showingSearchTerms should be true - true == true - 
[task 2022-11-09T20:10:10.977Z] 20:10:10     INFO - Buffered messages finished
[task 2022-11-09T20:10:10.979Z] 20:10:10     INFO - TEST-UNEXPECTED-FAIL | browser/components/urlbar/tests/browser/browser_UrlbarInput_searchTerms_moveTab.js | A promise chain failed to handle a rejection: can't access property "trim", value is null - stack: search@resource:///modules/UrlbarInput.sys.mjs:1509:24
[task 2022-11-09T20:10:10.980Z] 20:10:10     INFO - _maybeShowTipForUrl/<@resource:///modules/UrlbarProviderSearchTips.sys.mjs:485:22
[task 2022-11-09T20:10:10.980Z] 20:10:10     INFO - Rejection date: Wed Nov 09 2022 20:10:08 GMT+0000 (Coordinated Universal Time) - false == true - JS frame :: resource://testing-common/PromiseTestUtils.sys.mjs :: assertNoUncaughtRejections :: line 266
[task 2022-11-09T20:10:10.981Z] 20:10:10     INFO - Stack trace:
[task 2022-11-09T20:10:10.982Z] 20:10:10     INFO - resource://testing-common/PromiseTestUtils.sys.mjs:assertNoUncaughtRejections:266
[task 2022-11-09T20:10:10.982Z] 20:10:10     INFO - chrome://mochikit/content/browser-test.js:handleTask:1073
[task 2022-11-09T20:10:10.983Z] 20:10:10     INFO - Leaving test bound move_tab_into_new_window
[task 2022-11-09T20:10:10.984Z] 20:10:10     INFO - Entering test bound move_tab_into_existing_window
```