av9ash/GitBugs huggingface dataset:
Bug: Memory used to store a pdf file isn't released
Status: RESOLVED
Priority: P1
Resolution: FIXED
Created: 2023-01-09 14:16:21+00:00
Resolved: 2023-01-12 13:15:42+00:00

STR:
 - download the file https://bibliotekacyfrowa.ujk.edu.pl//Content/4430/PDF/475183.pdf
 - open it in Firefox
 - open devtools, Memory and take a snapshot
 - around 200Mb should be used
 - open about:memory, perform a GC and take an other snapshot: still 200Mb is used

In looking a the Dominators view in the devtools, it seems that a ref on the file is kept by the closure:
https://github.com/mozilla/pdf.js/blob/067d3b70aa46e1b2a3dff768c36ff5ba670407f2/web/app.js#L949

In digging into the code, I think we should use the `transfers` parameter in `sendWithPromise`:
https://github.com/mozilla/pdf.js/blob/067d3b70aa46e1b2a3dff768c36ff5ba670407f2/src/display/api.js#L516-L546

to pass the buffer associated with `source.data` (and probably with `source.initialData` either) as `transferable`.
It should make the transfer faster and it'll avoid the memory leak (I verified and it works).

:Snuffleupagus, do you see any drawbacks to do that ? Do you know if there are other places where we could transfer data instead of copying them ?
Bug: Weather suggestions should respect regional locale preferences for C/F
Status: VERIFIED
Priority: P2
Resolution: FIXED
Created: 2023-01-09 17:40:48+00:00
Resolved: 2023-05-02 13:34:21+00:00

There's a checkbox in about:preferences [labeled](https://searchfox.org/mozilla-central/rev/d62c4c4d5547064487006a1506287da394b64724/browser/locales/en-US/browser/preferences/preferences.ftl#324) "Use your operating system settings for “{ $localeName }” to format dates, times, numbers, and measurements." (Seems like it might be visible only if some other locale setting doesn't match the system locale, maybe the preferred web page locale settings?)

