av9ash/GitBugs huggingface dataset:
Bug: Bookmarks subfolders not showing in "Other bookmarks" section in Menu
Status: RESOLVED
Priority: --
Resolution: INCOMPLETE
Created: 2020-07-07 16:43:04+00:00
Resolved: 2020-08-14 11:35:25+00:00

User Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10_15_4) AppleWebKit/605.1.15 (KHTML, like Gecko) Version/13.1 Safari/605.1.15

Steps to reproduce:

In my bookmark structure, I have subfolders on the "Other bookmarks" section.

I select "Other bookmarks" from the application menu (macOS, Firefox Nightly)


Actual results:

Only top level bookmarks -not subfolders- on the "Other bookmarks" section appear when it is selected from the top application menubar in MacOS.


Expected results:

Subfolders in the "Other bookmarks" section should also appear.

Behaviour doesn't happen when selecting the "Other bookmarks" section from the toolbar (star icon).    Only happens from top menu bar (macOS).

If  "Show all bookmarks" is active (bookmark manager dialog is presented), then the top menu bar entry for "Other bookmarks" *displays* the correct subfolders.
Bug: Video playheads visible on dev tools
Status: VERIFIED
Priority: P2
Resolution: FIXED
Created: 2020-07-07 18:08:57+00:00
Resolved: 2020-07-13 08:09:20+00:00

Repro steps:

- Set `browser.newtabpage.activity-stream.discoverystream.config` to `{   "api_key_pref": "extensions.pocket.oAuthConsumerKey",   "collapsible": true,   "enabled": true,   "show_spocs": true,   "hardcoded_layout": false,   "personalized": true,   "layout_endpoint": "https://getpocket.cdn.mozilla.net/v3/newtab/layout?version=1&consumer_key=$apiKey&layout_variant=video-layout",   "unused_key": "unused_4" }`
- Set `browser.newtabpage.activity-stream.discoverystream.spocs-endpoint` to `https://spocs.getpocket.com/spocs?site=1124115`
- Set `browser.newtabpage.activity-stream.asrouter.devtoolsEnabled` to `true`
- Open `about:home#devtools`

Expected: See no video playheads visible inside of dev tools

Actual: Seeing floating video playheads (see pic)
Bug: Stuttering while watching 1080p 60fps videos on YouTube
Status: RESOLVED
Priority: --
Resolution: INVALID
Created: 2020-07-07 19:08:15+00:00
Resolved: 2020-07-07 19:10:45+00:00

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

Steps to reproduce:

After I noticed this happen (with hardware acceleration on), I tested out lower resolutions which streamed fine, and I also tested out the same videos with the same resolution on Chrome (which also worked flawlessly). I turned off hardware acceleration on FireFox and streaming 1080p 60fps works fine now.

OS: Windows 10 Pro
CPU: Ryzen 3800X
GPU: Radeon RX 5600XT


Actual results:

With hardware acceleration on, GPU video encode (in task manager) goes to 100% while streaming 1080p 60fps on YouTube.


Expected results:

Ideally there should be zero stuttering or struggle from my computer as it should be able to handle 1080p 60fps video with immense ease.
Bug: Roblox doesn't launch unless you clear cookies or open developer tools
Status: RESOLVED
Priority: --
Resolution: DUPLICATE
Created: 2020-07-07 19:11:27+00:00
Resolved: 2020-07-20 19:26:44+00:00

Since the Firefox 78 update, there have been a lot of users on the support forums complaining about issues with the online game platform Roblox. For those unfamiliar with the game, it has a launcher program installed on the user's computer and the user goes to the Roblox website to select the game they want to play. The browser then launches the game engine on the user's computer via a content type handler.

In Firefox 78 and newer, users are complaining that the game website will not start the launcher. The issue can be fixed by clearing the cookies, but the fix will only work for the session. If the user closes Firefox, they will have the same issue again.

