av9ash/GitBugs huggingface dataset:
Bug: When attempting to start sharing the screen, camera sharing is being stopped (on linux, MacOS and windows 7)
Status: NEW
Priority: P2
Created: 2020-05-21 07:23:00+00:00
Resolved: 2024-08-22 13:52:29+00:00

**Note**
* When the user is in a video call and attempts to start screen-sharing, the camera sharing stops; the camera permission is simply killed.

**Affected versions**
* nightly v78.0a1 
* beta b77.0b8

**Affected platforms**
* Windows 7
* Ubuntu 18.04
* MacOS 10.12
* does NOT occur on Windows 10

**Steps to reproduce**
Precond: 
privacy.webrtc.allowSilencingNotifications - true	
privacy.webrtc.legacyGlobalIndicator - false	
1. Engage in a video conference.
2. Allow the microphone and camera sharing.
3. Also, start screen sharing.

**Actual result**
* The camera sharing stops.

**Expected result**
* The camera should not stop sharing.


**Regression range**
It is NOT a feature issue as this also occurs with the feature off OR on a build without the feature altogether (like Release v76.0)

**Additional notes**
* This issue is found to reproduce in Zoom on Windows 7, Ubuntu 18 and MacOS (but not on Windows 10). This appears to be specific to Zoom.
* On Hangouts, the camera share appears to be stopped intendedly and the app automatically asks again for permission of camera share after the screen-share is stopped. The flow is found on ALL OSes.
* On Talky, the camera share does not stop when the screen-sharing begins. Happens with the feature on and off and also happens on all OSes.
* The camera can, however, be permitted (again) after the screen-sharing has started.
* This bug description will suffer changes in the next few days until feature testing is completed.
Bug: Protections panel - [Site not working?] hover effect triggered over the whole row instead of just string
Status: VERIFIED
Priority: P3
Resolution: FIXED
Created: 2020-05-21 09:30:52+00:00
Resolved: 2020-08-21 07:33:11+00:00

**Affected versions**
* 76.0.1, 77.0b7, 78.0a1 (2020-05-20);

**Affected platforms**
* Windows 10, macOS 10.15.4, Ubuntu 18.04;

**Steps to reproduce**
1. Launch Firefox with a fresh profile, and access https://edition.cnn.com/
2. Click on the ETP shield;
3. Hover over the  [Site not working?]  string;
4. On the same [row] move the mouse to the right;

**Expected result**
* hover effect over the  [Site not working?]  string in effect only while mouse cursor is over the string;

**Actual result**
* hover effect applied over  [Site not working?]  while holding mouse on the row;

