av9ash/GitBugs huggingface dataset:
Bug: A cookie issue in Private Browsing on 111.0b1 and 112.0a1 (2023-02-15) (macOS)
Status: RESOLVED
Priority: --
Resolution: INVALID
Created: 2023-02-16 10:23:16+00:00
Resolved: 2023-02-16 11:11:09+00:00

User Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10_15_7) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/110.0.0.0 Safari/537.36

Steps to reproduce:

On macOS Ventura 13.1, on Firefox 111.0b1 and 112.0a1 (2023-02-15):

Create an online .html file:

<!DOCTYPE html>
<html>
<head>
<script>
function setCookie(cname,cvalue,exdays) {
  const d = new Date();
  d.setTime(d.getTime() + (exdays*24*60*60*1000));
  let expires = "expires=" + d.toUTCString();
  document.cookie = cname + "=" + cvalue + ";" + expires + "; path=/";
}

function getCookie(cname) {
  let name = cname + "=";
  let decodedCookie = decodeURIComponent(document.cookie);
  let ca = decodedCookie.split(';');
  for(let i = 0; i < ca.length; i++) {
    let c = ca[i];
    while (c.charAt(0) == ' ') {
      c = c.substring(1);
    }
    if (c.indexOf(name) == 0) {
      return c.substring(name.length, c.length);
    }
  }
  return "";
}

function checkCookie() {
  let user = getCookie("username");
  if (user != "") {
    alert("Welcome again " + user);
  } else {
     user = prompt("Please enter your name:","");
     if (user != "" && user != null) {
       setCookie("username", user, 30);
     }
  }
}
</script>
</head>

<body onload="checkCookie()"></body>

</html>

Open a New Private Window, load it:

https://duckhiemblogger.blogspot.com/2023/02/function-setcookiecnamecvalueexdays_16.html

Enter a string.

Close the tab, open a new tab in the Private Window, load it again:

https://duckhiemblogger.blogspot.com/2023/02/function-setcookiecnamecvalueexdays_16.html




Actual results:

The second tab can get the cookie entered in the first tab in Private Window.


Expected results:

This https://support.mozilla.org/en-US/kb/private-browsing-use-firefox-without-history states: Private Browsing does not save your browsing information, such as history and cookies, so that, the fact that we need to close the Private Window to clear all set cookies in the private browsing session?
Bug: The behavior https://bugzilla.mozilla.org/show_bug.cgi?id=1811181 happens in Private Window on 111.0b1 (macOS)
Status: RESOLVED
Priority: --
Resolution: DUPLICATE
Created: 2023-02-16 10:31:16+00:00
Resolved: 2023-10-30 19:18:40+00:00

User Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10_15_7) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/110.0.0.0 Safari/537.36

Steps to reproduce:

On macOS Ventura 13.1, open a Private Window in Firefox 111.0b1, load the first file, grant the permission, in the same tab, load the second file, the permission in granted automatically.


Actual results:

In Private Window in Firefox 111.0b1, in the same tab, the second file can get the permission automatically.


Expected results:

I think Private Browsing should prevent something.
Bug: Delete or Distrust CA Certificates window has increased height
Status: VERIFIED
Priority: P1
Resolution: FIXED
Created: 2023-02-16 12:58:28+00:00
Resolved: 2023-11-07 16:07:14+00:00

**Found in**
* 111.0b1


**Affected versions**
* 112.0a1 (20230216094044)
* 111.0b1
* 110.0



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




**Steps to reproduce**
1. Open Firefox and about:preferences#privacy..
2. Scroll down to the Certificates section and click View Certificates.
 3. Select the Authorities tab and click on a random certificate.
4. Click on Delete or Distrust button and observe the window.

**Expected result**
* Delete or Distrust CA Certificates window is correctly displayed.

**Actual result**
* Delete or Distrust CA Certificates window has increased height.

**Regression range**
* Last good revision: bf1bc477f95d9ca0686bf22e577727d11be616fc
First bad revision: 1e4afe94c89bf0d123accce7f6fe4565be09d5c0
Pushlog:
https://hg.mozilla.org/integration/autoland/pushloghtml?fromchange=bf1bc477f95d9ca0686bf22e577727d11be616fc&tochange=1e4afe94c89bf0d123accce7f6fe4565be09d5c0

**Additional notes**
* Attached a screenshot.
Bug: Disabling top sites or setting maxRichResults to 0 is returning empty results set
Status: VERIFIED
Priority: P2
Resolution: FIXED
Created: 2023-02-16 13:11:24+00:00
Resolved: 2023-03-08 10:09:58+00:00