AFAICT this pref applies to the app chrome and not (only?) web pages, so the weather suggestion UI should respect it and it should override `Services.locale.appLocaleAsBCP47`, which is what the weather UI [currently uses](https://searchfox.org/mozilla-central/rev/d62c4c4d5547064487006a1506287da394b64724/browser/components/urlbar/UrlbarProviderQuickSuggest.sys.mjs#718). The pref is [exposed in the locale service API](https://searchfox.org/mozilla-central/rev/d62c4c4d5547064487006a1506287da394b64724/intl/locale/LocaleService.cpp#488) as [regionalPrefsLocales](https://searchfox.org/mozilla-central/rev/d62c4c4d5547064487006a1506287da394b64724/intl/locale/mozILocaleService.idl#87-98).
Bug: browser_bug1184989_prevent_scrolling_when_preferences_flipped.js fails on windows 11
Status: RESOLVED
Priority: P3
Resolution: FIXED
Created: 2023-01-09 23:41:27+00:00
Resolved: 2023-02-17 15:08:25+00:00

I am working to get all our tests running on windows11, currently they run on windows10.  In doing so a few tests require some attention.  

you can see here:
https://treeherder.mozilla.org/jobs?repo=try&tier=1%2C2%2C3&revision=d1433bf8663418bb320b6f2ca60494cfc70e6ad6&searchStr=bc1&selectedTaskRun=cdE-3u0PTiOIwb-4ALjaGQ.0

this fails every time we run it with:
```
task 2023-01-09T22:49:47.079Z] 22:49:47     INFO - TEST-PASS | browser/components/preferences/tests/browser_bug1184989_prevent_scrolling_when_preferences_flipped.js | Page should not scroll when radio flipped - 
[task 2023-01-09T22:49:47.080Z] 22:49:47     INFO - TEST-PASS | browser/components/preferences/tests/browser_bug1184989_prevent_scrolling_when_preferences_flipped.js | Search engineList is selected - 
[task 2023-01-09T22:49:47.080Z] 22:49:47     INFO - Buffered messages finished
[task 2023-01-09T22:49:47.081Z] 22:49:47     INFO - TEST-UNEXPECTED-FAIL | browser/components/preferences/tests/browser_bug1184989_prevent_scrolling_when_preferences_flipped.js | Page should not scroll when search engineList flipped - Got 437, expected +0
[task 2023-01-09T22:49:47.081Z] 22:49:47     INFO - Stack trace:
[task 2023-01-09T22:49:47.081Z] 22:49:47     INFO - chrome://mochikit/content/browser-test.js:test_is:1477
[task 2023-01-09T22:49:47.081Z] 22:49:47     INFO - chrome://mochitests/content/browser/browser/components/preferences/tests/browser_bug1184989_prevent_scrolling_when_preferences_flipped.js:checkPageScrolling/</<:97
```

I am not sure if there is something to adjust at the OS level, the test itself, the browser, or just skip the test on windows.
Bug: Combined toolbarbutton separators not showing in widget overflow list
Status: NEW
Priority: P5
Created: 2023-01-10 03:27:22+00:00
Resolved: 2023-03-07 18:43:14+00:00

### STR
1. In customize mode, add the zoom controls item to the overflow list
2. Exit customize mode
3. Open the overflow list

### Expected
Vertical separators between the three buttons

### Actual
Separator dimensions are 1x0
Bug: Expanded address bar “Switch to Tab” button color differs between generated and privileged themes
Status: RESOLVED
Priority: --
Resolution: WONTFIX
Created: 2023-01-10 11:00:38+00:00
Resolved: 2023-01-13 17:53:13+00:00

Description:
The “Switch to Tab” from the expanded address bar has a different color when using a generated theme as opposed to when using a privileged theme.

Steps to reproduce:
1. Prepare two instances of Nightly with new profiles
2. Access about:config on both and set `extensions.experiments.enable` to `true`
3. Restart the browsers to apply the above pref
4. Load a pair of the same generated and privileged theme in the browsers via about:debugging
5. For the “Switch to tab” button to appear, open https://www.wikipedia.org/ in a new tab and then click the address bar to reveal the expanded address bar and the button
6. Observe the difference between the color of the button while using the generated/privileged themes

Actual:
Generated themes “Switch to tab” button color is different from the one used by the privileged theme.

Expected:
Generated theme “Switch to tab” button should use the same color as in the case of the privileged theme.
Bug: “Protections” panel “🛈” button hovered state color and “Enhanced Tracking Protection” switch accent color around circle in switch differs between generated and privileged themes
Status: RESOLVED
Priority: --
Resolution: WONTFIX
Created: 2023-01-10 11:24:36+00:00
Resolved: 2023-01-13 17:53:44+00:00

Description:
1. The “🛈” button from the “Protections” panel (shield icon in address bar) has a different color when hovered over when using generated themes as opposed to privileged themes
2. The accent color around the white circle inside the “Enhanced Tracking Protection” switch has a different color when using generated themes as opposed to privileged themes

Steps to reproduce:
1. Prepare two instances of Nightly with new profiles
2. Access about:config on both and set `extensions.experiments.enable` to `true`
3. Restart the browsers to apply the above pref
4. Load a pair of the same generated and privileged theme in the browsers via about:debugging
5. Open the “Protections” panel and hover over the “🛈” button. Observe the difference between the hovered state color of the button while using the generated/privileged themes
6. Observe the difference between the color around the white circle inside the “Enhanced Tracking Protection” switch while using the generated/privileged themes

Actual:
1. The generated theme “🛈” button hovered state color is different from the one used by the privileged theme.
2. The generated theme accent color around the white circle inside the “Enhanced Tracking Protection” switch is different from the one used by the privileged theme.

Expected:
1. The generated theme “🛈” button hovered state color should be the same as the one used by the privileged theme.
2.  The generated theme accent color around the white circle inside the “Enhanced Tracking Protection” switch should be the same as the one used by the privileged theme.
Bug: [Experiment] The profile is unenrolled from the PDFjs Feature Callout experiment after an action is performed on the first callout message
Status: RESOLVED
Priority: P2
Resolution: WONTFIX
Created: 2023-01-10 14:04:33+00:00
Resolved: 2023-07-20 23:07:16+00:00

**[Notes]:**
- This doesn't seem to be a Nimbus bug, but it is affecting the experiment. This happens because the "browser.pdfjs.feature-tour" is changed to a different value after performing an action on the CFR panel. For example, if the user is enrolled in the treatment a or b branch and the CFR panel is displayed, if they dismiss the panel, or navigate to the next slide, the pref will have a new value and the user will be automatically unenrolled from the experiment with the reason "changed-pref". 
- While this is the expected behavior of Nimbus pref configurations, we consider that the experiment would be affected by this interaction.

**[Affected versions]:**
- Firefox 109 RC BuildID 20230109161414.
- Firefox Nightly 110.0a1 BuildID 20230109212101.

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

**[Prerequisites]:**
- Have the “nimbus.debug” pref set to true.
 
**[Steps to reproduce]:**
1. Open the Firefox browser with the profile from the prerequisites.
2. Navigate to [Treatment A](about:studies?optin_slug=pdfjs-feature-callout&optin_branch=treatment-a&optin_collection=nimbus-preview) or [Treatment B](about:studies?optin_slug=pdfjs-feature-callout&optin_branch=treatment-b&optin_collection=nimbus-preview) link in order to force enroll in the experiment.
3. Navigate to https://www.clickdimensions.com/links/TestPDFfile.pdf.
4. Click the "Next" button from the CFR panel.
5. Navigate to the about:studies page.
6. Observe the PDFjs Feature Callout experiment.

**[Expected result]:**
- The experiment is not marked as complete.

**[Actual result]:**
- The experiment is marked as complete.

**[Additional Notes]:**
- The issue is also reproducible when enrolling in the experiment naturally.
- Attached is a screen recording of the issue.
Bug: cannot delete or copy bookmarks in bookmark manager
Status: RESOLVED
Priority: --
Resolution: INCOMPLETE
Created: 2023-01-10 14:22:28+00:00
Resolved: 2023-06-23 08:06:10+00:00

Steps to reproduce:

Opened manage bookmarks
Created a new folder
Dragged bookmark from one folder to another in the folder tree

Next, tried to copy and paste bookmark


Actual results:

Nothing happened, bookmarks did not change folder locations


Expected results:

Bookmark should have been moved from previous folder (Bookmark Toolbar) to new folder
Bug: Failed to save PDF annotations (Error when saving the document: this.parent is null)
Status: RESOLVED
Priority: --
Resolution: FIXED
Created: 2023-01-10 15:46:35+00:00
Resolved: 2023-01-10 18:54:12+00:00

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

Steps to reproduce:

1. Open a PDF file which is long enough (mine is 34 pages).
2. Make an annotation on the first page.
3. Scroll to the last page.
4. Press Ctrl+S and save the annotated PDF.


Actual results:

1. The annotation is NOT saved.
2. There is an error log in the console:
```
Error when saving the document: this.parent is null viewer.js:1914:15
    save resource://pdf.js/web/viewer.js:1914
    downloadOrSave resource://pdf.js/web/viewer.js:1931
    webViewerDownload resource://pdf.js/web/viewer.js:2842
    dispatch resource://pdf.js/web/viewer.js:3373
    handleEvent resource://pdf.js/web/viewer.js:11932
```

It's probably because the page where the annotation locates has been unloaded. If I scroll to where I made the annotation, the annotated PDF can be saved successfully.



Expected results:

The PDF annotation should be saved, and no error should occur.
Bug: test_punycodeURIs times out when run from an MSIX package
Status: NEW
Priority: P5
Created: 2023-01-10 17:22:02+00:00
Resolved: 2023-02-02 11:32:06+00:00

```
[task 2023-01-09T14:43:08.720Z] 14:43:08     INFO -  TEST-START | uriloader/exthandler/tests/unit/test_punycodeURIs.js
[task 2023-01-09T14:48:08.732Z] 14:48:08     INFO -  TEST-TIMEOUT | uriloader/exthandler/tests/unit/test_punycodeURIs.js | took 300013ms
[task 2023-01-09T14:48:08.737Z] 14:48:08     INFO -  xpcshell return code: None
```

Full log is available at https://treeherder.mozilla.org/jobs?repo=try&author=bhearsum%40mozilla.com&test_paths=uriloader%2Fexthandler%2Ftests%2Funit&fromchange=06efba7b77357f173e0eeedcda35960c81a4575c&selectedTaskRun=LH2IYjFSR2KmHm4cbI90JA.0 (although there's really nothing of note there).

If I had to guess, I'd say it's probably having trouble finding or launching at https://searchfox.org/mozilla-central/rev/a156a65ced2dae5913ae35a68e9445b8ee7ca457/uriloader/exthandler/tests/unit/test_punycodeURIs.js#122, as things are a little bit different inside of an MSIX environment for two reasons:
1) We cannot write to the install directory (which means we can't put support files there)
2) We run xpcshell tests through `firefox.exe -xpcshell`, so any assumptions made about the currently running process may not be valid.
Bug: Dynamic blocklist entry shows up for all users on about:third-party page
Status: VERIFIED
Priority: --
Resolution: FIXED
Created: 2023-01-10 19:20:33+00:00
Resolved: 2023-01-17 12:31:36+00:00

