av9ash/GitBugs huggingface dataset:
Bug: full screen mode of streaming charts at in.investing.com not working in firefox browser in private window due to referrer being stripped to origin
Status: RESOLVED
Priority: --
Resolution: WORKSFORME
Created: 2020-07-15 06:28:20+00:00
Resolved: 2022-07-06 08:30:24+00:00

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

Steps to reproduce:

loggedin into in.investing.com > selected a stock > selected chart > selected for full screen option of chart.

I have tried changing preferences, cleared cookies and site data, but nothing worked.

firefox version 78.0.2


Actual results:

initial chart was displayed but full screen function of chart is providing no response


Expected results:

Full screen mode of chart when selected should expand the chart to full screen. Same was happening in previous instances.

Same is happening when the website in.investing.com is accessed on chrome browser
Bug: Newer Firefox 32 bits render some PDF text invisible
Status: RESOLVED
Priority: --
Resolution: DUPLICATE
Created: 2020-07-15 07:44:40+00:00
Resolved: 2020-12-01 01:19:43+00:00

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

Steps to reproduce:

1) Configure Firefox 32 bits to open and display PDF directly: Tools - Options - General - Applications - Portable Document Format - Open in Firefox.
2) Access this test PDF file: http://www.orimi.com/pdf-test.pdf


Actual results:

Firefox 32 bits pops a warning: "This PDF document might not be displayed correctly."

