av9ash/GitBugs huggingface dataset:
Bug: The pdf viewer's document outline section does not link to pages
Status: VERIFIED
Priority: --
Resolution: FIXED
Created: 2024-07-10 03:02:31+00:00
Resolved: 2024-09-24 07:43:43+00:00

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

Steps to reproduce:

After updating to 127 I opened a pdf of a textbook with the first section of page numbers as roman numerals. I then clicked on a section that was on a page with an arabic numeral page number labeled in the document outline section on the left of the viewer.


Actual results:

The document outline does not jump to pages that are not numbered with roman numerals. 


Expected results:

The viewer should have gone to the section that is labeled in the document outline. The same pdf works correctly in version 126.
Bug: Intermittent blank page display during PDF zoom transitions
Status: NEW
Priority: --
Created: 2024-07-10 07:20:26+00:00
Resolved: 2024-08-22 00:09:26+00:00

**Found in**
* 129.0b1

**Affected versions**
* 130.0a1 (2024-07-09)
* 129.0b1
* 128.0
* 128.0esr

**Tested platforms**
* Affected platforms: macOS 14.4, Windows 11, Ubuntu 22.04 
* Unaffected platforms: none

**Steps to reproduce**
1. Access https://bugzilla.mozilla.org/attachment.cgi?id=8792203 
2. Zoom in and out several times using the zoom buttons or key combination (ctrl/cmd + -)
3. Observe the content of the PDF while zooming in and out

**Expected result**
* PDF content is correctly displayed when zooming in and out, without any rendering issues

**Actual result**
* PDF content displays a blank page for a brief second when zooming in and out at certain zoom levels

**Regression range**
* Last good build: 2024-01-05
* First bad build: 2023-01-06
* Potentially regressed by: Mozregression pointed to bug 1868928 on Windows 11, but I am uncertain if this is the actual regressor or not, as the issue is intermittent. 

**Additional notes**
* See the attached video
* Reproducing with hardware acceleration disabled and enabled as well
* This was initially fixed in bug 1661253
Bug: On Firefox 127 on Android, the embedded website can get the current website as referer
Status: RESOLVED
Priority: --
Resolution: INVALID
Created: 2024-07-10 07:46:27+00:00
Resolved: 2024-07-11 19:48:17+00:00

User Agent: Mozilla/5.0 (Linux; Android 10; K) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/126.0.0.0 Mobile Safari/537.36

Steps to reproduce:

Load http://cm2.pw/poc/referrer, the embedded website https://raw.cm2.pw can get the current website http://cm2.pw/poc/referrer as referer.


Actual results:

The embedded website can know which website embeds the embedded website.


Expected results:

I read around that this is a security bug.
Bug: Allow using shift-enter/shift-click to open the search engine page without a search from the search bar (was: Nav Bar Search Box No Longer Accepts Bare Carriage Return)
Status: VERIFIED
Priority: P2
Resolution: FIXED
Created: 2024-07-10 10:20:54+00:00
Resolved: 2024-11-23 20:49:09+00:00

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

Steps to reproduce:

Enter a carriage return in the Nav Bar search box.


Actual results:

Nothing.


Expected results:

In all previous releases, when you switched focus to the Nav Bar search box and pressed the enter key, by default you would go to your selected search engine's default search page.

Now, with the release of 128.0, unless you enter at least a single character in the search box and then press enter, nothing happens.
Bug: about:support fails to load experimental features. Missing genai-settings-chat-title string
Status: VERIFIED
Priority: --
Resolution: FIXED
Created: 2024-07-10 10:28:21+00:00
Resolved: 2024-07-22 07:12:41+00:00

Using my developer build, after opening "about:support" I get the following error in the page console:

> [fluent] Missing message in locale en-US: genai-settings-chat-title support
> [fluent] Couldn't find a message: genai-settings-chat-title support
> stack of snapshot error for about:support:  TypeError: titleL10nObjects[i] is null

and the "Experimental Features" table is empty as a result.

My guess is that bug 1894999 forgot to add `<link rel="localization" href="preview/genai.ftl" />` to `aboutSupport.xhtml`.
Bug: I have double buttons for the bookmarks menu
Status: RESOLVED
Priority: --
Resolution: WORKSFORME
Created: 2024-07-10 12:34:41+00:00
Resolved: 2024-07-19 09:28:40+00:00

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

Steps to reproduce:

When I updated to v128 I got double bookmark menu buttons


Actual results:

When I updated to v128 I got double bookmark menu buttons