For testing purposes, an entry is added to the dynamic blocklist with the name "TestDllBlocklist_UserBlocked.dll". Right now this shows up for all users on about:third-party - we should instead only add it to the blocklist when tests are running.
Bug: Firefox doesn't ask where to save files I download
Status: RESOLVED
Priority: --
Resolution: INCOMPLETE
Created: 2023-01-10 23:54:22+00:00
Resolved: 2023-02-03 16:06:25+00:00

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

Steps to reproduce:

When I download a file, it goes directly to my Downloads folder. In my settings under General - Files and Applications - Downloads, I have the box checked next to "Always ask you where to save files" which doesn't appear to work. I have version 108.0.2 (64-bit) for my personal computer. I also use Firefox at work with a different computer with version 108.0.1 and the same thing happens - I also have the settings on my work computer set with the box checked next to "Always ask you where to save files". 

After performing lots and lots of searches, I found a workaround by going to about:config and setting "browser.download.improvements_to_download_panel" to false. 

Any way to know if this issue will be fixed?

Thanks.

User Agent on both work and personal: 
Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:108.0) Gecko/20100101 Firefox/108.0
Bug: Firefox doesn't reopen tabs when program/computer crashes
Status: RESOLVED
Priority: --
Resolution: DUPLICATE
Created: 2023-01-11 03:20:45+00:00
Resolved: 2023-12-08 17:23:44+00:00

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