It is expected that we return empty result sets, but we currently have no insight into that.
We need either to report the preferences status in environment, or add an environment property in each event, so we can cross check user settings that may influence the events.
This is something we must coordinate with Glean team.
Bug: Document that provider will be empty if there's no results
Status: RESOLVED
Priority: P2
Resolution: FIXED
Created: 2023-02-16 13:17:22+00:00
Resolved: 2023-02-22 21:46:03+00:00

It may sound obvious, but it's better to be explicit about it.
if there's no results, and selected_result is empty or a special value (see Bug 1817156) then the `provider` key cannot contain anything and will be null.
Bug: Evaluate how we record interactions with the go button
Status: VERIFIED
Priority: P2
Resolution: FIXED
Created: 2023-02-16 13:23:51+00:00
Resolved: 2023-03-06 14:31:45+00:00

I can reproduce some strange events recording when:
1: type something in urlbar
2: selects a one off button with the keyboard
3: click on the Go button

Apart from checking the returned events are consistent, we should probably have a special go_button engagement_type for the go button?
Bug: Sometimes more than one heuristic is returned
Status: RESOLVED
Priority: P2
Resolution: FIXED
Created: 2023-02-16 13:33:31+00:00
Resolved: 2023-03-13 08:34:11+00:00

I see a few events with more than one heuristic returned
result types are: search_engine,autofill_origin
selected_result is unknown

I wonder if it's some case where we're sending cached/stale results
Bug: Sometimes selected_result is unknown even if there's results
Status: VERIFIED
Priority: P2
Resolution: FIXED
Created: 2023-02-16 13:37:11+00:00
Resolved: 2023-03-23 11:16:44+00:00

I see events where selected_result is unknown, but results contain autofill_origin or search_engine.
There is a string typed.
engagement_type is enter.
Bug: Paste + Select All + Cut copy the content incorrectly
Status: RESOLVED
Priority: P3
Resolution: FIXED
Created: 2023-02-16 15:08:44+00:00
Resolved: 2025-03-05 20:53:15+00:00

Steps to reproduce:

1. Open any webpage
2. Copy some content in the webpage
3. Click the address bar (all the content is now selected)
4. Paste the content by using keyboard
5. Select all by using keyboard
6. Cut by using keyboard


Actual results:

The content in the clipboard is the URL, not the content copied from the website.


Expected results:

The content in the clipboard should be the content copied from the website.
Bug: Firefox ignores the protection of pdf files
Status: RESOLVED
Priority: --
Resolution: DUPLICATE
Created: 2023-02-16 15:25:05+00:00
Resolved: 2023-02-16 16:43:50+00:00

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

Steps to reproduce:

Open a pdf file, which is protected with a password against copying.



Actual results:

Selecting text and pictures in firefox allows copying of the selection to the clipboard and therefore, "destructs"/avoids the protection.

All known to me versions since about 2018 behave similarly in this respect. I was hoping that a patch will correct this, but has not yet happened.