Expected results:

I should only have one bookmark menu
Bug: All tab borders are highlighted
Status: VERIFIED
Priority: --
Resolution: FIXED
Created: 2024-07-10 14:31:53+00:00
Resolved: 2024-08-08 12:10:11+00:00

STR:
1. Open Firefox nightly with "Fall Foggy Forest" theme is applied.
2. Open multiple web pages in tabs.

Actual result:
All tab borders are highlighted.

Expected result:
Only active tab border is highlighted.

Additional info:
Tested with the latest Firefox nightly Win64 on Windows 11 x64.
Bug: ESR 128 does not support "browser.tabs.firefox-view" causing the firefox-view button to reappear on old profiles.
Status: RESOLVED
Priority: --
Resolution: WONTFIX
Created: 2024-07-10 15:25:13+00:00
Resolved: 2024-07-24 14:02:11+00:00

Steps to reproduce:

Upgraded from ESR 115 to ESR 128


Actual results:

The firefox-view button reappeared despite setting "browser.tabs.firefox-view" to "false"


Expected results:

The firefox-view button should not have reappeared. System administrators use the "browser.tabs.firefox-view" setting to control firefox-view across multiple systems.
Bug: Missing text in PDF.js when browser.display.use_document_fonts==0
Status: NEW
Priority: P3
Created: 2024-07-10 16:03:25+00:00
Resolved: 2024-10-28 13:44:08+00:00

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

Steps to reproduce:

- In preferences > fonts, uncheck "Allow pages to choose their own fonts, instead of your selections above"
- Try to read a PDF (yet to find a file on which this repros that I can share here)


Actual results:

With some files, all or parts of the text is missing. PDF.js logs a warning: `Web fonts are disabled: unable to use embedded PDF fonts.`, and several others of the form `Warning: getPathGenerator - ignoring character: "Error: Requesting object that isn't resolved yet MS PGothic_path_部.".`

This seems to be intentional:
https://searchfox.org/mozilla-central/rev/0b1d02b2cb5736511139cf0e40b318273e825899/toolkit/components/pdfjs/content/PdfStreamConverter.sys.mjs#353-355
Patching this check out resolves the issue.


Expected results:

All text should be rendered. Using embedded font is probably important to preserve the layout, but there should probably be a separate override anyway.

Note that embedded fonts can already be disabled with `pdfjs.disableFontFace`. In fact, this is what `supportsDocumentFonts == false` does internally.
Bug: Language change menu disappeared
Status: RESOLVED
Priority: --
Resolution: INVALID
Created: 2024-07-10 19:45:24+00:00
Resolved: 2024-07-30 04:31:19+00:00

Steps to reproduce:

visit about:settings, scroll down, search for "Choose the languages used to display menus, messages, and notifications from Firefox."


Actual results:

Not included


Expected results:

Should definitely be included
Bug: version 128.0 links to zip file downloads produce varying results
Status: RESOLVED
Priority: --
Resolution: INCOMPLETE
Created: 2024-07-10 21:50:54+00:00
Resolved: 2024-08-22 12:22:51+00:00

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

Steps to reproduce:

We use Seapine/Perforce's HelixALM issue tracking system and have been for years. We place zip files on issues - and other team members can download them from a link in the attachments - it has always worked flawlessly until today. Only change is Firefox 127.02->128.0. Click on a file link one time and it works as it should opening the zip application (as specified in the settings), but if you click on several links in succession, by the fourth time, the link instead generates an empty tab. The next time, FF generates a pop-up block message despite the site having a registered exception.  


Actual results:

After multiple file downloads at the same site, clicking on the 5th download file link generates a blank tab instead, then the next attempt generates a pop-up blocked message despite the site being in the pop-ups accepted list. Note the following is a typical file download link - with specific site, cookie, attachment, etc obfuscated so this link should not work - I provide it to show its form/structure https://testtrack.anon.com/Scripts/ttcgi.exe?requestType=DownloadAttachment&cookie=ZDYCGJCIAOJHNPEHAODOEMAAAOJFJPPKAPAEEJAIAMAIAMMEH&serverName=Default&symmetricKey=&itemType=1695531732&recordID=17236&reportedByIndex=1&attachID=26406&attachIdx=957&cache_buster=1720646865820&strForDownload=0



Expected results:

The file (zip type) link normally produces an open zip application with the downloaded file ready for unzipping.
Bug: Firefox Nightly keeps crashing when opened (latest version/2024-07-10)
Status: RESOLVED
Priority: --
Resolution: FIXED
Created: 2024-07-11 07:01:31+00:00
Resolved: 2024-07-13 16:56:16+00:00