Steps to reproduce:

After computer crashes, I reopen Firefox after computer is restarted.


Actual results:

Firefox opens without previous tabs open, even though when it normally closes under normal circumstances the tabs do reopen.  

When I go to the History - Recently Closed Tabs, the tabs don't appear to be reopened.  If I Manage History, older tabs appear but it is ALL  the older tabs used prior & not just the ones that were open when the program crashed with the computer.


Expected results:

All tabs that were previously open should have reopened.  And in the Recently Closed Tabs, the recent tabs that were open should be listed so they can be reopened.
Bug: pdf obfuscated viewed in internal PDF Viewer for Windows, but external is working
Status: RESOLVED
Priority: --
Resolution: DUPLICATE
Created: 2023-01-11 10:22:36+00:00
Resolved: 2023-01-11 10:38:39+00:00

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

Steps to reproduce:

viewing a web generated pdf file (attached)

The pdf was created by ghostscript by merging a wkhtml generated pdf and some Adobe Acrobat pdf files ( pages 3+ )


Actual results:

What happens next depends on who processes it for a view:

Under Linux, everything works in any tested app ( XPDF, Inkscape, Chrome, Firefox, Evince )
Under Windows, with the same FF release 108, the internal viewer can't display pages 3+ . The same file, opened with Adobe or any other external viewer can display those pages. 



Expected results:

flawless display of page 3+
Bug: Queuing additional dialogs in TabDialogBox breaks layout of top dialog
Status: RESOLVED
Priority: --
Resolution: FIXED
Created: 2023-01-11 12:17:59+00:00
Resolved: 2023-01-13 19:36:56+00:00

STR:
1. Open https://jigsaw.w3.org/HTTP/Basic/ and wait for the auth prompt to appear.
2. Keep the auth prompt open and navigate to a URL which triggers another prompt with different dimensions, e.g. `evil@eviltrap.site` will show the confirm-auth dialog.

Expected result:
The confirm-auth dialog should be queued behind the basic auth dialog. The basic auth dialog should not change.

Actual result:
When the confirm-auth dialog opens in the background the dimensions of the basic auth dialog are updated resulting in some content getting cut-off.

This probably affects other dialogs shown via the TabDialogBox too.

This seems to be a regression of Bug 1789168. Mozregression result:
```
 5:04.71 INFO: Last good revision: dd74d4159c5dfa4307f663df24cf64766a4d5781
 5:04.71 INFO: First bad revision: 61cde6b6f2737eee00c49fb75390aff3d814f677
 5:04.71 INFO: Pushlog:
https://hg.mozilla.org/integration/autoland/pushloghtml?fromchange=dd74d4159c5dfa4307f663df24cf64766a4d5781&tochange=61cde6b6f2737eee00c49fb75390aff3d814f677
```

Emilio, could you take a look? Thanks!
Bug: Create Bookmark popup disappears after 5 seconds
Status: NEW
Priority: P3
Created: 2023-01-11 23:10:06+00:00
Resolved: 2025-01-24 16:09:58+00:00

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

Steps to reproduce:

1. CTRL+D
2. Create New Bookmark popup opens.


Actual results:

After a number of seconds, the popup disappears by itself.


Expected results:

If I have mobility issues and it takes a long time for me to interract with my computer, such as it being physically difficult to move the mouse cursor in a steady, controlled and timely manner, or requiring other assistive technologies, then it would take a long time and many tries for me to reliably interact with the bookmark dialog window.