This issue was introduced in update 78, since it does not occur in prior versions of Firefox. It's a Firefox-exclusive issue because I also tested in Chrome.

It appears that the issue is related to some cookies that are created and expire at the end of the session. If you use the cookie inspector to delete all session cookies or manually delete just one of the cookies set to expire at the end of the session, the game will launch.

Just curious if maybe one of the Firefox developers wanted to look into the issue further to see if it's caused by Firefox and check if it impacts other websites using the same method.

I did see there was a change to Enhanced Tracking Protection, in Firefox 78 so perhaps it's the cause of the issue. However, disabling ETP for the website didn't seem to help when I tested.
Bug: Back button does not respect theme colors
Status: NEW
Priority: P5
Created: 2020-07-07 19:29:17+00:00
Resolved: 2020-07-13 15:18:30+00:00

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

Steps to reproduce:

I created a theme with

"button_background_active": "rgb(255, 255, 0)",
"button_background_hover": "rgb(255, 0, 0)",

web-ext run path_to_manifest


Actual results:

The back button is red and has yellow on hover.


Expected results:

The back button should be red on hover.
Bug: about:studies is blank: Uncaught TypeError: can't access property "slice", study.userFacingName is undefined
Status: VERIFIED
Priority: P1
Resolution: FIXED
Created: 2020-07-07 19:41:36+00:00
Resolved: 2020-07-17 08:14:38+00:00

My about:studies page is blank in my regular user profile (80 Nightly), but not in a clean user profile. yoasif reported seeing the same problem.

I see the following JavaScript error in the web console:

```
Uncaught TypeError: can't access property "slice", study.userFacingName is undefined
    render resource://normandy-content/about-studies/about-studies.js:282
    _renderValidatedComponentWithoutOwnerOrContext resource://normandy-vendor/ReactDOM.js:18
    _renderValidatedComponent resource://normandy-vendor/ReactDOM.js:18
    performInitialMount resource://normandy-vendor/ReactDOM.js:18
    mountComponent resource://normandy-vendor/ReactDOM.js:18
    mountComponent resource://normandy-vendor/ReactDOM.js:5
    mountChildren resource://normandy-vendor/ReactDOM.js:18
    _createInitialChildren resource://normandy-vendor/ReactDOM.js:18
    mountComponent resource://normandy-vendor/ReactDOM.js:18
    mountComponent resource://normandy-vendor/ReactDOM.js:5
    mountChildren resource://normandy-vendor/ReactDOM.js:18
    _createInitialChildren resource://normandy-vendor/ReactDOM.js:18
    mountComponent resource://normandy-vendor/ReactDOM.js:18
    mountComponent resource://normandy-vendor/ReactDOM.js:5
    performInitialMount resource://normandy-vendor/ReactDOM.js:18
    mountComponent resource://normandy-vendor/ReactDOM.js:18
    mountComponent resource://normandy-vendor/ReactDOM.js:5
    mountChildren resource://normandy-vendor/ReactDOM.js:18
    _createInitialChildren resource://normandy-vendor/ReactDOM.js:18
    mountComponent resource://normandy-vendor/ReactDOM.js:18
    mountComponent resource://normandy-vendor/ReactDOM.js:5
    _updateRenderedComponent resource://normandy-vendor/ReactDOM.js:18
    _performComponentUpdate resource://normandy-vendor/ReactDOM.js:18
    updateComponent resource://normandy-vendor/ReactDOM.js:18
    performUpdateIfNecessary resource://normandy-vendor/ReactDOM.js:18
    performUpdateIfNecessary resource://normandy-vendor/ReactDOM.js:5
    i resource://normandy-vendor/ReactDOM.js:5
    perform resource://normandy-vendor/ReactDOM.js:5
    perform resource://normandy-vendor/ReactDOM.js:5
    perform resource://normandy-vendor/ReactDOM.js:5
    v resource://normandy-vendor/ReactDOM.js:5
    closeAll resource://normandy-vendor/ReactDOM.js:5
    perform resource://normandy-vendor/ReactDOM.js:5
    batchedUpdates resource://normandy-vendor/ReactDOM.js:18
    d resource://normandy-vendor/ReactDOM.js:5
    o resource://normandy-vendor/ReactDOM.js:18
    enqueueSetState resource://normandy-vendor/ReactDOM.js:18
    setState resource://normandy-vendor/React.js:5
    handleEvent resource://normandy-content/about-studies/about-studies.js:66
```