I've updated FF Nightly today and after restarting the PC it keept crashing when trying to open.

**Regression range:** good: 2024-07-09 / bad: 2024-07-10
**Regression pushlog:** https://hg.mozilla.org/integration/autoland/pushloghtml?fromchange=da6255a8842052aee7d8b728b4af0b98a6cbc30e&tochange=0e3d86bfb0ea9b8cdccbe92755ba98b43b5e992d
Bug: Some windows no longer displaying, though they appear in the Window Tab list
Status: REOPENED
Priority: --
Created: 2024-07-11 08:33:19+00:00
Resolved: 2025-02-04 20:25:44+00:00

Recently, not sure if related to beta release 128.09, some of my windows will no longer reappear in full, even though they are on the Window Menu list. The current window goes part gray as if shifting focus to the window I want to open, but that window does not appear.

 I have regressed back a beta and then reloaded and also updated to 129.0b2, but to no avail. I can open new windows and previous tabs from history. But cannot retrieve the previous set of windows. Only one or to, random, but now always the same.

I am going to reset session again, but with proper name this time and trty to record actions on the screen with the windows issue

I have reverted back to a previous sessionstore.jsonlz4 again no effect
Bug: Open tel: link with target=_blank doesn't trigger the default action
Status: VERIFIED
Priority: --
Resolution: FIXED
Created: 2024-07-11 08:40:37+00:00
Resolved: 2024-08-28 13:28:38+00:00

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

Steps to reproduce:

I have a link:
<a href="tel:0123456789" target="_blank">call me</a>

When I click the link, it does not trigger the action set under settings/applications neither it asks for how to open the tel-link.

When I remove the target or set it to "_self", the link works:
<a href="tel:0123456789">call me</a>


Actual results:

It opened a new blank page with tel:0123456789 in the url-field.


Expected results:

My default application for tel-links should open
Bug: Tooltip displayed on mouseover is not captured the first time Screenshot overlay is enabled
Status: NEW
Priority: P3
Created: 2024-07-11 10:21:24+00:00
Resolved: 2024-07-11 18:54:22+00:00

** Logged as a follow-up to Bug 1905468.

**Found in**
* Firefox 129.0b2

**Affected versions**
* Nightly 130.0a1
* Firefox 129.0b2
* Firefox 128.0
* Firefox 128.0esr
* Firefox 115.13.0

**Tested platforms**
* Affected platforms: macOS 13, Ubuntu 22.04 and Windows 10x64

**Steps to reproduce**
1. Launch Firefox with a new profile.
2. Go to https://www.chartjs.org/docs/latest/samples/tooltip/interactions.html
3. Hover over one of the data points to reveal the little "tooltip".
4. Open screenshots using Ctrl/Cmd+Shift+S and select a region to capture the tooltip.

**Expected result**
* The little "tooltip" should pe captured in the screenshot.

**Actual result**
* The little "tooltip" is not captured in the screenshot the first time the Screenshot overlay is enabled in that session. The second attempt to capture the tooltip is successful. Please see the screen recording for more details.

**Regression range**
* Not a regression.
Bug: Firefox DLP scan not happening after pasting clipboard data in content editable area from another Firefox window
Status: VERIFIED
Priority: P2
Resolution: FIXED
Created: 2024-07-11 11:49:53+00:00
Resolved: 2024-09-11 11:06:44+00:00

**Found in**
* 129.0b2


**Affected versions**
* 130.0a1 (2024-06-10)
* 129.0b2

		


**Tested platforms**
* Affected platforms: Windows 10x64, Windows 11
* Unaffected platforms: macOS, Ubuntu


**Preconditions**
* Download the DLP test assets from https://drive.google.com/file/d/1yjqVRuxdKV3WnO7D2wzMgDXBuYBxUgVw/view
* Create a distribution folder inside the Firefox folder and paste the policies-2.json to it and then rename it to policies.json
* run the DLP agent in CMD using: .\content_analysis_sdk_agent.exe --user --toblock=.*\d{3}-?\d{2}-?\d{4}.* --towarn=.*warn.* --delays=10


**Steps to reproduce**
1. Open https://en.wikipedia.org/wiki/1234567890 and open another Firefox window.
2. In the new window open https://developer.mozilla.org/en-US/docs/Web/HTML/Global_attributes/contenteditable.
3. Copy `123456789` from one window and paste it inside the output area of the second window.