On the example PDF, all text is rendered invisible (it can still be selected and copied to the clipboard, meaning it is there, it just can't be seen). Selecting all text doesn't show anything, so the font is not white, it's really invisible.

Other PDF files render fine or partly invisible (only some parts are visible). It has something to do with the PDF generator engine, as some sites produce PDF on the fly and either all of them work fine, or all of them fail.


Expected results:

On Firefox 64 bits, the test PDF renders just fine. The problem is confined (for now) to Firefox 32 bits. I don't remember seen this bug on older versions of Firefox. Other browsers also render the test PDF without problems.
Bug: Intermittent browser/components/urlbar/tests/browser/browser_locationBarCommand.js | usertyping attribute must be set for the go button to be visible -
Status: RESOLVED
Priority: P5
Resolution: INCOMPLETE
Created: 2020-07-15 12:46:54+00:00
Resolved: 2020-08-11 17:22:42+00:00

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

---

```
 INFO - TEST-START | browser/components/urlbar/tests/browser/browser_locationBarCommand.js
[task 2020-07-15T11:53:44.592Z] 11:53:44     INFO - TEST-INFO | started process screentopng
[task 2020-07-15T11:53:44.748Z] 11:53:44     INFO - TEST-INFO | screentopng: exit 0
[task 2020-07-15T11:53:44.749Z] 11:53:44     INFO - Buffered messages logged at 11:53:44
[task 2020-07-15T11:53:44.749Z] 11:53:44     INFO - Entering test bound setup
[task 2020-07-15T11:53:44.750Z] 11:53:44     INFO - Leaving test bound setup
[task 2020-07-15T11:53:44.750Z] 11:53:44     INFO - Entering test bound alt_left_click_test
[task 2020-07-15T11:53:44.750Z] 11:53:44     INFO - Running test: Alt left click
[task 2020-07-15T11:53:44.750Z] 11:53:44     INFO - TEST-PASS | browser/components/urlbar/tests/browser/browser_locationBarCommand.js | userContextId must be the same as the originating tab - 0 == "" - 
[task 2020-07-15T11:53:44.750Z] 11:53:44     INFO - Buffered messages finished
[task 2020-07-15T11:53:44.751Z] 11:53:44     INFO - TEST-UNEXPECTED-FAIL | browser/components/urlbar/tests/browser/browser_locationBarCommand.js | usertyping attribute must be set for the go button to be visible - 
[task 2020-07-15T11:53:44.751Z] 11:53:44     INFO - Stack trace:
[task 2020-07-15T11:53:44.751Z] 11:53:44     INFO - chrome://mochikit/content/browser-test.js:test_ok:1299
[task 2020-07-15T11:53:44.752Z] 11:53:44     INFO - chrome://mochitests/content/browser/browser/components/urlbar/tests/browser/browser_locationBarCommand.js:triggerCommand:225
[task 2020-07-15T11:54:29.415Z] 11:54:29     INFO - Not taking screenshot here: see the one that was previously logged
[task 2020-07-15T11:54:29.417Z] 11:54:29     INFO - TEST-UNEXPECTED-FAIL | browser/components/urlbar/tests/browser/browser_locationBarCommand.js | Test timed out - 
[task 2020-07-15T11:54:29.436Z] 11:54:29     INFO - GECKO(7499) | MEMORY STAT | vsize 3237MB | residentFast 395MB | heapAllocated 130MB
[task 2020-07-15T11:54:29.437Z] 11:54:29     INFO - TEST-OK | browser/components/urlbar/tests/browser/browser_locationBarCommand.js | took 45025ms
[task 2020-07-15T11:54:29.456Z] 11:54:29     INFO - checking window state
[task 2020-07-15T11:54:29.459Z] 11:54:29     INFO - TEST-START | browser/components/urlbar/tests/browser/browser_locationBarExternalLoad.js
```
Bug: restore session disappears and deletes session after opening link from another program
Status: RESOLVED
Priority: --
Resolution: INVALID
Created: 2020-07-15 16:23:40+00:00
Resolved: 2020-07-15 16:32:13+00:00

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

Steps to reproduce:

have a bunch of firefox windows open.
killall firefox
open a link from another program and the session restore tab will breifly appear then the link from the program will load and the session restore will be gone along with the sessiosn


Actual results:

have a bunch of firefox windows open.
killall firefox
open a link from another program and the session restore tab will breifly appear then the link from the program will load and the session restore will be gone along with the sessiosn


Expected results:

have a bunch of firefox windows open.
killall firefox
open a link from another program and the session restore tab will breifly appear then the link from the program will load and the session restore will be gone along with the sessiosn
Bug: Protections popup does not list "allowed" cookies in default configuration
Status: NEW
Priority: P3
Created: 2020-07-15 16:34:03+00:00
Resolved: 2021-02-11 17:48:56+00:00

Found while writing tests for bug 1652614 and checking initial states in new windows.

STR:

1. open a site without trackers. I used `https://xkcd.com/`. It probably doesn't matter.
2. verify "normal" (not strict/custom) tracking protection is in use. AIUI this only rejects trackers, but not other cookies.
3. open the browser console, run `gProtectionsHandler.onContentBlockingEvent(Ci.nsIWebProgressListener.STATE_COOKIES_LOADED)`
4. open the protection popup

ER:
cookies are listed as "allowed"

AR:
cookies are not listed

It's quite possible I'm misunderstanding the desired state here - or the meaning of the flag. The documentation at https://searchfox.org/mozilla-central/rev/82c04b9cad5b98bdf682bd477f2b1e3071b004ad/uriloader/base/nsIWebProgressListener.idl#292 is not super clear to me. But existing tests (cf. https://searchfox.org/mozilla-central/rev/82c04b9cad5b98bdf682bd477f2b1e3071b004ad/browser/base/content/test/protectionsUI/browser_protectionsUI_categories.js#153 ) use this flag to test for cookies appearing as "blocked" in the pref when `network.cookie.cookieBehavior` is set to reject all cookies. I don't know what our philosophy is to show cookies as "allowed" when other (non-tracking?) cookies are in use and not blocked.

This reproduces on 79 beta so is not a recent regression, unlike 1652614... Filing mostly to have something on record and make an explicit decision; we may want to update the tests to check specifically for tracking cookies, assuming those *do* cause us to list cookies as "allowed" ?
Bug: Typing in go/links does a search instead of redirect to http://go/links
Status: RESOLVED
Priority: --
Resolution: DUPLICATE
Created: 2020-07-15 19:14:28+00:00
Resolved: 2020-07-16 19:33:37+00:00

User Agent: Mozilla/5.0 (iPhone; CPU iPhone OS 13_5_1 like Mac OS X) AppleWebKit/605.1.15 (KHTML, like Gecko) Version/13.1.1 Mobile/15E148 Safari/604.1

Steps to reproduce:

Type in http://go/ into the address bar. 
Successfully access golinks. 
Type in go/links into the browser bar. 



Actual results:

A google search is performed when entering in go/links


Expected results:

Firefox should direct browser to http://go/links
Bug: PDFs default to "Open with Firefox" when I've said I don't want that
Status: VERIFIED
Priority: --
Resolution: FIXED
Created: 2020-07-15 22:33:27+00:00
Resolved: 2020-09-09 15:40:12+00:00

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

Steps to reproduce:

Prior to Firefox 78.0.2, I had configured Firefox to "Always Ask" for PDF content-types. This worked the way I want it: When I clicked on a link that serves a PDF I was presented with a choice between opening in an external application (most common) or saving the PDF somewhere specific instead. Opening in an external document viewer was the default, which is fine.

When Firefox upgraded to 78.0.2, it decided it knew better and changed the preference to "Open in Firefox" for PDFs. That was mildly annoying. I didn't want PDFs rendering in Firefox, so I found the setting and changed it back again.

So far so good.


Actual results:

Now when I follow a link that serves a PDF document, Firefox opens a dialog that has three options:

1. **Always selected by default!** Open with Firefox
2. Open with: Document Viewer (default)
3. Save File
[ ] Do this automatically for files like this from now on.


Expected results:

Firefox should NOT have defaulted to "Open with Firefox". 

The whole reason why I changed my preference away from "Open in Firefox" is because I DON'T want it to open in Firefox. Hence this is a silly default which is forcing me to constantly fight against Firefox, switching away from that option every time. Except I often forget that the behaviour has changed and now I am accidentally opening  documents in Firefox when I intended to open them in an external document viewer.

Acceptable alternatives would have been:

a. to default to the option for opening in a document viewer (the previous behaviour), or
b. to default to whatever I actually chose last time (assuming there was a last time) .

I prefer option a). However, there is a small possibility that some people would like to choose between opening in Firefox and saving the document, and there may be some people who almost always want to save, but occasionally want to do something different, and for those people, b) would be a better choice.
Bug: firefox prevents screensafer to get active
Status: RESOLVED
Priority: --
Resolution: INCOMPLETE
Created: 2020-07-15 23:24:54+00:00
Resolved: 2020-08-13 12:45:33+00:00

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