I think this is a regression from bug 1624728.
Bug: Cannot minimize indicator when in DOM fullscreen mode
Status: NEW
Priority: P2
Created: 2020-07-07 19:42:23+00:00
Resolved: 2020-07-09 10:16:56+00:00

STR:

1. Start a WebRTC call on https://meet.google.com, sharing at least the microphone and camera.
2. Enter the call, and ensure the global sharing indicator is displayed
3. Assuming you're the only person in the room, your camera feed should be the only one displayed. Double-click on that to enter DOM fullscreen.
4. Click on the minimize button in the indicator.

ER:

The indicator should minimize.

AR:

The indicator does not minimize.
Bug: Activating address bar when a new typed domain is still loading only selects the trailing slash
Status: RESOLVED
Priority: P3
Resolution: WORKSFORME
Created: 2020-07-07 19:55:00+00:00
Resolved: 2024-07-30 10:20:18+00:00

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

Steps to reproduce:

Type an address I've visited before, such as bogleheads.org/, into location bar. Note trailing slash. Problem also happens if you enter the full URL, e.g. https://www.bogleheads.org/. Hit Enter. Then immediately hit Cmd-L before the page has fully loaded.


Actual results:

This will select only the "/" part of the URL.


Expected results:

The whole URL should have been selected.

I discovered this because sometimes I want to open a URL that I've visited recently and also copy its URL so I can paste it into a Hacker News comment or whatever. The easiest way is to autocomplete it, then select the URL. Often I end up with just "/" on the clipboard due to this bug.
Bug: Cookies and session state maintained across tabs and windows in incognito mode
Status: UNCONFIRMED
Priority: --
Created: 2020-07-08 03:57:04+00:00
Resolved: 2023-08-14 12:20:02+00:00

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

Steps to reproduce:

