av9ash/GitBugs huggingface dataset:
Bug: The Thickness levels remain locked after the Highlighted text is unselected
Status: VERIFIED
Priority: P1
Resolution: FIXED
Created: 2024-02-21 10:11:21+00:00
Resolved: 2024-03-04 10:08:17+00:00

**Found in**
* Nightly 125.0a1 (2024-02-21)

**Affected versions**
* Nightly 125.0a1 (2024-02-21)
* Beta 124.0b1
* Release 123

**Affected platforms**
* All

**Steps to reproduce**
1. Open any PDF in Firefox.
2. Enable the Highlight tool.
3. Highlight some Text.
4. Try to Edit the Thickness levels.
5. Click Anywhere else to Unselect the Highlighted Text.
6. Try to Edit the Thickness levels.
7. Disable the Highlight tool from the Toolbar and re Enabled it.
8. Try to Edit the Thickness levels.

**Expected result**
* The Moment the Highlighted text is unselected the Thickness levels should be unlocked and editable.

**Actual result**
* The Thickness levels remain locked after the Tool is disabled and re enabled, or the Highlighted text is unselected.

**Regression range**
Not a Regression
Bug: Translating a page from German to English strips out unicode symbols like "✓"
Status: RESOLVED
Priority: --
Resolution: MOVED
Created: 2024-02-21 14:20:41+00:00
Resolved: 2024-07-19 18:23:01+00:00

When translating the current https://www.mozilla.org/de/firefox/ page from German to English, the checkmark ✓ symbol in the comparison chart goes away (making that chart impossible to read unless you toggle back and forth between German and English).

I have attached the current page in case it changes.
Bug: Tabs on on "Open Tabs" are in the wrong order when sorted by recent activity
Status: RESOLVED
Priority: --
Resolution: DUPLICATE
Created: 2024-02-21 14:53:09+00:00
Resolved: 2024-02-21 18:37:25+00:00

In the screenshot the order goes "last week", "6 days ago", "yesterday" which makes no sense when sorting by recent activity.
Bug: Firefox Incognito Mode Accessing Passwords Saved in Normal Mode
Status: RESOLVED
Priority: --
Resolution: INVALID
Created: 2024-02-21 17:25:19+00:00
Resolved: 2024-02-21 22:04:02+00:00