Steps to reproduce:

when Firefox is active in the front, the screen safer will not get active.
I'm useing MAC OSX 10.10.5


Actual results:

The screen stays awake


Expected results:

after a sertain time the screensafer should get active.
It works well if any other programm is in front
Bug: Changes made to sync options do not carry over
Status: RESOLVED
Priority: --
Resolution: INACTIVE
Created: 2020-07-16 01:07:28+00:00
Resolved: 2020-08-18 06:34:36+00:00

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

Steps to reproduce:

Go to tool/options
Go to Sync
Check all boxes (bookmarks and passwords were the only two previously checked)
Click "save changes"
Wait about 15 minutes to give everything else to sync
Close Firefox
Open Firefox on second PC
Log into sync and verify
Check original computer that made the changes


Actual results:

Only bookmarks and passwords were synced despite checking all the sync options on the first PC. When I open Firefox again on the first PC, all options have reverted to only syncing bookmarks and passwords despite clicking "save changes" and giving it time to update


Expected results:

Firefox should sync everything to the second PC and sync options should not revert to what it was previously. I should be the one to change it back once I am ready to
Bug: Location bar content not copied to PRIMARY upon clicking in = selecting the URL (Linux/X11)
Status: RESOLVED
Priority: P3
Resolution: DUPLICATE
Created: 2020-07-16 08:09:28+00:00
Resolved: 2023-01-23 16:37:11+00:00

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

Steps to reproduce:

Using Firefox 78.0.2 on Linux/X11:
1.  Visit a URL by entering it into the location bar and pressing return
2. Click into the location bar once or press Ctrl+L; the URL gets highlighted
3. Middle click into any text area (inside firefox or some other window/application)


Actual results:

URL does not get pasted.


Expected results:

URL should be in PRIMARY as soon as it gets highlighted and be able to be pasted somewhere else.

This bug has been introduced only shortly before my current 78.0.2 as I regularly use this procedure to paste URLs into mails and constantly end up not pasting what I want.