1. Open incognito window
2. Login to a website, let's say paypal.com
3. Open new tab and go to paypal.com (you'll be logged in)
4. Open new window and go to paypal.com (you'll be logged in)
5. Close all incognito windows and open a new incognito window and go to paypal.com (you'll be logged in)


Actual results:

Cookies and session state for websites are maintained across tabs and new windows in incognito mode. This leads to potential information leakage through the cookies if you want to browse something else in a new incognito mode.


Expected results:

Ideally when opening a new tab in incognito mode, it is expected for the session state and cookies to not be carried over. A new tab is something that can be accepted but a new window seems to be the bigger problem since typically a person opens a new incognito window so the previous incognito window's details are not carried over.
Bug: Unable to send multiple parameters at a time.
Status: RESOLVED
Priority: --
Resolution: INCOMPLETE
Created: 2020-07-08 05:49:53+00:00
Resolved: 2020-08-18 09:43:33+00:00

User Agent: Mozilla/5.0 (Windows NT 6.1; ) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/83.0.4103.116 Safari/537.36

Steps to reproduce:

aaa


Actual results:

bbb


Expected results:

ccc
Bug: Firefox doesn't load first opened website
Status: NEW
Priority: P3
Created: 2020-07-08 08:23:44+00:00
Resolved: 2022-01-10 18:55:44+00:00

Firefox 79.0b5 (64-bit), Ubuntu 18.04.

STR:
1. Start Firefox.
2. Tap F6 to focus the address bar.
3. Tap "c" to get a suggested URL ("chat.mozilla.org" in my case).
4. Tap Enter.

Expected:
page opens.

Actual:
page doesn't open.

This works when pasting a URL in step 3. Therefore perhaps related to auto-completion?
Bug: Can't open new tab manually
Status: RESOLVED
Priority: --
Resolution: WORKSFORME
Created: 2020-07-08 08:28:59+00:00
Resolved: 2020-07-13 14:07:14+00:00

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

Steps to reproduce:

Frankly, I don't know... :(


Actual results:

For whatever reason, I cannot open a new tab. Te usual plus-sign is missing


Expected results:

I should be able to  see the plus-sign for opening new tabs. I also tried restarting firefox in safe mode with all the add-ons disabled, but it didn't resolve the problem. I also restarted the computer, but it didn't have effect.
Bug: Firefox 78.0.1 is saving .WEBP files as .JPG or .JPEG for files served with .jpeg extension and no content-disposition header information
Status: RESOLVED
Priority: P3
Resolution: DUPLICATE
Created: 2020-07-08 11:02:03+00:00
Resolved: 2020-11-10 17:00:56+00:00

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

Steps to reproduce:

Hello dears and especially feckless Firefox programmers.

Several months ago I created this bug report  Bug 1602220 :

https://bugzilla.mozilla.org/show_bug.cgi?id=1602220

but someone colosed this bug and marked it as SOLVED and FIXED in v78
However, the biggest problem is that the BUG is indeed still here !!!
I have Firefox 78.0.1 and If I try to save this image

https://d15-a.sdn.cz/d_15/c_img_QN_Q/yGNPj.jpeg?fl=cro,0,0,1280,1033%7Cres,1280,,1%7Cwebp,75

the image is saved as .jpg :) instead of .webp

Can you please kick the moron who wrongly corrected the problem to his head and say him that is it good enough to find a "WEBP" string in the first 64 characters in the image file to identify WEBP image file type ??? 

Is there some MORE able/qualified programmer with higher IQ which would be willing and able to correct this BUG ?

Jerry 







Actual results:

Hello dears and especially feckless Firefox programmers.

Several months ago I created this bug report  Bug 1602220 :
https://bugzilla.mozilla.org/show_bug.cgi?id=1602220
someone colosed this bug and marked it as SOLVED and FIXED in v78
However, the biggest problem is that the BUG is indeed still here !!!
I have Firefox 78.0.1 and If I try to save this image

https://d15-a.sdn.cz/d_15/c_img_QN_Q/yGNPj.jpeg?fl=cro,0,0,1280,1033%7Cres,1280,,1%7Cwebp,75

the image is saved as .jpg :)

Can you please kick the moron who wrongly corrected the problem to his head and say him that is it good enough to find a "WEBP" string in the first 64 characters in the image file to identify WEBP image file type ??? 

Is there some MORE able/qualified programmer with higher IQ which would be willing and able to correct this BUG ?

Jerry 




Expected results:

Th Firefox should be capable to save ALL images type of WEBP with .webp extension instead of .jpg or .jpeg or .png extension etc.
Bug: Custom new-tab pages don't have auto-focus on search-field
Status: RESOLVED
Priority: --
Resolution: DUPLICATE
Created: 2020-07-08 13:37:26+00:00
Resolved: 2020-07-22 20:46:55+00:00

80.0a1 (2020-07-08) (64-bit) on macOS

Until the last update, opening a new tab would automatically focus on the search-bar, even when the new-tab page was customized with an extension.

Now, when I open a new tab with a new-tab extension the search bar is not focused anymore. I tried it on two computers with the latest Nightly and multiple addons ([like this one](https://addons.mozilla.org/en-US/firefox/addon/tabby-cat-friend/)).

The search bar is still getting focused on `Firefox Home` and `Blank Page`.
Bug: No longer able to join GoToMeeting via GoToOpener in Firefox
Status: RESOLVED
Priority: --
Resolution: DUPLICATE
Created: 2020-07-08 15:05:02+00:00
Resolved: 2020-07-20 19:26:27+00:00

STEPS TO REPRODUCE (on Mac):

1) Load a link like https://global.gotomeeting.com/join/817906333
2) Install the application it prompts you to install via the "Download the app" button.
3) Load that link again.