Even worse: under windows 10, printing from firefox to a pdf with the driver "Save to PDF" (I believeit is firefox internal, because I do not see it in the system's print-dialog) removes the protection totally.


Expected results:

Copying should not be possible (except as a screenshot, which cannot be avoided)!
Bug: Order of bookmarks is messed up since 110.0
Status: RESOLVED
Priority: P2
Resolution: FIXED
Created: 2023-02-16 16:16:01+00:00
Resolved: 2023-02-27 14:40:12+00:00

User Agent: Mozilla/5.0 (Windows NT 6.1; rv:109.0) Gecko/20100101 Firefox/110.0

Steps to reproduce:

Since updating to 110.0, the order of bookmarks when typing in address bar is always wrong and clearing history does not fix it. In the past, the order of bookmarks sometimes got messed up if Firefox had been open for some time, but clearing history always fixed it.


Actual results:

Bookmarks are ordered in a weird messed up and seemingly random (but consistent) way, with almost all bookmarks that show up being some really old ones.


Expected results:

Bookmarks should be ordered most recent first, and then in descending order.
Bug: FetchPageDataService should take nsIURI and use loadURI instead of fixupAndLoadURIString
Status: NEW
Priority: P3
Created: 2023-02-16 17:21:57+00:00
Resolved: 2025-02-13 14:24:20+00:00

https://searchfox.org/mozilla-central/rev/b579290e6b830d1b3f0a941203b0c0e1e56c42a3/browser/components/pagedata/PageDataService.sys.mjs#562

AFAICT [there are no non-test consumers](https://searchfox.org/mozilla-central/search?q=.fetchPageData&path=&case=false&regexp=false), [also not for queueing the URLs](https://searchfox.org/mozilla-central/rev/b579290e6b830d1b3f0a941203b0c0e1e56c42a3/browser/components/pagedata/PageDataService.sys.mjs#663). I don't know if this should be removed instead or if we still have plans for it, or if I'm missing something. If we do have plans for it or I'm missing something, updating it and the tests that rely on it should be reasonably straightforward right now?

Dave, do you know what the status of this code is?
Bug: Bookmark list no longer remembers scroll location
Status: RESOLVED
Priority: --
Resolution: DUPLICATE
Created: 2023-02-16 17:56:23+00:00
Resolved: 2023-02-16 20:36:07+00:00

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

Steps to reproduce:

Use the Bookmarks icon or menu-bar entry to open bookmarks list. It is longer than the screen height and scrolls. If I click on and open an entry, after scrolling down, then go back and reopen the list, it has forgotten it was scrolled and opens at the top.


Actual results:

It no longer remembers the scroll location and always opens from the top after clicking an entry to go to that web site.


Expected results:

It should remember the scroll location. Firefox 109 and earlier did this correctly, and I verified on another computer that has not been updated to 110 yet.
Bug: nous avons 4 adresses mail dans Moilla Thunderbird, nous recevons des mails mais impossible d'en envoyer, vous nous envoyez des messages, mais quand je veux signaler un bug, nos adresses sont inconnues!
Status: RESOLVED
Priority: --
Resolution: INCOMPLETE
Created: 2023-02-16 22:10:42+00:00
Resolved: 2023-03-02 23:42:59+00:00

User Agent: Mozilla/5.0 (Windows NT 6.1) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/109.0.0.0 Safari/537.36 Edg/109.0.1518.78
Bug: error in the display of the bookmarks, when scrolling it jumps to the end
Status: RESOLVED
Priority: --
Resolution: DUPLICATE
Created: 2023-02-16 22:20:55+00:00
Resolved: 2023-04-23 19:28:58+00:00

Steps to reproduce:

1. You need a bookmarks folder in the bookmarks toolbar
2. there have to be so many bookmarks that you can scroll several times
3. scroll down to the bottom of the list
4. open a link with the scroll wheel
5. while on the new tab, open the bookmarks folder again


Actual results:

6. the folder is no longer at the end of the list but at the start
7. if you just scroll down a little now, it jumps straight to the end of the list


Expected results:

6. the folder should be at the end of the list as it was left
Bug: Intermittent browser/base/content/test/general/browser_bug676619.js | single tracking bug
Status: RESOLVED
Priority: P5
Resolution: INCOMPLETE
Created: 2023-02-16 22:28:46+00:00
Resolved: 2025-02-03 12:12:22+00:00

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

---
```
[task 2023-02-16T22:02:39.567Z] 22:02:39     INFO - TEST-PASS | browser/base/content/test/general/browser_bug676619.js | file name should match (link2) - 
[task 2023-02-16T22:02:39.568Z] 22:02:39     INFO - Checking link3 with name: just some video.ogg
[task 2023-02-16T22:02:39.568Z] 22:02:39     INFO - Buffered messages finished
[task 2023-02-16T22:02:39.569Z] 22:02:39    ERROR - TEST-UNEXPECTED-FAIL | browser/base/content/test/general/browser_bug676619.js | application terminated with exit code -6
[task 2023-02-16T22:02:39.569Z] 22:02:39     INFO - runtests.py | Application ran for: 0:02:50.405943
[task 2023-02-16T22:02:39.570Z] 22:02:39     INFO - zombiecheck | Reading PID log: /tmp/tmpgzj4w2k9pidlog
[task 2023-02-16T22:02:39.570Z] 22:02:39     INFO - ==> process 1592 launched child process 1610
```
Bug: Don't offer to send more tabs than is possible.
Status: NEW
Priority: P2
Created: 2023-02-16 22:30:51+00:00
Resolved: 2025-02-13 18:48:47+00:00

From a thread in slack, someone reported trying to send 300 tabs, but ended up rate-limited by the server. Worse, they then got rate-limited, so the feature was entirely broken for some period after that.

That means there is a practical upper-limit on how many tabs can be sent, and that number is effectively a constant. Firefox really shouldn't offer to send more tabs than it can confidently know will fail.

(Tricky part here is UX. Current flow is "Select all tabs" -> "Click 'Send 300 tabs to Device'" - not clear how this flow should change when 300 tabs are selected but our limit is less than that?)
Bug: Private state for saving links and media should come from the parent, not the content window
Status: RESOLVED
Priority: P1
Resolution: FIXED
Created: 2023-02-16 23:13:25+00:00
Resolved: 2023-02-25 21:00:59+00:00

The context menu child actor sends whether its content window is private off to the parent, which then reads that information when saving links or media. This is suboptimal - the parent can just figure this out itself, and anyway shouldn't necessarily trust the child process to tell the truth about this. Given there's significant user interaction required to hit this code I don't think it's a terrible security issue, but it's still suboptimal. Let's fix it.
Bug: Mousing off Library screen top menu produces an unwanted flash
Status: NEW
Priority: P3
Created: 2023-02-17 01:23:31+00:00
Resolved: 2023-02-23 17:25:02+00:00

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

Steps to reproduce:

- open the Library (ctrl-shift-o)
- hover on any of the three menu choices at the top
- *very* slowly, mouse off the menu in any direction


Actual results:

For me, there is a black flash that fills the the menu choice background and disappears very quickly.  I couldn't capture the flash with my gifcam software; I've attached a .mp4 from a Reddit post which is where I was first made aware of the phenomenon. That person has a blue flash.


Expected results:

There should be no flash when mousing off that menu.
Bug: Tabs get into inconsistent state.
Status: RESOLVED
Priority: --
Resolution: INCOMPLETE
Created: 2023-02-17 05:27:05+00:00
Resolved: 2023-05-11 07:12:26+00:00

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

Steps to reproduce:

1) Dragging a tab to a different order on the same window.
2) Notification popup happens while dragging.