**Regression range**
* First bad: 2019-07-18
* Last good: 2019-07-17
* Pushlog: [URL](https://hg.mozilla.org/mozilla-central/pushloghtml?fromchange=b6d154b2309846531934289c1e167208fc385ac3&tochange=bc0fdcef296f2d429e3f4b5f29e264ffc185163d)
* not a regression, visible with redesign of panel;

**Additional notes**
* attached recording with the issue.
Bug: Increase in sync pings being submitted without a device id, starting April 14th 2020
Status: RESOLVED
Priority: P1
Resolution: FIXED
Created: 2020-05-21 09:59:40+00:00
Resolved: 2020-07-07 20:09:36+00:00

The sync ping contains "command-sent" and "command-received" events designed to measure the success rate of send-tab. Ideally, for each such event we would be able to identify the submitting device id, thanks to the `device_id` field in the sync ping.

This [redash query](https://sql.telemetry.mozilla.org/queries/71320/source#179171) explores what percentage of events do not have an associated submitting device id. Prior to April 14th 2020 this was hovering at less than 1%, which I think can be safely explained by the known cases in which [we can't submit a device-id](https://searchfox.org/mozilla-central/rev/a40ef31fc9af34a99ceda6d65cdc4573d52b83d2/services/fxaccounts/FxAccountsTelemetry.jsm#77). But after April 14th we see a significant increase, to around 4%.

What's the source of this increase, and how do we fix it? Our first clue might be that it started a few days after the release of Firefox 75, but from slack conversations, we haven't been able to think of anything in that release that might have caused it.

(The graph shows a second increase in early May, which has since subsided back to the ~4% level; this was almost certainly caused by Bug 1636053 and has been resolved)
Bug: urlbar enlarges when focused
Status: RESOLVED
Priority: --
Resolution: INVALID
Created: 2020-05-21 10:05:26+00:00
Resolved: 2020-05-25 13:51:45+00:00

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

Steps to reproduce:

I clicked in the urlbar.


Actual results:

There was this very weird effect where the urlbar grew, partially hiding all the UI elements around it.


Expected results:

I would expect it to stay the same size it was, as it has always done in the past and as any normal user interface behaves.
Bug: Many send-tab telemetry events are missing the peer device id
Status: RESOLVED
Priority: --
Resolution: FIXED
Created: 2020-05-21 10:09:45+00:00
Resolved: 2022-02-23 07:39:43+00:00

The sync ping contains "command-sent" and "command-received" events designed to measure the success rate of send-tab. Ideally, for each such event we would be able to identify the peer device (that is, the device to which our device sent a tab, or from which our device received a tab) by using the "string value" field of the event, which we set to [the target device id on command-sent events](https://searchfox.org/mozilla-central/rev/a40ef31fc9af34a99ceda6d65cdc4573d52b83d2/services/fxaccounts/FxAccountsCommands.js#211) and to the [senderID on command-received events](https://searchfox.org/mozilla-central/rev/a40ef31fc9af34a99ceda6d65cdc4573d52b83d2/services/fxaccounts/FxAccountsCommands.js#247).

This [redash query](https://sql.telemetry.mozilla.org/queries/71320/source#179173) explores what percentage of events do not have an associated peer device id. It shows two interesting things:

1) There's a steady rate of about 15% of events that are missing the peer device id, but that *do* have the submitting device id. The presence of the submitting device id means we can't blame this on an [inability to sanitize the id](https://searchfox.org/mozilla-central/rev/a40ef31fc9af34a99ceda6d65cdc4573d52b83d2/services/fxaccounts/FxAccountsTelemetry.jsm#77).
2) April 14th shows an additional spike of pings that have *neither* the peer device id from the event, nor the submitting device id from the ping itself. That's probably a clue for Bug 1639831.

Why are so many of these events missing the peer device id, and what can be do about it?
Bug: gmail search
Status: RESOLVED
Priority: --
Resolution: INCOMPLETE
Created: 2020-05-21 12:45:12+00:00
Resolved: 2020-06-15 09:31:20+00:00

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

Steps to reproduce:

logged to gmail account


Actual results:

the search window appears small and you cannot enetr any text there


Expected results:

The search window should be bigger and you should be able to enter text for searching
Bug: Open in NIghtly option not visible on an already opened pdf
Status: RESOLVED
Priority: --
Resolution: INVALID
Created: 2020-05-21 14:06:12+00:00
Resolved: 2020-07-01 21:52:41+00:00

**Affected versions**
* Latest Nightly 78.0a1

**Affected platforms**
* macOS 10.15.5 beta 3
* Windows 10 64bit
* Ubuntu 18.04 64bit

**Steps to reproduce**
1. Open latest Nightly
2. Open a pdf in a tab (eg: http://www.africau.edu/images/default/sample.pdf)
3. In a new tab visit about:preferences
4. Change the Action of pdf Content Type to Always Ask
5. Revisit the first tab where the pdf is loaded and refresh the page (remember the save options)
6. Open a new tab and load the same pdf from step 2

**Expected result**
* Open in Nightly option is available in all tabs

**Actual result**
* Open in Nightly option is not available in already opened files from other tabs.

**Regression range**
* This is not a regression since it also reproduces on the first build where this was enabled for the first time (bug 1638682)

**Additional notes**
* Screencast attached showing the issue
* I am not sure if this is actually the correct behavior and the content from the tab that's already opened does not qualify as Unknown Content type.
Bug: Crash in [@ OOM | large | mozalloc_abort | <name omitted> | <dogear::tree::Tree as core::convert::TryFrom<dogear::tree::Builder>>::try_from ]
Status: RESOLVED
Priority: P5
Resolution: WORKSFORME
Created: 2020-05-21 20:46:54+00:00
Resolved: 2020-11-11 00:15:28+00:00

This bug is for crash report bp-34da10d4-80ac-4142-862f-76b0a0200520.

```
Top 10 frames of crashing thread:

0 libmozglue.dylib mozalloc_abort memory/mozalloc/mozalloc_abort.cpp:33
1 libmozglue.dylib <name omitted> memory/mozalloc/mozalloc_oom.cpp:51
2 XUL gkrust_shared::oom_hook::hook toolkit/library/rust/shared/lib.rs:221
3 XUL rust_oom src/libstd/alloc.rs:240
4 XUL alloc::alloc::handle_alloc_error src/liballoc/alloc.rs:268
5 XUL <dogear::tree::Tree as core::convert::TryFrom<dogear::tree::Builder>>::try_from third_party/rust/dogear/src/tree.rs
6 XUL <bookmark_sync::store::Store as dogear::store::Store>::fetch_remote_tree toolkit/components/places/bookmark_sync/src/store.rs:440
7 XUL bookmark_sync::merger::MergeTask::merge third_party/rust/dogear/src/store.rs:75
8 XUL <bookmark_sync::merger::MergeTask as moz_task::Task>::run toolkit/components/places/bookmark_sync/src/merger.rs:217
9 XUL moz_task::TaskRunnable::allocate::Run xpcom/rust/moz_task/src/lib.rs:132

```

There's only a single instance of this crash, which has Rust Sync code in the stack, but it might be worth looking at, because the OOM allocation size is 16,565,899,576,099,806,975 bytes, which suggests that something has gone terribly wrong.
Bug: Tags Are No Longer Draggable
Status: RESOLVED
Priority: --
Resolution: WORKSFORME
Created: 2020-05-21 22:54:33+00:00
Resolved: 2023-10-10 13:49:43+00:00

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

Steps to reproduce:

I upgrade to 76.0.1 and tabs in my tab bar can no longer be dragged/reordered.



Expected results:

Tags should still be draggable.

OSX 10.10
Bug: 2 installations of Firefox in Uninstall and Remove programs
Status: RESOLVED
Priority: --
Resolution: DUPLICATE
Created: 2020-05-22 00:31:40+00:00
Resolved: 2020-05-22 07:43:10+00:00

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

Steps to reproduce:

What I did was got a Firefox update today. I decided to update it and saw two update versions of Firefox. One from yesterday shows 75.0 and one today 76.0.1 and it shows two X64 update installations in Uninstall and Remove the programs control panel. Usually from experience Firefox updates have ONE installation. Don't know if this was a Operating System error or your end. I THINK this is Firefox's end.


Actual results:

"What I did was got a Firefox update today. I decided to update it and saw two updated versions of Firefox. One from yesterday shows 75.0 and one today 76.0.1 and it shows two X64 update installations in Uninstall and remove the programs control panel. Usually from experience Firefox updates have ONE installation. Don't know if this was an Operating System error or your end. I THINK this is Firefox's end. "  What I will do is remove the 75.0 and stick with the recent update because I do NOT normally see two firefox in uninstall program section and it should be looked into it in case.


Expected results:

One update installation and the previous update removed automatically and should only show ONE firefox version in Control Panel via the Add and Remove Program section list. I am using desktop version Windows 10 64bit Home.
Bug: Firefox Nightly addon UIs are white-on-white
Status: RESOLVED
Priority: --
Resolution: FIXED
Created: 2020-05-22 03:36:22+00:00
Resolved: 2020-07-01 21:49:55+00:00

I'm on MacOS Firefox Nightly 78.0a1 20200521214934. My update history says I was on 20200521093657 previously, and that didn't exhibit this behavior.

Essentially, all my addon UIs are blank. The addon icons to the right of the awesomebar show up properly, but when I click on them, they show me a white rectangle where UI would be. If I click on the rectangle, things happen, so the buttons and functionality are there. The UI is just pure white. I have a screenshot I'll attach.

Disabling all but one addon doesn't seem to help; I've tried a number of combinations. Disabling all addons, or restarting with addons disabled, helps, because I can no longer get to the addon UI.

I had fission enabled a while back, but I've refreshed nightly (purged my profile) since, and I don't have fission enabled currently.

I'm not able to see anything informative in the console.
Bug: Request to access cookie: Incorrect message in console when *Content Blocking* is disabled but *Enhanced Tracking Protection* is enabled
Status: NEW
Priority: P3
Created: 2020-05-22 09:11:29+00:00
Resolved: 2023-04-03 12:15:31+00:00

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

Steps to reproduce:

Launch a new profile, go to https://www.resoneo.com/
By default, Enhanced Tracking Protection is enabled, NOT Content Blocking


Actual results:

In console I get messages like 

Request to access cookie or storage on “<URL>” was blocked because it came from a tracker and *content blocking* is enabled
Request to access cookie or storage on “https://platform.twitter.com/widgets/widget_iframe.2a0082900…adde2d7b849b06a0bb.html?origin=https%3A%2F%2Fwww.resoneo.com” was blocked because it came from a tracker and *content blocking* is enabled

Indeed cookies are blocked on that request, but because of Enhanced Tracking Protection being enabled, not because of Content Blocking

This message is inaccurate and misleading to developers willing to understand what is happening and how Firefox Content Blocking may affect their site usability and behavior


Expected results:

It should say

Request to access cookie or storage on “https://platform.twitter.com/widgets/widget_iframe.2a0082900…adde2d7b849b06a0bb.html?origin=https%3A%2F%2Fwww.resoneo.com” was blocked because it came from a tracker and *enhanced tracking protection* is enabled
Bug: Firefox window "hidden" upon open
Status: RESOLVED
Priority: --
Resolution: WORKSFORME
Created: 2020-05-22 09:53:24+00:00
Resolved: 2020-05-23 14:45:56+00:00

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

Steps to reproduce:

Start Firefox
Desktop manager shows Firefox has focus


Actual results:

FF window cannot be found- menu is shown, but the window is not.
Have to open Desktop / Spaces Manager, drag to another monitor.


Expected results:

Able to start using FF upon open

macOS 10.14.6
External + Internal Monitor selected.
Have deleted plist file.
Have not reset profile because I don't have time to setup up everything again (I have to manage multiple PCs in addition to "real" work so life is too short)
Bug: JSON dump not found when using preview collection
Status: VERIFIED
Priority: P3
Resolution: FIXED
Created: 2020-05-22 10:45:00+00:00
Resolved: 2020-07-21 15:52:49+00:00

We load the JSON dump from `.../dumps/{bucketName}/{collectionName}.json`.
 
When pointing the browser at the preview collection, the bucketName becomes `main-preview` and the dump isn't found. The main consequence is that a full sync is done on `.get()` with fresh profiles (involving network calls), instead of just loading the packaged dump.

Since the preview collection shares history with the main collection, we could load the dump from `${bucketName.replace("-preview", "")}/${collectionName}.json`.
Bug: Link launches broken Firefox instance
Status: RESOLVED
Priority: --
Resolution: INCOMPLETE
Created: 2020-05-22 12:16:59+00:00
Resolved: 2023-04-02 00:48:38+00:00

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

Steps to reproduce:

Received survey request with a link from Post Handler in Australia. On clicking on the link it launches FF but it's a broken/unresponsive window. 

[Image "Australia" ignored] [links to https://click.notifications.auspost.com.au/?qs=5adfb5ffa8a98e2ec67ca2599b40710172a14691e2feadcd8315775a919394a2c348367c6239d4ea87cab2a1812d2a07e928c81d611408fb66ad1cb9ef348c4d]


Actual results:

Window launch is broken. Only way to close is via task bar > right click > close window. 

See image attached. 


Expected results:

Normal window open with address and so on.
Bug: [Windows] Vertical line appears in drag space when drag space is enabled
Status: RESOLVED
Priority: --
Resolution: DUPLICATE
Created: 2020-05-22 13:40:26+00:00
Resolved: 2020-05-23 12:12:36+00:00

**Affected versions**
* Firefox 77.0b9
* Firefox 76.0
* latest Nightly 78.0a1

**Affected platforms**
* Windows 8.1 32bit
* Windows 10 64bit

**Steps to reproduce**
1. Start Firefox
2. Click hamburger menu
3. Click Customize
4. Tick Drag Space
5. Exit Customize

**Expected result**
* No graphical issues can be seen in the tab bar

**Actual result**
* Vertical line appears in the left side of the first tab which reaches to the top of the page.

**Regression range**
* First bad: 2018-12-11
* Last good: 2018-12-10
* Pushlog: https://hg.mozilla.org/mozilla-central/pushloghtml?fromchange=13f891b92db19ea8ec85ef329eff7a793c8b368f&tochange=ac7f3beb633340c6b3fea25059e8b8aa52b5fc8a
* Potential regressor: Not sure which is the regressor here, multiple bugs in the pushlog and could not go deeper with mozregression since this is a very old regression.

**Additional notes**
* Screenshot showing the issue attached.
Bug: [Windows 8.1] Missing left border on the first tab when Menu Bar is enabled
Status: NEW
Priority: --
Created: 2020-05-22 13:53:26+00:00
Resolved: 2020-06-17 14:32:23+00:00

**Affected versions**
* Firefox 77.0b9
* Firefox 76.0
* latest Nightly 78.0a1

**Affected platforms**
* Windows 8.1 32bit

**Unaffected platforms**
* Windows 10 64bit
* Ubuntu 18.04 64bit
* MacOS 10.15.5 beta 3

**Steps to reproduce**
1. Start Firefox
2. Enable Menu Bar (right click in tab bar and enable Menu Bar)

**Expected result**
* No visual defects can be seen in the Tabbar

**Actual result**
* Left border of the first Tab is missing

**Regression range**
* First bad: 2017-09-26
* Last good: 2017-09-27
* Pushlog: https://hg.mozilla.org/mozilla-central/pushloghtml?fromchange=33b7b8e81b4befcba503c0e48cd5370aeb715085&tochange=7d15bc419c6cd7e9f3b4d41370c3b0e5990c8d1b
* Potential regressor: Not sure which one could be the regressor here, someone who is involved in this area maybe able to determine the culprit.

**Additional notes**
* Image with the issue is attached.
Bug: [macOS] Glitches in the Protection panel while scrolling a long list of cookies
Status: RESOLVED
Priority: P3
Resolution: WORKSFORME
Created: 2020-05-22 15:02:05+00:00
Resolved: 2024-03-13 15:27:21+00:00

**Affected versions**
* latest Nightly 78.0a1
* Beta 77.0b9
* Release 76.0.1

**Affected platforms**
* macOS 10.15

**Steps to reproduce**
1. Launch Firefox.
2. Navigate to about:preferences#privacy.
3. Select the Custom option and from the Cookies section, click on the drop-down menu, then select "All third-party cookies (may cause website to break)".
3. Access a site that has lots of 3rd party cookies, e.g. https://www.prosport.ro/
4. From the URL click on the shield icon.
5. Click on the  "Third-Party Cookies" from the protection panel.
6. Scroll slowly through cookies via the scrollbar.

**Expected result**
* No UI issues can be observed at the bottom of the panel.

**Actual result**
* UI glitches can be observed at the bottom of the panel.

**Regression range**
* This does not seem to be a regression, since I was able to reproduce this on older version as well, e.g. Firefox 70.0 (where the ETP panel was redesigned).

**Additional notes**
* I was not able to reproduce on other mac machines, this may be an issue that affects only macs with retina display. 
* Configuration used: MacBook	Intel Core i7 (2.8 GHz) "Nvidia GeForce GT 750M 2GB
Intel Iris Pro 1536 MB"
* [Please observe the screencast with the issue](https://drive.google.com/file/d/1OCJBEnaBbSHEX2Z5rj6p6Asv5rP-NXuE/view?usp=sharing).
Bug: Find will not find text if entered with diacritics ("nikud") in Hebrew for PDF viewer
Status: RESOLVED
Priority: P1
Resolution: FIXED
Created: 2020-05-22 16:59:22+00:00
Resolved: 2023-02-14 12:54:37+00:00

trying to find הספר with match diacritics turned off does not find  הַסֵּפֶר in the following pdf:

https://www.machonso.org/uploads/images/%D7%95%D7%95%D7%9C%D7%A3.pdf
Bug: Perma browser_UsageTelemetry_urlbar.js | unexpected counts should be zero for FX_URLBAR_SELECTED_RESULT_INDEX at index 1 - 1 == 0 when Gecko 78 merges to Beta on 2020-06-01
Status: VERIFIED
Priority: P1
Resolution: FIXED
Created: 2020-05-22 21:31:18+00:00
Resolved: 2020-05-29 10:40:10+00:00

central-as-beta simulation: https://treeherder.mozilla.org/#/jobs?repo=try&group_state=expanded&selectedTaskRun=DdiAK-jSTsifIfoTaVGj0g-0&resultStatus=testfailed%2Cbusted%2Cexception%2Cretry%2Cusercancel%2Crunnable&revision=0799f0ae22aa66449b8845124b82a77f8ef2061f&searchStr=browser-chrome

Log: https://treeherder.mozilla.org/logviewer.html#?job_id=303382464&repo=try

17:07:40 INFO - TEST-UNEXPECTED-FAIL | browser/modules/test/browser/browser_UsageTelemetry_urlbar.js | unexpected counts should be zero for FX_URLBAR_SELECTED_RESULT_INDEX at index 1 - 1 == 0 - JS frame :: resource://testing-common/TelemetryTestUtils.jsm :: assertHistogram :: line 297
4290	17:07:40 INFO - TEST-UNEXPECTED-FAIL | browser/modules/test/browser/browser_UsageTelemetry_urlbar.js | expected counts should match for FX_URLBAR_SELECTED_RESULT_INDEX at index 2 - 0 == 1 - JS frame :: resource://testing-common/TelemetryTestUtils.jsm :: assertHistogram :: line 291
4301	17:07:40 INFO - TEST-UNEXPECTED-FAIL | browser/modules/test/browser/browser_UsageTelemetry_urlbar.js | unexpected counts should be zero for FX_URLBAR_SELECTED_RESULT_INDEX_BY_TYPE_2 at index 1 - 1 == 0 - JS frame :: resource://testing-common/TelemetryTestUtils.jsm :: assertKeyedHistogramValue :: line 360
4306	17:07:40 INFO - TEST-UNEXPECTED-FAIL | browser/modules/test/browser/browser_UsageTelemetry_urlbar.js | expected counts should match for FX_URLBAR_SELECTED_RESULT_INDEX_BY_TYPE_2 at index 2 - 0 == 1 - JS frame :: resource://testing-common/TelemetryTestUtils.jsm :: assertKeyedHistogramValue :: line 354
Bug: Firefox has just been updated in the background. Click Restart firefox to complete the update.
Status: RESOLVED
Priority: --
Resolution: WORKSFORME
Created: 2020-05-22 22:15:50+00:00
Resolved: 2020-09-01 13:32:44+00:00

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

Steps to reproduce:

I have downloaded mozilla firefox 68.8.0 esr version and installed on my win10 machine. Then i launched the shortcut and its throwing me an error to restart firefox. 


Actual results:

Then i did restart the firefox it launches automatically and still shows same error.


Expected results:

Am i doing any wrong ?