EXPECTED RESULTS: Get a dialog asking you to open a link in the GoToOpener app.

ACTUAL RESULTS: Nothing.

This used to work in Firefox 77.  I tried bisecting, and as far as I can tell it regressed in the range https://hg.mozilla.org/mozilla-central/pushloghtml?fromchange=f3a82909&tochange=bf162b06 which suggests bug 1606797 as a likely cause...
Bug: Unable to launch specific Content Type via desktop application
Status: RESOLVED
Priority: --
Resolution: DUPLICATE
Created: 2020-07-08 17:27:49+00:00
Resolved: 2020-07-08 18:35:33+00:00

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

Steps to reproduce:

User tried to open custom Content Type via electron link (file://<link>), browser seems not reacting to this request.

Issue discovered with 78.0.1 and only for part of users.


Actual results:

1. Nothing - Application was not launched nor option to choose application
2. With Debugger console turned on issue is not happening, application is launched successfully


Expected results:

Expected to launch link or choose application to launch based on settings in handler.json

Is there any difference in launching via Standard user mode & Developer debug mode which could affect the behavior?
Bug: Sync ping devices list contains many devices without `os`/`version` info
Status: NEW
Priority: P3
Created: 2020-07-08 21:23:51+00:00
Resolved: 2020-08-18 06:35:06+00:00

In bug 1639838 we stopped filtering the ping devices list, however the info we include about (most of) the previously filtered devices is just their device ID and device type field. 

There are a number of issues with this.

1. Those devices are entirely useless in the context of analyzing event telemetry, which is the problem that bug is attempting to address.

2. The presence of these unfiltered devices would make it almost impossible to do other sorts of analysis we might want to do in the future. My personal device list now contains a huge number of entries, going back multiple years and including multiple device-registration-induced duplicates (in https://bugzilla.mozilla.org/show_bug.cgi?id=1639838#c10 I go into more deftails about this). Specifically, previously the list would have been able to answer questions about:
    - how many other devices the user is actually using, and what they're types are. 
    - whether or not these bookmark validation problems are correlated with having mobile devices.
    - ...

These are really two separate issues, but I think they're probably related (that said, you could imagine solutions to number 2 that involve include usage timestamps which would solve that issue but not the first)

---

Essentially my feeling here (which you can disagree with):

- For sync users we should try very hard to avoid sending devices in the device list which have no os/version info

- For all users (but especially non-sync users), we should try very hard to include irrelevant devices in that list, where irrelevant means something like "could not possibly influence any sort of analysis we might want to do".
    - My personal devices list contains: 20 devices 2018, 4 from 2019, and 2 from 2017. These all seem very much irrelevant.

### Strawman solution

Note: This is more intended to be a starting point for discussion than what the algorithm should definitely be.

1. Bring back at least age-based filtering, but modify it so that it cannot filter devices whose id appears in the events list.

2. If we are a sync user and are going to include device record with no os/version info, try and resolve that:

    - If they're not a sync user, nothing can be done.

    - Otherwise, try to dedupe it using something like:

        - Clients engine info like staleness and such (I believe it knows this for some cases, but would have to check again to remember the details).

        - If device name is identical to a device whose info we have, we use its info. (This is a little dodgy, so if we expect the clients engine approach to be reliable, we should stick with that)

Thoughts?
Bug: Intermittent TV browser/components/customizableui/test/browser_character_encoding_ctrl_click.js | Uncaught exception - Subview (PanelUI-characterEncodingView) did not show within 20 seconds.
Status: RESOLVED
Priority: P5
Resolution: INCOMPLETE
Created: 2020-07-09 06:00:09+00:00
Resolved: 2021-06-22 17:01:11+00:00

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

---
Bug: Clicking "stay on page" (ie cancelling) in beforeunload dialogs should cause us to reset the URL bar
Status: RESOLVED
Priority: --
Resolution: FIXED
Created: 2020-07-09 10:37:40+00:00
Resolved: 2025-03-02 14:52:44+00:00

The fact that we don't do this is part of a chain of not-quite-right-things used by https://twitter.com/lbherrera_/status/1280617786088329220 and bug 1333599. AIUI fixing this will break the spoof. There's an old patch to address this in bug 1333599, I think.
Bug: Edit This Bookmark pop-up sometimes appears in the wrong place
Status: RESOLVED
Priority: P5
Resolution: WORKSFORME
Created: 2020-07-09 11:26:57+00:00
Resolved: 2022-07-01 09:52:44+00:00

Steps to reproduce:

1) Create new profile and run Firefox.
2) Create a bookmark.
3) Open bookmarks Library window ("show all bookmarks") and create a folder.
4) Click the "bookmarked" star and change the bookmark location to the new folder.
5) Click the "bookmarked" star multiple times.