Actual results:

Tab detaches from the drag without completing the drag and gets stuck.  Unable to select or interact with tab using the mouse.


Expected results:

The UI should remain in a consistent state.
Bug: When trying to save a file with the same name it won't save it after 10000 files.
Status: NEW
Priority: P5
Created: 2023-02-17 07:27:27+00:00
Resolved: 2023-12-04 13:09:01+00:00

Steps to reproduce:

Tried to save the same Report from SSRS over 10000 times. 
The filenames where from ReportNew2.pdf up to ReportNew2-9999.pdf


Actual results:

After ReportNew2-9999.pdf firefox says that it can not save file in the specified folder.
You can only save a file if you change the folder you are saving or if you delete all files in folder.


Expected results:

It should create the next file ReportNew2-10000.pdf
Bug: [Linux] Always open similar files check mark is not displayed in about:downloads
Status: VERIFIED
Priority: P3
Resolution: FIXED
Created: 2023-02-17 13:04:51+00:00
Resolved: 2023-03-03 12:07:48+00:00

**Found in**
* opened on request from [bug 1792431#c8](https://bugzilla.mozilla.org/show_bug.cgi?id=1792431#c8)


**Affected versions**
* 112.0a1 (20230217091713)
* 111.0b2
* 110.0
* 102.8.0esr



**Tested platforms**
* Affected platforms: Ubuntu 20.04
* Unaffected platforms: Windows 10x64, Windows 7x64, macOS 12




**Steps to reproduce**
1. Download a random file like http://ipv4.download.thinkbroadband.com/5MB.zip.
2. Open about:downloads page and right-click on the downloaded item.
3. Click on Always open similar files.
4. Right-click on the previously downloaded item again.

**Expected result**
* Always open similar files option has a checkmark in front.

**Actual result**
* No checkmark is displayed.

**Regression range**
* Not a regression per [1792431#c1](https://bugzilla.mozilla.org/show_bug.cgi?id=1792431#c1)

**Additional notes**
* Attached a screen recording.
Bug: Bookmark dropdown not remembering position of last bookmark selected.
Status: RESOLVED
Priority: --
Resolution: DUPLICATE
Created: 2023-02-17 13:36:05+00:00
Resolved: 2023-02-17 14:07:22+00:00

Steps to reproduce:

Happens everytime I select a bookmark from the toolbar icon dropdown.


Actual results:

Post v 110 each time I envoke the bookmark dropdown from the toolbar it defaults to the top of the list. I have bookmarks organised in groups that I visit during a specific browsing session. Frustrating that I have to scroll all the way from the top each time I want to move to a different website.  


Expected results:

Prior to v 110 when I selected a bookmark from the toolbar dropdown the position of that bookmark was remembered and selecting the dropdown list again would go to the 'last used' position in the list. 
Is there a switch in config settings that can revert this behaviour?
Bug: Microphone icon should show when a user is on a SERP and is using it
Status: RESOLVED
Priority: P2
Resolution: WORKSFORME
Created: 2023-02-17 15:39:24+00:00
Resolved: 2023-03-08 18:49:07+00:00

STR:

- The persist search terms feature is enabled
- Enable microphone on a SERP (e.g. Bing) for voice searches and save the permission
- Do another search that results in the search terms persisting
- Use the voice feature to enable the microphone

Expected Result:
- The red microphone icon is shown in the urlbar.

Actual Result:
- The red microphone icon is hidden in the urlbar.

That's because we only show the Permissions Box when `pageproxystate` is `valid`.

One solution for this is to revert the urlbar if search terms persist and we know the microphone has been enabled.
Bug: Intermittent browser/components/urlbar/tests/browser/browser_textruns.js | single tracking bug
Status: RESOLVED
Priority: P5
Resolution: INCOMPLETE
Created: 2023-02-17 17:00:13+00:00
Resolved: 2023-03-14 17:02:46+00:00

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

---
```
[task 2023-02-17T16:04:01.909Z] 16:04:01     INFO - TEST-PASS | browser/components/urlbar/tests/browser/browser_textruns.js | Extension ID of search provider should be set - "test@tests.mozilla.org" == true - 
[task 2023-02-17T16:04:01.909Z] 16:04:01     INFO - Buffered messages finished
[task 2023-02-17T16:04:01.910Z] 16:04:01     INFO - TEST-UNEXPECTED-FAIL | browser/components/urlbar/tests/browser/browser_textruns.js | Test timed out - 
[task 2023-02-17T16:04:02.211Z] 16:04:02     INFO - GECKO(4412) | MEMORY STAT | vsize 2104575MB | vsizeMaxContiguous 66046330MB | residentFast 433MB | heapAllocated 166MB
[task 2023-02-17T16:04:02.213Z] 16:04:02     INFO - TEST-OK | browser/components/urlbar/tests/browser/browser_textruns.js | took 45405ms
[task 2023-02-17T16:04:02.224Z] 16:04:02     INFO - checking window state
[task 2023-02-17T16:04:02.229Z] 16:04:02     INFO - TEST-START | browser/components/urlbar/tests/browser/browser_tokenAlias.js
```
Bug: "toolkit.scrollbox.smoothScroll" is not working partially.
Status: RESOLVED
Priority: --
Resolution: INVALID
Created: 2023-02-17 17:27:16+00:00
Resolved: 2023-02-23 16:22:31+00:00

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

Steps to reproduce:

If "Animate controls and elements inside windows" is on in Windows settings, "toolkit.scrollbox.smoothScroll" works correctly true/false.
Animate controls and elements inside windows" is off, "toolkit.scrollbox.smoothScroll" does not work at all, and even if it is true, tab bar smooth scrolling does not work.


Actual results:

This bug was reproducible even after booting with add-ons disabled and booting in troubleshooting mode.


Expected results:

Since this bug did not occur before the update of firefox 109, it is believed to be caused by Firefox 110.
Bug: Stub Installer Fails on First Attempt
Status: RESOLVED
Priority: --
Resolution: WORKSFORME
Created: 2023-02-17 17:54:45+00:00
Resolved: 2024-02-15 18:32:58+00:00

Over the last week, I've had to install Firefox on a few computers on different networks.
- 2 different physical machines with Win 10
- 2x Win 11 virtual machine

Different networks. Same results. All were Firefox Release.

Each time, the stub installer failed on the first attempt. On my virtual machine, it worked on the second attempt. On the physical machines, I needed to use the full installer.

Steps to reproduce:
- Download and run stub installer from Mozilla.org
- After getting the error "Hmm. FOr some reason, we could not install Firefox. Choose OK to start over."
- Download full installer from website. 
- Result: Success

Options 2:
- Instead of downloading the full installer, try the stub installer a second time. 
- Result: Success

Expected Results
- Installation works with the stub installer on the first attempt.

With the virtual machine installs, I was doing a screen share with Najla (CC'd) to replicate in front of someone.
Bug: Update the Nimbus Legacy Telemetry expose event to use `branch` instead of `branchSlug`
Status: NEW
Priority: P3
Created: 2023-02-17 18:41:34+00:00
Resolved: 2023-03-06 22:29:08+00:00

Recently there was some concern over exposure events not recording branch info
- Resolved via mozanalysis fix
- Issue is that branch info is being recorded using a different key than enrollments (`branch` vs `branchSlug`)

Should probably be fixed in Nimbus for consistency
Here: https://searchfox.org/mozilla-central/source/toolkit/components/telemetry/Events.yaml#1076
here: https://searchfox.org/mozilla-central/source/toolkit/components/nimbus/lib/NimbusFeatures.cpp#199
And also probably here (though this is just a variable name): https://searchfox.org/mozilla-central/source/toolkit/components/nimbus/ExperimentAPI.jsm#317