**Expected result** 
* DLP scan is started and the content is not pasted.


**Actual result**
* No DLP scan is happening and the content is pasted.



**Regression range**
* Not a regression. New feature.

**Additional notes**
* Attached a screen recording.
* This is also happening while copying content from another Firefox instance.
* This issue is not reproducible while copying content from Notepad.
Bug: State is not correctly restored from localStorage in duplicated tabs
Status: RESOLVED
Priority: --
Resolution: DUPLICATE
Created: 2024-07-11 12:30:34+00:00
Resolved: 2024-07-11 20:59:43+00:00

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

Steps to reproduce:

1. Open the attached HTML file in Firefox.
2. Select "Dark" from the dropdown.
3. Click the button to activate it.
4. Duplicate the tab (right-click the tab and select "Duplicate Tab").


Actual results:

The duplicated tab shows the "Dark" option selected, but the body element does not have a black background. The button is not in an active state.


Expected results:

The duplicated tab should show the same state as the original tab: "Dark" option selected, body element with a black background, and the button in an active state with an aqua background.
Bug: "Duplicate Tab" tab context menu behavior diverges from other browsers when it comes to the ordering of "visibilitychange" events which can result in duplicated tabs not having the same state under Firefox (but they would in other browsers)
Status: NEW
Priority: P3
Created: 2024-07-11 14:01:00+00:00
Resolved: 2024-07-23 17:05:06+00:00

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

Steps to reproduce:

1. Open the attached HTML file in Firefox.
2. Select "Dark" from the dropdown.
3. Click the button to activate it. This should show the span.
4. Duplicate the tab (right-click the tab and select "Duplicate Tab").


Actual results:

When duplicating a tab in Firefox, the state stored in localStorage is not correctly applied to the DOM elements. The duplicated tab shows the "Dark" option selected, but the body element does not have a black background. The button is not in an active state, and the span is not shown. This issue does not occur in other browsers such as Chrome or Edge.


Expected results:

The duplicated tab should show the same state as the original tab: "Dark" option selected, body element with a black background, button in an active state with an aqua background, and the span should be visible.
Bug: Firefox 128 x64 MSI installs to Program Files (x86)
Status: RESOLVED
Priority: --
Resolution: INVALID
Created: 2024-07-11 15:04:39+00:00
Resolved: 2024-07-17 16:10:56+00:00

Steps to reproduce:

1) download <https://ftp.mozilla.org/pub/firefox/releases/128.0/win64/en-US/Firefox%20Setup%20128.0.msi>
2) install
3) check <%ProgramFiles(x86)%\Mozilla Firefox>


Actual results:

Instead of installing overtop 127.0.2 in <%ProgramFiles%\Mozilla Firefox>, it installed fresh 32-bit binary to <%ProgramFiles(x86)%\Mozilla Firefox>.


Expected results:

It should have installed the 64-bit version.
Bug: Tab hover preview does not appear when pressing "esc" to dismiss another panel while hovered over a tab
Status: NEW
Priority: P5
Created: 2024-07-11 16:08:10+00:00
Resolved: 2024-07-25 16:02:55+00:00

Found in latest nightly 129.0a1 on MacOS 14 (though in theory this should affect all platforms).

Expected behaviour: if another panel is dismissed via a keyboard shortcut while the cursor is positioned over a tab, the tab hover preview should immediately open.

Actual behaviour: the tab hover preview does not open. The cursor has to be moved off the tab and back on to activate the panel.
Bug: Slow load of Firefox View
Status: NEW
Priority: P3
Created: 2024-07-11 18:09:12+00:00
Resolved: 2024-07-22 19:36:04+00:00

I noticed when opening Firefox View that it opened slowly. 

Steps to reproduce:

1. Use Firefox and have a lot of open tabs
2. Click Firefox View icon 

What happens:

The feature opens slowly and doesn't feel "native". There is a perceptible delay after clicking and before anything seems to happen on the screen. 

Expected Result:

Given that this is supposed to be a native feature and not a web page on the other side of the world, this should feel fast - if not instant. 

Profile: https://share.firefox.dev/462b1Yj
Bug: Feature callouts close when a tab preview thumbnail panel appears
Status: RESOLVED
Priority: P1
Resolution: DUPLICATE
Created: 2024-07-11 18:44:25+00:00
Resolved: 2024-09-23 17:49:46+00:00