Expected:

5) The Edit This Bookmark window appears under the "bookmarked" star and points to the star.

Actual:

5) The Edit This Bookmark window appears too far to the left. See the attached screen shot

Maximizing the window resets the state and the Edit This Bookmark window will then appear in the correct place.
Bug: The "DOH_ROLLOUT_CONFIRMATION" doorhanger is wrongly displayed outside the browser's borders at resize
Status: NEW
Priority: P5
Created: 2020-07-09 12:44:11+00:00
Resolved: 2020-07-09 16:12:42+00:00

**[Affected versions]:**
- Firefox Beta 79.0b5 - Build ID: 20200708005253
- Firefox Nightly 80.0a1 - Build ID: 20200709093347

**[Affected Platforms]:**
- Windows 10 x64
- macOS 10.15
- ubuntu 18.04 x64

**[Prerequisites]:**
- Have a Firefox profile with the `browser.newtabpage.activity-stream.asrouter.devtoolsEnabled` pref set to `true` in the "about:config" page.

**[Steps to reproduce]:**
1. Open the browser with the profile from prerequisites.
2. Navigate to the "about:newtab#devtools" page and search the "DOH_ROLLOUT_CONFIRMATION" section.
3. Click the "Show" button from the "DOH_ROLLOUT_CONFIRMATION" section.
4. Resize the browser and observe the behavior.

**[Expected result]:**
- The "DOH_ROLLOUT_CONFIRMATION" is displayed inside the browser's borders.
	
**[Actual result]:**
- The "DOH_ROLLOUT_CONFIRMATION" is displayed outside the browser's borders.

**[Notes]:**
- Attached a screen recording of the issue.
Bug: DoH heuristics sometimes don't run when network goes up
Status: VERIFIED
Priority: P1
Resolution: FIXED
Created: 2020-07-09 14:03:17+00:00
Resolved: 2020-07-15 12:18:51+00:00

Found this thanks to @dcicas and @bmaris. Sometimes, when the network goes up, we don't re-run heuristics.

The reason is that we receive a signal that the network link is up, but captive portal state is unknown, so we don't run heuristics. Later, we never receive a captive portal state change event. This implies that the observer notification `ipc:network:captive-portal-set-state`  which is used by the captive portal web extension API is unreliable. However, I verified that `network:captive-portal-connectivity` IS sent, so that one should work.

We should change the captive portal handler to use onConnectivityAvailable rather than onStateChanged, at least for now. Once bug 1603779 lands we should solve this network handling issue once and for all.

I'll attach a patch specifically for beta - this bug does not manifest the same way in Nightly and I'd rather solve it in central after bug 1603779 lands.