Largely, it would then be impossible for me to properly create a new bookmark, as the bookmark dialog window would always automatically close on me. This is both disheartening and extremely frustrating.

It is unacceptable as an accessibility issue, and precludes the normal use of this feature.

Please remove the auto-closing logic on the Create Bookmark popup.
Bug: Bookmark search shows stale results after updating one of them
Status: RESOLVED
Priority: --
Resolution: INCOMPLETE
Created: 2023-01-12 04:59:15+00:00
Resolved: 2023-02-13 15:24:33+00:00

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

Steps to reproduce:

1. Open bookmark menu.
2. Enter search term.
3. Ensure hit is found.
4. Edit hit.
5. Change the URL.
6. Save hit.
7. Edit hit again.
8. Observe old URL.


Actual results:

The bookmark search results are stale. If you edit one of them, then go to edit again, it does not contain the updated values.

Need to clear and re-search to get updated values.

If you need to make multiple edits, you'll have to keep appyling ALL edits every single time, or keep redoing the search after every edit.


Expected results:

The bookmark search results should show the bookmarks' current data.
Bug: URL bar remains blank until after the page loads
Status: RESOLVED
Priority: --
Resolution: DUPLICATE
Created: 2023-01-12 05:13:12+00:00
Resolved: 2023-02-27 10:28:49+00:00

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

Steps to reproduce:

Via Bookmarks:
1. Save a bookmark to any address that either times out or is very slow.
2. Open the bookmark.
3. Observe the URL bar is blank when loading starts.
4. After the page has resolved, observe the URL bar gets populated.

Via Reopen Tab:
1. Navigate to any address that either times out or is very slow.
2. When loading has finished, close the tab/window.
3. Reopen the tab/window.
4. Observe the URL bar is blank when loading starts.
5. After the page has resolved, observe the URL bar gets populated.

Example unresolvable address:
https://abc/


Actual results:

The URL bar remains blank until the page resolves.
This blocks all possibility to edit the address during loading (such as running a bookmark, then going to add parameters or change the subdomain).
This blocks all possibility to copy the address of the tab without having to wait for it to timeout/resolve.

Screenshot attached of running a bookmark to a localhost address that is slow to resolve. Taken just after executing the bookmark and loading started.


Expected results:

When navigation starts, the URL bar should be populated.
Bug: Bypass PopUp Blocker click Mouse or Keyboard
Status: RESOLVED
Priority: --
Resolution: INVALID
Created: 2023-01-12 10:39:02+00:00
Resolved: 2024-05-30 18:03:45+00:00

- Summary 

By creating and dispatching click space keyboard or  mouse click event after clik script , the popup blocker can be bypassed and any URL can be opened in a new window.

- Reproduce 

Firefox Browser Desktop Version : 108.0.2 (64-bit)

For testing this script in this website : https://iecoop.id/ppblock/

Testing in Safari Browser is Block popup

Thanks
Bug: inspect() does not bust cache when fetching the latest changes from server
Status: RESOLVED
Priority: --
Resolution: FIXED
Created: 2023-01-12 13:32:12+00:00
Resolved: 2023-01-26 13:37:35+00:00

`inspect()` pull the server information, but does not bust cache (it uses `?_expected=0`). 

When using the devtools, the UI compares the server timestamp with the local timestamp.

With the following timeline, the timestamps will be different:

1. `inspect()` fetches the server info. CDN caches the response with `_expected=0` (eg. timetamp=42)
1. a change is published on server, client syncs (eg. timestamp=99)
1. CDN caches the latest the response with `_expected=99`
1. `inspect()` fetches the server info, but obtains the cached response with `_expected=0` 
1. the two obtained timestamps are different whereas the client is up-to-date

We should bust the cache in `inspect()`.

Since it's only used by DevTools (directly or via `clearAll()`), we don't risk anything with regards to the server traffic
Bug: Unable to delete top result in Firefox Suggest Address Bar
Status: RESOLVED
Priority: --
Resolution: WORKSFORME
Created: 2023-01-12 15:13:36+00:00
Resolved: 2023-01-12 16:55:06+00:00

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

Steps to reproduce:

Currently airbnb.com.au is the top result when I start to type airbnb in the address bar.  I'm based in the US but was using the .com.au site for a bit. 

1. I've cleared my entire history of any reference to airbnb.com.au for all time. 
2. I've deleted all airbnb.com.au bookmarks
3. I've toggled of Firefox Suggest Address Bar in settings
4. I've tried restarting the browser multiple times. 


Actual results:

airbnb.com.au is still the top suggestion


Expected results:

No suggestion of airbnb.com.au should've been made.