av9ash/GitBugs huggingface dataset:
Bug: Custom Enhanced Tracking Protection settings still focusable and accessible when search excludes them
Status: RESOLVED
Priority: --
Resolution: FIXED
Created: 2022-07-18 05:23:06+00:00
Resolved: 2023-06-02 15:23:33+00:00

STR:

1. Open about:preferences.
2. In the search box, type: zzzz
3. Press tab twice.
    - Expected: Focus should go to the browser tab bar.
    - Actual: Focus goes to the Cookies checkbox in custom Enhanced Tracking Protection (id: contentBlockingBlockCookiesCheckbox).

I'm blind, so I can't be sure, but from what I can tell using OCR, these controls aren't actually visible on screen. However, they are definitely focusable with tab and they are definitely exposed in the a11y tree. This is very confusing/annoying for screen reader users, as it makes it appear as if the search always matches these options, but the context is missing.
Bug: Drag-to-save does not obey filename in content disposition
Status: RESOLVED
Priority: --
Resolution: INCOMPLETE
Created: 2022-07-18 06:10:28+00:00
Resolved: 2024-09-11 03:47:18+00:00

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

Steps to reproduce:

1. Find a file that comes back with a content disposition response header which includes a filename that is different from the filename in the url (example: https://data23.kemono.party/data/7c/40/7c408f95e0e17e4d291777b9505ab558db3e535526ed69c745b6da6f24044cc8.jpg?f=PXL_20220216_184315912.jpg)
2. Drag file to desktop or any other folder
3. File will have the filename that was present in the url, not the filename that was in the content disposition. With the example file, the image will be saved as 7c408f95e0e17e4d291777b9505ab558db3e535526ed69c745b6da6f24044cc8.jpg instead of PXL_20220216_184315912.jpg


Actual results:

File is saved with the incorrect name when dragging to save


Expected results:

File should be saved with filename present in the content disposition response header when dragging to save
Bug: Javascript division provides strange results
Status: RESOLVED
Priority: --
Resolution: DUPLICATE
Created: 2022-07-18 08:23:45+00:00
Resolved: 2022-07-18 09:07:41+00:00

User Agent: Mozilla/5.0 (Windows NT 10.0; WOW64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/103.0.0.0 Safari/537.36

Steps to reproduce:

I am building a metrics converter website that performs intensive calculations and i am mainly using JS to perform all these calculations.

There are many scenarios where I get decimal numbers with different precision(much longer), I can provide a few instances here.
 


Actual results:

Eg - Centimeters to Meters
So let's say if a user enters 0.009 centimeters and the formula to get the meters would be to divide the centimeter value by 100

0.009/100
Provides - 0.00008999999999999999





Expected results:

The Expected result should be just 0.00009, this works perfectly in other languages like python, c# etc. 

0.009/100
Provides - 0.00009
Bug: Heavily loaded firefox render computer unusable at startup
Status: RESOLVED
Priority: --
Resolution: INCOMPLETE
Created: 2022-07-18 09:07:23+00:00
Resolved: 2024-01-01 12:22:40+00:00

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

Steps to reproduce:

Start firefox (on Linux Mint 19.3 Cinnamon with only 16GB ram) with a very large amount of windows (38) and thousands of (>5000) tabs (Yeah, I know it's a pathological use and it's not specific to one version).


Actual results:

Currently, my firefox is so loaded, that I'm forced to start it in SAFE MODE or it renders my computer unusable because it fills up my memory (possibly because of the some addons) but that's just the context and it's probably irrelevant (I just mention it to make sure).

The point is that it take a long time AND it steals the focus for each windows which is particularly annoying  because it blocks me from doing anything else with my computer while i'm waiting for the starting completion.


Expected results:

I really would like it to start in the background without blocking me from using my computer during the starting process.
Bug: Firefox view - Fix Dynamic timestamp and improve tests
Status: RESOLVED
Priority: --
Resolution: FIXED
Created: 2022-07-18 10:21:39+00:00
Resolved: 2022-07-22 21:48:57+00:00

I introduced a bug while making changes during the review round, and unfortunately my tests had a typo (copy/pasted around) so I only noticed the bug after the patch landed.
Bug: Device name and timing for synced tabs lacks padding/margin in about:firefoxview
Status: RESOLVED
Priority: P2
Resolution: FIXED
Created: 2022-07-18 15:32:14+00:00
Resolved: 2022-08-25 12:09:18+00:00

Spotted when testing D151401. See screenshot.

I wonder if I broke this in https://bugzilla.mozilla.org/show_bug.cgi?id=1764816 ...
Bug: Paragraphs are being read in parts instead of being read in one shot (NVDA)
Status: RESOLVED
Priority: --
Resolution: WORKSFORME
Created: 2022-07-18 17:17:37+00:00
Resolved: 2022-07-19 02:04:06+00:00

**Note**
* When the user attempts to use up/down arrow buttons in order to read parts of a page, he will notice that (somewhat longer) paragraphs are being read parts instead of being read in one shot. Some links appear to be split into different links, creating confusion.

** Found in**
* Nightly v104.0a1

**Affected versions**
* Nightly v104.0a1

**Affected platforms**
* Windows 10 + NVDA
* Ubuntu + ORCA - splits partagraphs into lines and is less confusing. 
* MacOS + VoiceOver - UNAFFECTED, as it reads all paragraphs in one go.

**Steps to reproduce (Windows)**
1. Have NVDA running in the background.
2. Launch Firefox.
3. Load www.afb.org
4. Use the down arrow to navigate through the information on the page.
5. Reach the longer chunks of text (paragraphs/links).

**Expected result**
* The paragraphs are being read in one go.

**Actual result**
* The paragraphs are being read in parts (or lines).

**Regression range**
* Not a recent regression.

**Additional notes**
* Example 1 (simple text): "AFB's third Access and Engagement research report examines the continued negative impact of [NVDA stops, user input is required] systemic and COVID-19-specific issues on the education of students who are blind or have low [NVDA stops, user input is required] vision—particularly experiences with technology, learning progress, and social-emotional effects of [NVDA stops, user input is required] the pandemic."
* Example 2 (link): "We speak up for children who are blind or visually impaired, to make sure every student has an equal [NVDA stops, user input is required] opportunity to succeed."
* If any of the affected operating systems are addressed and the issue still occurs on others, other bugs will be logged separately for the remaining issues. Please NI me for continuity is necessary.
* This issue does not occur when navigating using the TAB key (in case of long link texts).
Bug: NVDA (or any screen readers) does not specify when a Fx's menu buttons have sub-menu buttons
Status: NEW
Priority: P3
Created: 2022-07-18 18:13:05+00:00
Resolved: 2023-06-02 15:23:34+00:00

**Note**
* When the user navigates through the menu buttons, he might not notice that some buttons have sub-menu buttons.

** Found in**
* Nightly v104.0a1

**Affected versions**
* Nightly v104.0a1

**Affected platforms**
* all

**Steps to reproduce**
1. Have NVDA running in the background.
2. Navigate to the "Hamburger menu"/"main menu" button and open it.
3. Navigate through the menu and observe how NVDA reads "Bookmarks", History, More tools and Help.

**Expected result**
* Notice that there is no reference to the fact that the button opens a sub-menu.

**Actual result**
* The screen readers only read the button text and its position in its group of buttons.

**Regression range**
* Not a recent regression.

**Additional notes**
* This issue occurs the same in any of the screen readers/OSes tested.
Bug: The "Only Show on New Tab" feature in bookmarks doesn't work when the New Tab is set to a blank page.
Status: RESOLVED
Priority: --
Resolution: DUPLICATE
Created: 2022-07-19 08:09:33+00:00
Resolved: 2022-07-19 08:13:10+00:00

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

Steps to reproduce:

1. Create a bookmark on Firefox 102
2. Change the New Tab setting from Firefox home to Blank Page
3. Right click the toolbar and under Bookmarks Toolbar, set the visibility to Only Show on New Tab 


Actual results:

The bookmarks tab does not show.


Expected results:

The bookmarks tab should show.
Bug: [Experiment] The Autofill telemetry impressions are not recorded using the 103 Release Candidate build
Status: VERIFIED
Priority: P1
Resolution: FIXED
Created: 2022-07-19 10:29:04+00:00
Resolved: 2022-08-01 09:21:17+00:00

**[Notes]:**
- This issue is reproducible only using the Release Candidate build; on Nightly 104.0a1 and Beta 103.0b9 builds the autofill impressions are correctly triggered and displayed in the `about:telemetry` page.

**[Affected versions]:**
- Firefox RC 103, Build ID: 20220718155818

**[Affected platforms]:**
- Windows 10 x64
- macOS 12.4
- Ubuntu 20.04 x64

**[Prerequisites]:**
- Have Firefox RC 103 (en* build) on your computer.
- Have the following [user.js](https://drive.google.com/file/d/1XRWXb4DQHGfPmMdeuHMuZ3rdyueB-WUx/view?usp=sharing) downloaded on your computer.
- Have the `browser.search.region` pref set to `US`.

**[Steps to reproduce]:**
1. Open the browser with the profile from prerequisites.
2. Navigate to the Profile Folder from `about:support` page and paste the user.js file from the prerequisites.
2. Restart the browser and open a new tab.
3. Type `moz` characters in the Address Bar.
4. After the `mozilla.org/` domain autofills, press the `Enter` key
5. Navigate to `about:telemetry` in the new tab.
6. Search for `urlbar.impression.autofill_origin` scalar.

**[Expected result]:**
- The `urlbar.impression.autofill_origin` scalar is displayed with `1` as value.

**[Actual result]:**
- The `urlbar.impression.autofill_origin` scalar is **not** displayed.

**[Additional notes]:**
- This issue is also reproducible with the following impressions:
- urlbar.impression.autofill_adaptive
- urlbar.impression.autofill_url
- urlbar.impression.autofill_about
- I have also looked over the [Probe Dictionary](https://probes.telemetry.mozilla.org/?search=urlbar.impression.autofill) and I have noticed that the autofill impressions are recorded only in Nightly and Beta starting with 103 version. Is it intended not having them on the Release builds?
- [Here](https://drive.google.com/file/d/1fM4QQk1L2c65F0bveknXCNeLJhlrH2ev/view?usp=sharing) is a screen recording with the issue.
Bug: Intermittent TV browser/components/places/tests/browser/browser_toolbar_other_bookmarks.js | This test exceeded the timeout threshold. It should be rewritten or split up. If that's not possible, use requestLongerTimeout(N), but only as a last resort. -
Status: RESOLVED
Priority: P5
Resolution: INCOMPLETE
Created: 2022-07-19 12:01:00+00:00
Resolved: 2022-08-16 17:00:50+00:00

**Filed by:** abutkovits [at] mozilla.com
**Parsed log:** https://treeherder.mozilla.org/logviewer?job_id=384759723&repo=autoland
**Full log:** https://firefox-ci-tc.services.mozilla.com/api/queue/v1/task/UAnTxg49Ts2d8_HeZNHxbw/runs/0/artifacts/public/logs/live_backing.log
**Reftest URL:** https://hg.mozilla.org/mozilla-central/raw-file/tip/layout/tools/reftest/reftest-analyzer.xhtml#logurl=https://firefox-ci-tc.services.mozilla.com/api/queue/v1/task/UAnTxg49Ts2d8_HeZNHxbw/runs/0/artifacts/public/logs/live_backing.log&only_show_unexpected=1

---
```
[task 2022-07-19T10:41:55.423Z] 10:41:55     INFO - TEST-PASS | browser/components/places/tests/browser/browser_toolbar_other_bookmarks.js | Last visible toolbar bookmark is the same in both windows. - 
[task 2022-07-19T10:41:55.424Z] 10:41:55     INFO - Leaving test bound testOtherBookmarksToolbarOverFlow
[task 2022-07-19T10:41:55.424Z] 10:41:55     INFO - Buffered messages finished
[task 2022-07-19T10:41:55.424Z] 10:41:55     INFO - TEST-UNEXPECTED-FAIL | browser/components/places/tests/browser/browser_toolbar_other_bookmarks.js | This test exceeded the timeout threshold. It should be rewritten or split up. If that's not possible, use requestLongerTimeout(N), but only as a last resort. - 
[task 2022-07-19T10:41:55.425Z] 10:41:55     INFO - GECKO(5954) | MEMORY STAT vsizeMaxContiguous not supported in this build configuration.
[task 2022-07-19T10:41:55.425Z] 10:41:55     INFO - GECKO(5954) | MEMORY STAT | vsize 16929MB | residentFast 299MB | heapAllocated 125MB
[task 2022-07-19T10:41:55.425Z] 10:41:55     INFO - TEST-OK | browser/components/places/tests/browser/browser_toolbar_other_bookmarks.js | took 49145ms
```
Bug: Fix input error in bug_1737043_aboutNetError.py
Status: RESOLVED
Priority: P3
Resolution: FIXED
Created: 2022-07-19 12:19:29+00:00
Resolved: 2022-07-19 21:38:28+00:00

While adding the patch for bug 1737043 which pertains to the `aboutNetError` page, I used the wrong target path for the `bug_1737043_aboutNetError.py` migration script in `add_transforms`

:flod mentioned he fixed this issue in an outside repository that he uses so this is not completely necessary, but I think the code should be fixed to avoid confusion.
Bug: Downloads icon animation should only run in visible/painting browser windows
Status: RESOLVED
Priority: --
Resolution: WORKSFORME
Created: 2022-07-19 12:47:47+00:00
Resolved: 2023-10-26 15:36:25+00:00

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

Steps to reproduce:

Starting a download with 30 plus upwards windows open. This issue can be felt moderately with perhaps 20 windows onwards, and severely from 50 windows onwards. Nowadays, Firefox completely and utterly stalls my whole computer while I download anything at all.

Downloading something in a single private browsing window, as a point of comparison, the download animation has no effect on the performance of the browser.

This is also a problem with any and all add-ons that have updating icons (number indicators, etc.) in the menu toolbar - the common factor being that the browser updates the UI in each window, causing the stalling/freezing effect.


Actual results:

The download meter animation frames updating stall the browser when the user has lots of windows open. 

Every time the download progress wheel icon frames are updated, the entire browser UI stalls completely, apparently updating every window simultaneously, creating massive and constant stress on the browser UI.

Once each window has updated the animation frame, control of the UI returns for a moment. As soon as the download progresses enough for the icon to be reupdated, the browser completely freezes again. 


Expected results:

The issue has clearly to do with the animation being updated simultaneously in every window, not just the visible one(s).

To save resources, the browser should update the animations in just currently visible window(s), and update them iteratively as the user switches back and forth.
Bug: Strange CPU usage on main process without apparent reason
Status: RESOLVED
Priority: --
Resolution: INCOMPLETE
Created: 2022-07-19 13:25:07+00:00
Resolved: 2024-01-04 21:48:40+00:00

Since a few weeks (around a restart after upgrading to Firefox 102.0), I started seeing the main process of my usual, old, Firefox session on my work's mac eating way too much CPU compared to what it used to and should use.

Here are more detailed information:
- This is running Firefox stable, now the latest 102.x, on a mac; the session is having a very high number of tabs (thousands), but not more than it had in the past months/years. The addons didn't changed recently either
- The CPU issue isn't there when I open Firefox and didn't yet restore the session, which means it only have 7 opened pinned tabs;
- Once I restore the session, main process' CPU keeps getting between 200% at its lowest and more than 350% at its highest. The normal situation had this process to be much under 100% when not doing anything resource-hungry;
- I tried checking `about:performance` but it didn't show anything meaningful. `about:processes` (for which I'll join a partial screenshot below) only shows the main process use a lot of CPU/memory;
- As I suspected a regression from version 102.0 I played with `mozregression`, unfortunately I reproduced the issue with releases 101.0 and 100.0, leading me to think the profile is somehow messed up.

Now, how can I investigate what, in the main process, is causing this surge in CPU usage? I have no idea how to provide more useful information, bu there's definitely something fishy here.

Also, computer was rebooted and Firefox restarted a bunch of times, and some of the cache that could be culprit (like Slack eating almost 3GB in cache!) completely wiped.
Bug: Spacing between Tab pickup and Recently closed headers and supporting content different from design files
Status: VERIFIED
Priority: P3
Resolution: FIXED
Created: 2022-07-19 15:32:37+00:00
Resolved: 2022-09-30 09:05:29+00:00

Actual: Spacing between headers and supporting copy is 15 px
Expected: Spacing between headers and supporting copy is 4 px

(Tab Pickup and Recently closed headers and supporting copy)
Bug: Colorways landmark bisects main page content - expect colorways to be focused on / read by screenreader last
Status: RESOLVED
Priority: P3
Resolution: FIXED
Created: 2022-07-19 15:42:19+00:00
Resolved: 2023-06-02 15:23:34+00:00

Actual: Colorways content is focused on/read after tab pickup and before Recently closed.
Expected: Colorways content should be focused on/read after Tab pickup and Recently closed.
Bug: Firefox View collapse arrows should have aria roles and state that indicate what they do
Status: VERIFIED
Priority: P2
Resolution: FIXED
Created: 2022-07-19 15:53:38+00:00
Resolved: 2023-06-02 15:23:34+00:00

Actual: Both chevrons and supporting content underneath headers for Tab content and Recently closed are acting as accordions (when using voiceover) but both lack aria roles which effectively describe their functionality as accordions.
Expected: User is informed when focusing on the chevron button or the supporting copy button that this is a button and the information under the button is either collapsed or expanded.

Example of expected implementation of accordions : http://web-accessibility.carnegiemuseums.org/code/accordions/
Bug: Tab pickup containers and Recently closed list items assigned button role but should behave like and be read as links
Status: RESOLVED
Priority: --
Resolution: DUPLICATE
Created: 2022-07-19 15:58:38+00:00
Resolved: 2022-07-19 16:28:55+00:00

Actual: Tab pickup containers/cards and Recently closed list items are assigned a button role.
Expected: Tab pickup containers/cards and Recently closed list items are assigned a link role

Links carry different functionality than buttons. Buttons do something, links take the user somewhere. By assigning link role, we tell screenreader users clicking this will take them to a different URL. It also tells them that they can copy the link or perform other actions you can take on a link through the contextual menu, but not on a button.
Bug: Independent voices promo wrapping behavior different from design files
Status: RESOLVED
Priority: --
Resolution: DUPLICATE
Created: 2022-07-19 16:07:39+00:00
Resolved: 2022-07-19 17:53:16+00:00

Actual: Independent voices promo wraps between Tab pickup and Recently closed sections with colorways graphic on top of text.
Expected: Independent voices promo wraps between Tab pickup and Recently closed sections with colorways graphic to the right of text.
Bug: Intermittent TV browser/components/preferences/tests/browser_privacy_syncDataClearing.js | This test exceeded the timeout threshold. It should be rewritten or split up. If that's not possible, use requestLongerTimeout(N), but only as a last resort. -
Status: RESOLVED
Priority: P5
Resolution: INCOMPLETE
Created: 2022-07-19 16:09:45+00:00
Resolved: 2022-08-16 17:00:57+00:00

**Filed by:** abutkovits [at] mozilla.com
**Parsed log:** https://treeherder.mozilla.org/logviewer?job_id=384793538&repo=autoland
**Full log:** https://firefox-ci-tc.services.mozilla.com/api/queue/v1/task/SJXN-Z9HRrO9RSzgGunj0Q/runs/0/artifacts/public/logs/live_backing.log
**Reftest URL:** https://hg.mozilla.org/mozilla-central/raw-file/tip/layout/tools/reftest/reftest-analyzer.xhtml#logurl=https://firefox-ci-tc.services.mozilla.com/api/queue/v1/task/SJXN-Z9HRrO9RSzgGunj0Q/runs/0/artifacts/public/logs/live_backing.log&only_show_unexpected=1

---
```
[task 2022-07-19T15:52:54.954Z] 15:52:54     INFO - TEST-PASS | browser/components/preferences/tests/browser_privacy_syncDataClearing.js | DeleteOnClose is set accordingly to the private Browsing autostart pref, selected - 
[task 2022-07-19T15:52:54.955Z] 15:52:54     INFO - Buffered messages logged at 15:52:54
[task 2022-07-19T15:52:54.955Z] 15:52:54     INFO - Console message: [JavaScript Error: "TypeError: node.getAttribute is not a function" {file: "resource:///modules/BrowserUsageTelemetry.jsm" line: 829}]
[task 2022-07-19T15:52:54.955Z] 15:52:54     INFO - _recordCommand@resource:///modules/BrowserUsageTelemetry.jsm:829:15
[task 2022-07-19T15:52:54.955Z] 15:52:54     INFO - _addUsageListeners/<@resource:///modules/BrowserUsageTelemetry.jsm:860:51
[task 2022-07-19T15:52:54.955Z] 15:52:54     INFO - test_initialState@chrome://mochitests/content/browser/browser/components/preferences/tests/browser_privacy_syncDataClearing.js:284:15
[task 2022-07-19T15:52:54.955Z] 15:52:54     INFO - 
[task 2022-07-19T15:52:54.956Z] 15:52:54     INFO - Leaving test bound test_initialState
[task 2022-07-19T15:52:54.956Z] 15:52:54     INFO - Buffered messages finished
[task 2022-07-19T15:52:54.957Z] 15:52:54     INFO - TEST-UNEXPECTED-FAIL | browser/components/preferences/tests/browser_privacy_syncDataClearing.js | This test exceeded the timeout threshold. It should be rewritten or split up. If that's not possible, use requestLongerTimeout(N), but only as a last resort. - 
[task 2022-07-19T15:52:54.957Z] 15:52:54     INFO - GECKO(1741) | MEMORY STAT vsizeMaxContiguous not supported in this build configuration.
[task 2022-07-19T15:52:54.957Z] 15:52:54     INFO - GECKO(1741) | MEMORY STAT | vsize 16045MB | residentFast 337MB | heapAllocated 165MB
[task 2022-07-19T15:52:54.958Z] 15:52:54     INFO - TEST-OK | browser/components/preferences/tests/browser_privacy_syncDataClearing.js | took 61811ms
[task 2022-07-19T15:52:54.958Z] 15:52:54     INFO - checking window state
```
Bug: while pairing android to firefox browser caret browsing message pops up and freezes screen
Status: RESOLVED
Priority: --
Resolution: INCOMPLETE
Created: 2022-07-19 16:58:21+00:00
Resolved: 2022-11-16 03:14:07+00:00

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

Steps to reproduce:

In trying to install Firefox on my android phone I attempted to pair the two devices by going to
https://firefox.com/pair
This poped up a scan code (which I was unable to scan for an unrelated reason)



Actual results:

while I was trying to scan the code a popup came on the screen labeled
Caret Browsing (see attached screen shot)
At this time the screen went slightly grey and I could only enter the Yes or No boxes inside the popup.
Clicking these boxes just returned to the same state on the screen.
Meanwhile Foxfire was locked to any other input.
(I killed Foxfire from the operating system)




Expected results:

This popup does not seem relevant at this time.  If it is it should not lock or prevent other things from working
Bug: [Colorway Closet] Homepage reset footer layout is broken
Status: VERIFIED
Priority: P2
Resolution: FIXED
Created: 2022-07-19 18:08:29+00:00
Resolved: 2022-08-29 11:27:40+00:00

When a user does not have Firefox Home as their default homepage, the Firefox Home apply button will appear on the modal footer. If the apply button is selected, the button is updated to be an undo button.

To enable:
1. Ensure browser.theme.colorway-closet is enabled
2. Go to about:preferences and ensure that "Homepage and new windows" is not set to Firefox Home (can use blank page)
3. Open Colorways modal and notice the Firefox Home button at the bottom of the modal

Currently, the Firefox Home button does not look as expected with responsive sizing and must be fixed.