User Agent: Mozilla/5.0 (X11; Linux x86_64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/120.0.0.0 Safari/537.36

Steps to reproduce:

(1) Open Firefox Browser in incognito mode.
(2) Type any social media.Like Facebook
(3) Click email option.Now you  can  see the all credentials like( email ,password)
(4) Note: Remember this is a private browser.


Actual results:

If any user uses a chore browser, Chrome private browser cannot access the save password.


Expected results:

Accessing saved passwords in Chrome's normal mode while browsing in incognito mode.
Bug: Intermittent ./mach doc | Error: 1 new warnings have been introduced compared to the limit in docs/config.yml
Status: RESOLVED
Priority: P5
Resolution: FIXED
Created: 2024-02-21 19:53:46+00:00
Resolved: 2024-03-04 06:19:57+00:00

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

---
```
This line should be the new warning:
`/builds/worker/checkouts/gecko/docs-out/html/_staging/toolkit/components/ml/index.md: WARNING: document isn't included in any toctree`
```
Bug: Duplicate requests are sent for long running requests
Status: RESOLVED
Priority: --
Resolution: INCOMPLETE
Created: 2024-02-22 04:38:29+00:00
Resolved: 2024-07-25 13:15:20+00:00

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

Steps to reproduce:

We connect to the URL of our application. We then execute a report which fetches the metadata details of millions of documents within the application. A report is then sent as an email to the report executor.


This 


Actual results:

When the request takes more than 600 seconds, we see a duplicate request being sent. So the user who executes the report ends up getting 2 or more emails because of the duplicate requests which were sent


Expected results:

Only one email should be sent for one execution of the report.
Bug: Mozilla crashing on certain websites
Status: RESOLVED
Priority: --
Resolution: INCOMPLETE
Created: 2024-02-22 11:22:59+00:00
Resolved: 2024-07-25 13:12:15+00:00

User Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/121.0.0.0 Safari/537.36 Edg/121.0.0.0

Steps to reproduce:

I opened the UBL site


Actual results:

The mozilla stopped execution and crashed.


Expected results:

It should have rendered the site
Bug: Tab preview delay feels too big
Status: RESOLVED
Priority: --
Resolution: FIXED
Created: 2024-02-22 11:55:29+00:00
Resolved: 2024-02-27 04:35:06+00:00

`browser.tabs.cardPreview.delayMs` defaults to 1 second, which feels too slow. Tooltips use 500ms, probably would be worth matching them?
Bug: Mouse click event stuck when using right mouse click during taking a screenshot
Status: VERIFIED
Priority: P3
Resolution: FIXED
Created: 2024-02-22 12:56:13+00:00
Resolved: 2024-04-29 08:26:26+00:00

**Found in**
* Firefox 124.0b2

**Affected versions**
* Firefox 115.8.0esr
* Firefox 124.0b2
* Firefox 123.0
* Nightly 87.0a1

**Tested platforms**
* Affected platforms: MacOS 13.6, Ubuntu 22.04 and Windows 11.
* Unaffected platforms: none

**Preconditions**
* Have a 2 button mouse connected to the device. (trackpad or magic mouse will not work)

**Steps to reproduce**
1. Visit a random webpage
2. Press shift+cmd+S or click the screenshot button (is located in Customize and needs to be added in the toolbar).
3. Left click to select a screenshot area
4. Use the right click of the mouse at the same time the left click is used
5. Release the left click
6. Select the "Select all" option from context menu
7. Move the mouse without touching any mouse buttons

**Expected result**
* I believe the right click context menu should be disabled when selecting an area to take a screenshot, same as its done for Print preview for example. Once I release the left click button the options to download, copy or close appear. 

**Actual result**
* The mouse click button is stuck and the screenshot area can be changed even if no physical button is pressed on the mouse. On Mac the selection area is stuck in one place but in can still be moved if right clicking over and over in the page (see the screencast attached)

**Regression range**
* Not a recent regression since its reproducible on Firefox 87 as well and I think this has always been the same. Not sure when Screenshots was first implemented though. I am unable to open older builds on Ubuntu/Mac13 though so I would say that this is not a regression.

**Additional notes**
* I also am able to reproduce this after switching screenshots.browser.component.enabled to true.
Bug: Same search terms across different engines are using the same moz_historyform (update)
Status: NEW
Priority: P3
Created: 2024-02-22 13:50:05+00:00
Resolved: 2024-03-04 16:26:24+00:00

**Notes**
* Follow-up from bug 1858978

**Found in**
* Nightly 120.0a1;

**Affected versions**
* Nightly 120.0a1;

**Tested platforms**
* Windows 10;
* Ubuntu 22;
* macOS 13; 


**Preconditions**
* browser.urlbar.recentsearches.featureGate set to true 
* browser.urlbar.suggest.recentsearches set to true 

**Steps to reproduce**
1. Launch Firefox with the profile from preconditions.
2. Have a search done with default engine(A) for `search_term` any time. (e.g. in the past - let's say 2 months ago - below STR cover this scenario, or just recently - for more recent searches, the recent search order will get changed by same search done on different engine) 
3. Focus the Address Bar and perform some searches(x,y,z) using the default search engine(A).
4. Focus the Address Bar and notice the Recent Searches.
5. Use search shortcut for any engine, but the default engineA - e.g. `@engineB  search_term`
6. Focus the Address Bar and notice the Recent Searches.
7. Change default engine to the engineB, focus the Address Bar and notice the Recent Searches.


**Expected result**
* step 4 - Recent Search display `x`,`y`,`z` for engine(A)
* **step6 - Recent Search display `x`,`y`,`z` for engine(A)**
* step7 - Recent search display `search_term` for engine(B)

**Actual result**
* step 4 - Recent Search display `x`,`y`,`z` for engine(A)
* **step6 - Recent Search display `x`,`y`,`z`, `search_term` for engine(A)** 
* step7 - Recent search display `search_term` for engine(B)

**Regression range**
* Not a regression.
Bug: Incorrect IPv6 address presentation in certificate view
Status: NEW
Priority: P3
Created: 2024-02-22 13:58:34+00:00
Resolved: 2024-06-03 17:12:29+00:00

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

Steps to reproduce:

1. Open a new Firefox window and visit https://9.9.9.9/dns-query
2. Click the lock pad and finally click the View Certificate



Actual results:

In the View Certificate page the IP Address listed for object "Subject Alt Names" has incorrect format, e.g. "IP Address
2620::fe:0000:0000:0000:0000:0000:0009" (See attachment picture)


Expected results:

IPv6 address is a 128-bit colon segmented address but Firefox renders IPv6 as more than 128-bit -- "2620::fe:0000:0000:0000:0000:0000:0009"

That is, there should be ONE colon between "2620" and "fe"
Bug: Cannot scroll tab list when card preview is shown
Status: RESOLVED
Priority: --
Resolution: INVALID
Created: 2024-02-22 14:28:26+00:00
Resolved: 2024-02-23 16:36:11+00:00

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

Steps to reproduce:

When the card preview is shown it is no longer possible to scroll the tab list with either a mouse wheel.

STR

   * Enable browser.tabs.cardPreview.enabled
   * Open enough tabs that they start to scroll
   * Hover a tab and wait for card preview
   * Scroll the tabs (either mouse wheel)



Actual results:

The tabs scroll


Expected results:

No scrolling occurs
Bug: Upgrade to 115.8.0ESR while Firefox open gives Werfault errors
Status: RESOLVED
Priority: --
Resolution: INCOMPLETE
Created: 2024-02-22 15:31:36+00:00
Resolved: 2024-07-26 07:22:34+00:00

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

Steps to reproduce:

Delivered an upgrade from 115.7.0 ESR to 115.8.0 with Intune, whilst Firefox was open.


Actual results:

Repeated WERFAULT.exe popups. Happened on 2 machines.


Expected results:

The upgrade from 115.6 to .7 was brilliant as, I think for the first time, it detected an upgrade happening in the background and advised a restart. Prior to that, background upgrades resulted in bizarre instability. I would have expected the upgrade to .8 to be as good.
Bug: Opened tabs section should display windows in a masonry layout
Status: RESOLVED
Priority: --
Resolution: DUPLICATE
Created: 2024-02-22 17:07:15+00:00
Resolved: 2024-02-27 14:11:02+00:00

In the original spec for Opened tabs, we show windows in an masonry layout but that isn't reflected in implementation. See attached image for reference (tabs blanked out for confidentiality). Thank you

Original spec
https://www.figma.com/file/wP9MY9KJn9xqPf140lTvTv/Fx-View-Specs-2023?type=design&node-id=6699%3A737753&mode=design&t=A5rBxO1jn9rvJ8fQ-1
Bug: Intermittent toolkit/components/nimbus/test/unit/test_ExperimentManager_unenroll.js | single tracking bug
Status: RESOLVED
Priority: P5
Resolution: INCOMPLETE
Created: 2024-02-22 18:18:09+00:00
Resolved: 2024-04-22 12:05:34+00:00

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

---
```
[task 2024-02-22T17:52:09.841Z] 17:52:09     INFO -  TEST-START | toolkit/components/nimbus/test/unit/test_ExperimentManager_unenroll.js
[task 2024-02-22T17:52:17.031Z] 17:52:17  WARNING -  TEST-UNEXPECTED-FAIL | toolkit/components/nimbus/test/unit/test_ExperimentManager_unenroll.js | xpcshell return code: 0
[task 2024-02-22T17:52:17.032Z] 17:52:17     INFO -  TEST-INFO took 7185ms
```
Bug: Intermittent browser_overflowScroll.js | single tracking bug
Status: REOPENED
Priority: P5
Created: 2024-02-22 19:37:25+00:00
Resolved: 2025-03-03 06:46:50+00:00

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

---
```
[task 2024-02-22T19:00:11.512Z] 19:00:11     INFO - TEST-START | browser/base/content/test/tabs/browser_overflowScroll.js
[task 2024-02-22T19:00:11.732Z] 19:00:11     INFO - TEST-INFO | started process screenshot
[task 2024-02-22T19:00:12.002Z] 19:00:12     INFO - TEST-INFO | screenshot: exit 0
[task 2024-02-22T19:00:12.002Z] 19:00:12     INFO - Buffered messages logged at 19:00:11
[task 2024-02-22T19:00:12.002Z] 19:00:12     INFO - Entering test bound 
[task 2024-02-22T19:00:12.002Z] 19:00:12     INFO - Buffered messages finished
[task 2024-02-22T19:00:12.002Z] 19:00:12     INFO - TEST-UNEXPECTED-FAIL | browser/base/content/test/tabs/browser_overflowScroll.js | Tab strip should be overflowing - 
[task 2024-02-22T19:00:12.002Z] 19:00:12     INFO - Stack trace:
[task 2024-02-22T19:00:12.002Z] 19:00:12     INFO - chrome://mochikit/content/browser-test.js:test_ok:1580
[task 2024-02-22T19:00:12.002Z] 19:00:12     INFO - chrome://mochitests/content/browser/browser/base/content/test/tabs/browser_overflowScroll.js:null:40
[task 2024-02-22T19:00:12.002Z] 19:00:12     INFO - chrome://mochikit/content/browser-test.js:handleTask:1131
[task 2024-02-22T19:00:12.002Z] 19:00:12     INFO - chrome://mochikit/content/browser-test.js:_runTaskBasedTest:1203
[task 2024-02-22T19:00:12.002Z] 19:00:12     INFO - chrome://mochikit/content/browser-test.js:Tester_execTest:1345
[task 2024-02-22T19:00:12.002Z] 19:00:12     INFO - chrome://mochikit/content/browser-test.js:nextTest/<:1120
[task 2024-02-22T19:00:12.002Z] 19:00:12     INFO - chrome://mochikit/content/tests/SimpleTest/SimpleTest.js:SimpleTest.waitForFocus/<:1056
[task 2024-02-22T19:00:12.010Z] 19:00:12     INFO - TEST-PASS | browser/base/content/test/tabs/browser_overflowScroll.js | Selecting the first tab scrolls it into view (85 <= 137) - 
```
Bug: Native Notifications popping out a new temporary window after update to 123
Status: RESOLVED
Priority: --
Resolution: DUPLICATE
Created: 2024-02-22 19:59:05+00:00
Resolved: 2024-02-25 09:55:11+00:00

Steps to reproduce:

Simply updated the browser


Actual results:

Whenever I get a (native) notification, since I have that setting, a temporary window appears (and it shows or doesn't show depending on the visibility of the browser in that moment). It has been happening with Whatsapp Web, but I'm not using other notifications right now to check if it happens with another site.


Expected results:

The notification should be shown without any new window and regardless of browser visibility
Bug: Misalignment between urlbar identity icon and its searchglass version
Status: RESOLVED
Priority: P3
Resolution: WONTFIX
Created: 2024-02-22 22:05:45+00:00
Resolved: 2024-03-14 14:54:32+00:00

When the urlbar's identity icon is in search mode, its inline margins are much greater than in other modes where it can be clicked as a button.

See attached screen recording.

Regression window: https://hg.mozilla.org/integration/autoland/pushloghtml?fromchange=ae389473ba61480f5ae70369585727aef6010fc7&tochange=49c2d107e082c2e891f92fa8a40582f14eb89c38

I suppose it's hard to avoid misalignment with _something_. Either the identity icon is misaligned with the result favicons, or it's misaligned with itself (when navigating or switching between tabs). But I think this might be worse than the result misalignment, which feels pretty nitpicky. Like, the result misalignment isn't _good_, and I'd certainly prefer if they aligned, but it doesn't feel like a bug. It just feels like the icons weren't intended to align. But when I navigate and I see the urlbar text move to the right/left, and the space around the identity icon grow, it feels like a bug. Technically speaking, the jank factor feels higher :P

It might be resolved by reducing the margins of the result favicons to bring them into line with the identity icon, rather than adjusting the identity icon to match the favicons.
Bug: Unable to navigate inside the PDF file using Caret Browsing after Highlighting text
Status: VERIFIED
Priority: --
Resolution: FIXED
Created: 2024-02-23 08:37:12+00:00
Resolved: 2024-03-04 10:07:52+00:00

**Found in**
* Nightly 125.0a1 (2024-02-23)

**Affected versions**
* Nightly 125.0a1 (2024-02-23)
* Beta 124.0b2
* Release 123

**Affected platforms**
* All

**Steps to reproduce**
1. Open any PDF in Firefox.
2. Enable the Highlight tool.
3. Enable Caret Browsing with f7
4. Reach any text from the PDF file using the Up Down Arrows.
5. Use Shift + Right arrow in order to Highlight text.
6. Use Up Down Arrows in order to reach a different line of text.
7. Use the Escape key or Tab in order to reach any other text.
8. Use Shift + Right arrow in order to Highlight the text.

**Expected result**
* After Highlighting the text the user should be able to navigate using Left Right Up Down arrows.
* The user should be able to unselect the Highlighted text with Escape, and he should be able Highlight a different text.

**Actual result**
* After a text is highlighted the Caret cursor is locked at the beginning of the Highlighted text.
* Navigating to a different text and Highlighting with Shift and Right Arrow it will cause the Caret Cursor to jump at the beginning of the pdf.

**Regression range**
Not a Regression
Bug: [Caret browsing] Caret is at the wrong position when moving up on a highlighted text
Status: VERIFIED
Priority: P1
Resolution: FIXED
Created: 2024-02-23 09:14:25+00:00
Resolved: 2024-03-04 10:19:27+00:00

Attach (recommended) or Link to PDF file here:

Steps to reproduce the problem:
1. Set caret browsing mode
2. Highlight some text.
3. Put the caret in the middle of a line just under the highlighted text
4. Move the caret up.

What is the expected behavior? (add screenshot)
The caret should be in the middle.

What went wrong? (add screenshot)
The caret is at the beginning of the line.
Bug: Unable to Highlight Text in a PDF with Shift + UP/Down arrows when Caret browsing is enabled
Status: RESOLVED
Priority: --
Resolution: DUPLICATE
Created: 2024-02-23 10:42:16+00:00
Resolved: 2024-02-23 18:26:49+00:00

**Found in**
* Nightly 125.0a1 (2024-02-23)

**Affected versions**
* Nightly 125.0a1 (2024-02-23)
* Beta 124.0b2
* Release 123

**Affected platforms**
* All

**Steps to reproduce**
1. Open any PDF in Firefox.
2. Enable the Highlight tool.
3. Enable Caret Browsing with f7
4. Reach any text from the PDF file using the Up Down Arrows.
5. Use Shift + UP/Down arrows in order to Highlight text.

**Expected result**
* Users should be able to highlight entire rows with Shift+Down/Up arrows when Caret Browsing is enabled.

**Actual result**
* Using Shift + UP/Down arrows will select the text correctly but it will not highlight it.

**Regression range**
Not a Regression
Bug: Unexpected behavior when closing multiple tabs simultaneously using right-click menu
Status: RESOLVED
Priority: --
Resolution: INCOMPLETE
Created: 2024-02-23 11:34:40+00:00
Resolved: 2024-09-02 12:21:20+00:00

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

Steps to reproduce:

Open multiple tabs in Firefox (at least 5 for reliable reproduction).
Right-click on any tab.
Select "Close Tabs" from the context menu.


Actual results:

An unexpected confirmation dialog appears asking "Are you sure you want to close all X tabs?".
This dialog appears only once, regardless of the number of tabs being closed (e.g., even for 10 tabs, only one confirmation dialog is shown).
Clicking "Close" on the dialog closes all open tabs, even if the user intended to close only the right-clicked tab.


Expected results:

A separate confirmation dialog should appear for each tab being closed, asking individually "Are you sure you want to close this tab?".
Clicking "Close" on each individual dialog should close only the specific tab confirmed for closure.
Bug: The Address Bar flickers when the Yelp suggestions are removed after using the "Show less frequently" option
Status: RESOLVED
Priority: P3
Resolution: DUPLICATE
Created: 2024-02-23 12:30:29+00:00
Resolved: 2024-02-27 05:51:15+00:00

**[Affected versions]:**
- Firefox Nightly 125.0a1 - Build ID: 20240222103314
- Firefox Beta 124.0b2 - Build ID: 20240221091558

**[Affected Platforms]:**
- Windows 10 x64
- macOS 12.6.1
- Linux Ubuntu 20.04 x64

**[Prerequisites]:**
- Have the following prefs set with the values to enable the feature:
`browser.search.region` = US (connect to a VPN server if outside the US)
`nimbus.debug` = true
- Switch to the Stage server using the Remote Settings Devtools [addon](https://github.com/mozilla-extensions/remote-settings-devtools/releases).

**[Steps to reproduce]:**
1. Open the browser with the profile from the prerequisites.
2. Copy and paste the following link in order to force enroll in the Yelp suggestions experiment: 
`about:studies?optin_slug=qa-2280-yelp-suggestions-qa&optin_branch=treatment-top-pick&optin_collection=nimbus-preview`
3. Restart the browser. 
4. Type the “break” string in the Address Bar.
(note: remove Sponsored and Non-sponsored results if displayed instead of the Yelp suggestion)
5. Click the “Feedback” button from the Yelp suggestion.
6. Click the “Show less frequently” option.
7. Click outside the Address Bar panel.
8. Click inside the Address Bar panel.
9. Observe the behavior.

**[Expected result]:**
- The Yelp suggestion is no longer displayed.

**[Actual result]:**
- The Yelp suggestion is displayed for a split second.

**[Notes]:**
- This issue affects Yelp results displayed on both Top Pick and Firefox Suggest locations.
- For the Firefox Suggestion location, the flicker is more visible when triggering a Yelp suggestion, focusing it, closing the Address Bar panel, and then focusing the Address Bar.
- Here is a [screen recording](https://drive.google.com/file/d/1VuwAGgm5OwW1gXGxFPpLEnn7y667WNnU/view?usp=sharing) of the issue.
Bug: Voice Over will not read highlighted text during editing inside a PDF
Status: VERIFIED
Priority: P1
Resolution: FIXED
Created: 2024-02-23 12:34:15+00:00
Resolved: 2024-03-18 10:38:53+00:00

**Found in**
* Nightly 125.0a1 (2024-02-23)

**Affected versions**
* Nightly 125.0a1 (2024-02-23)
* Beta 124.0b2
* Release 123

**Affected platforms**
* macOS

**Steps to reproduce**
1. Open any PDF in Firefox.
2. Enable the Highlight tool.
3. Highlight Any Random text.
4. Use Voice over to reach the highlighted text.

**Expected result**
* Voice over should read the Highlighted text.

**Actual result**
* The Highlighted text is read as image.

**Regression range**
Not a Regression
Bug: NVDA and Voice Over will Focus on the Highlights first instead of the text from the PDF
Status: VERIFIED
Priority: --
Resolution: FIXED
Created: 2024-02-23 12:41:09+00:00
Resolved: 2024-05-30 00:49:43+00:00

**Found in**
* Nightly 125.0a1 (2024-02-23)

**Affected versions**
* Nightly 125.0a1 (2024-02-23)
* Beta 124.0b2
* Release 123

**Affected platforms**
* macOS

**Preconditions:**
Enable Voice Over

**Steps to reproduce**
1. Open any PDF in Firefox.
2. Enable the Highlight tool.
3. Highlight Any Random pieces of text from the PDF file.
4. Use Voice over to reach the First line of text from the PDF.

**Expected result**
* User should reach the text as if none of it is Highlighted. 
Voice Over should probably ignore the Highlights or when it reaches the Highlighted text it should say the text + the fact that its highlighted. 

**Actual result**
* The Voice over will reach the Highlights first until the end of the document and then it will start reading from the First line.
In a PDF where a user highlights multiple different rows of text, will be a bit harder for them to navigate through it with Voice over commands.

**Regression range**
Not a Regression