I don't know how others feel, but I miss the triple-click to select which is the standard in any other application (or even within text areas inside firefox)! This is a real break in usability standards.
With the current way of automatic full selection of the URL by the first click, I also cannot select parts of the URL (which I have to do all the time because of unnecessary sessionid, tracking and whatnot parameters in today's urls) without clicking a second time, which is also completely uncommon to any selectable text.

clipboard.autocopy is set (untouched).
The description of http://kb.mozillazine.org/Clipboard.autocopy is also wrong now with the current behavior.

If this is a feature and not a bug, please make it configurable (and I'd suggest to make the standard of a whole desktop environment the standard and not this way that breaks the standard). If you do not agree please at least make it configurable and leave the "feature" the standard.
Bug: [macOS]Pocket - tab-focus styling not applied on first option in Your privacy matters modal
Status: NEW
Priority: P2
Created: 2020-07-16 08:17:15+00:00
Resolved: 2024-03-04 12:23:05+00:00

**Affected versions**
* 79.0b8, 80.0a1

**Affected platforms**
* macOS 10.13.6

**Steps to reproduce**
Preconditions:
*browser.search.region* set to *US*
*browser.newtabpage.activity-stream.discoverystream.spocs-endpoint* set to *https://spocs.getpocket.com/spocs?country=US&region=CA*
1. Launch Firefox with the set prefs;
2. Locate a sponsored tile under the Recommended by Pocket section;
3. Click on the options button for it;
4. Click on Our sponsors and your privacy option;
5. Press Tab key a couple of times;

**Expected result**
* same design over elements;

**Actual result**
* tab-selector design differs;

**Regression range**
* not a regression, checking for the range saw that initially not even the bottom option was tab-selectable

**Additional notes**
* attached recording with the issue;
* suggested severity is S4, since it's an uncommon case / limited to sponsored content regions.
Bug: Don't strip the protocol if it differs from http(s) (was: File URL matching doesn't work)
Status: NEW
Priority: P3
Created: 2020-07-16 10:11:19+00:00
Resolved: 2020-11-05 10:29:30+00:00

(Summary could probably use some work)

STR:

1. be on Windows
2. type `file://` in the address bar

ER: only see local file results from history, maybe prefill with a path to $HOME if we're being nice

AR: other history results (that do not even appear to include "file" in the title / url) show up, mixed with some local file results

3. type another `/`

ER: same as above

AR: I see a number of remote tab switch hits and top site hits (different from above!) but no file results at all

4. type `C`

ER: same as above, limited to C: disk

AR: different remote tab switch hits again

5. type `:`

ER: same as above

AR: now it works


Inputting without the `file:///` prefix does not produce the same results, for some reason, and continues providing web results even after typing `C:`.
Bug: [PI-721]The "Firefox Multi-Account Containers" icon from the recommendation is barely visible when the browser's dark theme is enabled
Status: NEW
Priority: P5
Created: 2020-07-16 12:31:28+00:00
Resolved: 2020-07-20 15:13:19+00:00

**[Affected versions]:**
- Firefox Release 78.0.2 Build ID 20200708170202

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

**[Prerequisites]:**
- Have a browser profile with the profile cration date older than 1 week.
- Have the "Stage Preview" environment selected and polled using the Remote Settings Devtools add-on.
- Have the browser profile enrolled in the "high-velocity-message-testing-multi-account-containers-retention-study".
- Have the "browser.newtabpage.activity-stream.asrouter.devtoolsEnabled" preference set to "true".
- Have the browser dark theme enabled.

**[Steps to reproduce]:**
1. Open the browser and open a new tab.
2. Click the "Expand Devtools" button.
3. Select the "messaging-experiments" option from the "Show messages from" dropdown menu.
4. Click the "Show" button from the first messaging experiment.
5. Click the "Recommendation" button and observe the doorhanger.

**[Expected result]:**
- The "Firefox Multi-Account Containers" icon is clearly visible.

**[Actual result]:**
- The "Firefox Multi-Account Containers" icon is hard to notice using the dark theme.

**[Notes]:**
- Attached a screenshot of the issue:
Bug: PDFs loaded into invisible iframes with application/octet-stream without `content-disposition: attachment` no-op (display in the background) rather than download
Status: RESOLVED
Priority: --
Resolution: FIXED
Created: 2020-07-16 13:26:19+00:00
Resolved: 2020-08-14 21:57:48+00:00

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

Steps to reproduce:

The following technique to start a (pdf) download without a click no longer works:
https://stackoverflow.com/questions/3749231/download-file-using-javascript-jquery
(first answer)
The technique is a bit tricky but I don't know an alternative to it.

Now, the hidden iframe just tries to show the pdf-file independent of the mime-type.
Now it's only possible to download non-pdf-files. They work without any problem but pdf-files just do nothing, they neither download nor get opened in a tab to be viewed.
Bug: Default key for search engine gets deleted after a browser restart.
Status: RESOLVED
Priority: --
Resolution: DUPLICATE
Created: 2020-07-16 13:40:03+00:00
Resolved: 2020-07-20 19:27:45+00:00

Default "key"  for search engine in about:preferences#search  gets deleted after a browser restart.

**Reproduced in**
Windows10 64bit, MacOS 10.15, ubundu 18.04
With firefox 78.0.2 , firefox Beta 79.0b8 and nightly 80.0a1


**Steps to reproduce**
- Open firefox with a new profile
- Install ecosia addon https://addons.mozilla.org/en-US/firefox/addon/ecosia-the-green-search/?src=search
- go to about:preferences#search  and notice on one-offs list ecosia has default key "ecosia"
- restart firefox
- go to about:preferences#search
 

**Actual result**
 the default key for ecosia is now blank

**expected result**
 default key should be "ecosia" as before.
Bug: Global sharing indicator blocks access to menus in macOS
Status: NEW
Priority: P3
Created: 2020-07-16 16:36:02+00:00
Resolved: 2023-09-15 18:55:16+00:00

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

Steps to reproduce:

1. Join WebRTC session
2. Click on the new global sharing indicator to focus it.
3. Now you can no longer access the menu bar; it is blank.


Actual results:

If the global sharing indicator is focused, all of the Firefox menu bar items became inaccessible.


Expected results:

The menu bar should remain accessible no matter what window is focused, just like other non-browser windows in Firefox (such as About).
Bug: All main menu interactions show as `menubar-items`
Status: RESOLVED
Priority: --
Resolution: FIXED
Created: 2020-07-16 17:38:55+00:00
Resolved: 2020-07-17 03:32:25+00:00

For the interaction data added in bug 1620358  we prefer using the toolbar widget ID where possible. Unfortunately for the main menu on the normally hidden menu bar that means that any click in the menus will show as `menubar-items` instead of something more specific.
Bug: Typing in go/links does a search instead of redirect to http://go/links
Status: RESOLVED
Priority: --
Resolution: DUPLICATE
Created: 2020-07-16 18:21:31+00:00
Resolved: 2020-07-16 19:33:19+00:00

+++ This bug was initially created as a clone of Bug #1653065 +++

User Agent: Mozilla/5.0 (iPhone; CPU iPhone OS 13_5_1 like Mac OS X) AppleWebKit/605.1.15 (KHTML, like Gecko) Version/13.1.1 Mobile/15E148 Safari/604.1

Steps to reproduce:

Type in http://go/ into the address bar. 
Successfully access golinks. 
Type in go/links into the browser bar. 



Actual results:

A google search is performed when entering in go/links


Expected results:

Firefox should direct browser to http://go/links
Bug: Disable location bar auto-select on click
Status: RESOLVED
Priority: --
Resolution: DUPLICATE
Created: 2020-07-16 19:39:16+00:00
Resolved: 2020-07-17 12:47:57+00:00

When I click on the location bar in Firefox 75+, it automatically selects the entire URL. This is very annoying, because when I click on the location bar, I do it for precisely one reason: To place the cursor in that specific location, so that I can edit the URL. Now every time I want to do this, I have to click, wait and click again (but not too fast, so as to not trigger a double click), or click, draw a selection and then reduce that selection back down to 0 characters, just to work around this new "feature".

It is incredibly awkward. It's also inconsistent with every other textbox on my OS (Linux). But even on Windows, before I ever used Linux, I always disabled 'browser.urlbar.clickSelectsAll', because it is just more usable that way. I've had this setting set to false for the last 10+ years.

Now it's been months since this change dropped, I tried to get used to it, I really did, but it still drives me nuts every single day. Can you *please* make this optional again? I know this is not the first complaint about this issue. I am considering compiling my own version of Firefox at this point, just to work around this issue. This can't be the answer.
Bug: Protection panel "Blocked" heading changed to "Allowed" in some cases
Status: RESOLVED
Priority: --
Resolution: DUPLICATE
Created: 2020-07-16 20:35:42+00:00
Resolved: 2020-08-19 04:16:39+00:00

The heading changed when I don't think it should have.

Gijs, was this an intentional change? Your bug was in the push log.
Bug: Tooltip for hyperlinks overlaps on the previous tooltip
Status: RESOLVED
Priority: --
Resolution: INVALID
Created: 2020-07-16 21:23:05+00:00
Resolved: 2020-07-30 23:51:51+00:00

0. Maximize your Firefox window
1. Open the attachment
2. Hover over the first link
3. Move to the second link
4. And to the third link

Expected: The previous tooltip must disappear
Actual: It remains and a new tooltip overlaps.

Somehow it does not happen when the window is too small. This happens with and without WebRender.