Feature Callouts [currently close](https://searchfox.org/mozilla-central/rev/f7b41fc41c5505db507d076c16961a8da67dd318/browser/components/asrouter/modules/FeatureCallout.sys.mjs#368-378) when another panel appears, to avoid having multiple stacked panels. This has become a bit more problematic with the addition of tab preview thumbnails, which use panel elements and appear on merely hovering a tab. If a callout triggers on opening or selecting a tab, the callout will appear when you do that, but rapidly disappear as your mouse is now hovering a tab, resulting in a flash and a "false impression."

I'm not sure what will happen if we add an exclusion to that logic for tab preview thumbnails. Would feature callouts stack above or below them? Would be good to test this, but even if there's some z-fighting, I think it's still better than what we have now.

Also, we want the whole "close when a panel opens" behavior to be configurable, because we plan to run experiments where feature callouts are actually anchored to elements inside other panels, like highlighting a search engine button within the upcoming Unified Search Button menu. For that kind of thing to work well, we may need to provide a property that allows callouts to opt out of this auto-close behavior in the switch statement. So we might as well do that here while we're modifying the switch statement.

This has the potential to create a pretty bad user experience and really mess up experiment results, so I want to suggest P1, S3. Thankfully tab previews are restricted to Nightly for now, but probably not for long.
Bug: Home and newtab compact topsites card hover padding
Status: VERIFIED
Priority: P1
Resolution: FIXED
Created: 2024-07-11 18:54:03+00:00
Resolved: 2024-07-18 12:04:15+00:00

If you hover over a topsite with browser.newtabpage.activity-stream.discoverystream.thumbsUpDown.searchTopsitesCompact set to true, there is a bit of padding work that could be done to improve it.
Bug: Visiting accounts.firefox.com while connected to sync asks you to log in.
Status: NEW
Priority: P3
Created: 2024-07-11 19:32:14+00:00
Resolved: 2024-08-30 14:18:51+00:00

If you are signed in to the browser/sync, and manually enter accounts.firefox.com in your browser, you are prompted to sign in. I'm sure that in the past this was not true, but not sure exactly when that changed.

This is similar to bug 1906152, but different in that "manage account" on Desktop does work correctly.
Bug: "Reopen Closed Tab" does nothing. The windows list in sessionstore-backups/recovery.jsonlz4 is always empty, albeit cookies in it are saved as usual.
Status: RESOLVED
Priority: --
Resolution: DUPLICATE
Created: 2024-07-11 20:31:51+00:00
Resolved: 2024-07-22 22:42:17+00:00

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

Steps to reproduce:

* Use apt on Ubuntu Focal to update to Firefox 128.0+build2-0ubuntu0.20.04.1.
* Browse the web.
* After a while, Firefox will tell you that you must restart to continue using it. Accept that.
* (Firefox restarts with no windows open.)
* Reopen your websites manually.
* Close a tab accidentially.
* Press Ctrl+Shift+T as usual.
* Wonder that nothing happens.
* Start investigating for real:
* Quit firefox.
* Replace firefox profile with a known-good backup.
* Launch Firefox.
* Disable all add-ons.
* Set start page to about:blank
* Quit firefox.
* Delete session* from your profile, especially sessionstore-backups/.
* Launch firefox.
* Now your only open tab should be about:blank
* Set up a script that monitors your profile's sessionstore-backups/recovery.jsonlz4 for changes to "lastUpdate", "windows" and any mention of "hello".
* Wait a few moments until a new recovery.jsonlz4 is created. It has "windows": [] and no mention of "hello". Also take note of lastUpdate.
* Visit http://www.example.net/ (unencrypted)
* After a few seconds, the lastUpdate value has changed. Windows list is still empty, and no mention of "hello".
* In the the example.net tab, open the JavaScript console and run:  document.cookie = 'test=hello';
* After a few seconds, the lastUpdate value has changed again. Windows list is still empty, and an entry "value": "hello" has appeared. Closer inspection will reveal that this is from a saved cookie.
* Open BugZilla in a new tab.
* Close the example.net tab.
* Press Ctrl+Shift+T. (Nothing happens.)
* Right-click the tab title of the BugZilla tab to open the context menu. Click "Reopen Closed Tab". (Nothing happens.)

I retried with a fresh new profile, and there, everything works as expected.

I still hope we can find a way to somehow convert as much as possible of my known-good profile backup in a way that still can reopen closed tabs.


Actual results:

No visual feedback to my attempts to reopen the closed tab.


Expected results:

A tab opens that loads the website I had just closed.