av9ash/GitBugs huggingface dataset:
Bug: New Proton Tabs Bar design does not blend well with the Windows 7 specific glassy window
Status: RESOLVED
Priority: P2
Resolution: FIXED
Created: 2021-03-12 10:31:19+00:00
Resolved: 2021-04-01 08:43:39+00:00

**Affected Version:**
Firefox Nightly 88.0a1
In about:config set
browser.proton.enabled = true
browser.proton.tabs.enabled = true

**Affected Platform:**
Windows 7

**Steps to reproduce:**
1. Launch Firefox Nightly with proton prefs enabled on Windows 7
2. Open multiple tabs and don't maximize the browser

**Expected Result:**
The new proton tabs design should blend better or match with the default Windows 7 glassy window. Increasing/Decreasing the transparency in windows7 window settings outlines this issue even more.

**Actual Result:**
Proton Tabs does not blend well with the Windows 7 specific glassy window when the window is not maximized

Screenshot 1: https://drive.google.com/file/d/1wFYOHN9KCPPFVijEs_j42KdsGuC3hxFT/view?usp=sharing
Screenshot 2:  https://drive.google.com/file/d/1etrKBNhTg9tkG8Mnnyq9LXwJtnnui0-s/view?usp=sharing
Bug: freeze, stop loading not working
Status: RESOLVED
Priority: --
Resolution: INCOMPLETE
Created: 2021-03-12 10:50:57+00:00
Resolved: 2021-04-07 17:48:55+00:00

User Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:85.0) Gecko/20100101 Firefox/85.0

Steps to reproduce:

Enter google search, then follow one of the links. Some links will load all right, other links take a long time to load (not browser's fault).


Actual results:

When a tab takes forever to load, the STOP button doesn't stop it. The tab just "freezes" loading something forever -- and the whole browser along with it. Until some time would pass, then it unfreezes.


Expected results:

STOP button should actually stop the broken page/script loading process immediately. A problem in loading one tab should not affect the whole browser with ALL its open tabs (windows users have fashion of opening 20+ tabs at once and keep them open).
Bug: [Proton] Hamburger Menu is too wide using DE builds
Status: VERIFIED
Priority: P2
Resolution: FIXED
Created: 2021-03-12 12:21:23+00:00
Resolved: 2021-05-24 17:41:18+00:00

#### Tested with:

Nightly 88.0a1 (2021-03-12)
#### Tested on:

Windows 10
Windows 7
MacOS 11
Ubuntu 20.04

#### Preconditions:

In about:config, set browser.proton.enabled = true
Have a DE build installed.
#### Steps:

  1. Launch a DE firefox Nightly build and open the Hamburger menu.

#### Actual result:

The Hamburger menu is too wide.
#### Expected result:

The long strings should be displayed in two rows (according to Figma) and the Hamburger Menu should have the same size like in other builds.

#### Notes:
In Figma, the Hamburger menu from DE builds has the normal size and the long strings are displayed in two rows.
Bug: The "Saved to Library!" toast is displayed connected to the hamburger menu although the new Proton menu no longer has Library section
Status: VERIFIED
Priority: P1
Resolution: FIXED
Created: 2021-03-12 12:25:54+00:00
Resolved: 2021-03-25 13:27:06+00:00

**Affected Version:**
Latest Nightly 88.0a1 (2021-03-12)
browser.proton.enabled

**Tested Platforms:**
Windows 7/10, MacOs 

**Steps to reproduce:**
1. Go to any site and bookmark it
2. Notice the "Saved to Library!" toast dropping down from the hamburger menu button
3. Open the menu

**Expected Result:**
The user expects a section named "Library" which was suggested by the displayed toast. 

**Actual Result:**
Due to Proton changes the library section is no longer available in the menu.
Screenshot: https://drive.google.com/file/d/1Up_dLAF8bwxSD8lW-_0fs3K_4XMBSM2h/view
Bug: [Proton] Ugly bookmark icon inside context menu on Windows 10
Status: RESOLVED
Priority: --
Resolution: DUPLICATE
Created: 2021-03-12 12:36:57+00:00
Resolved: 2021-03-12 14:37:09+00:00

**Affected versions**
* Latest Nightly 88.0a1

**Unaffected versions**
* Firefox 87.0b9
* Firefox 86.0.1

**Affected platforms**
* Windows 10 only

**Steps to reproduce**
1. Start Firefox
2. Open a random website
3. Right click inside the page

**Expected result**
* Bookmark this page icon design is nice and fine.

**Actual result**
* Bookmarks this page icon looks washed.

**Regression range**
* Not a regression, this is reproducible since the new menu style was implemented in bug 1682522.

**Additional notes**
* Image showing the issue is attached.

**Suggested severity**
* I would make it an S3 severity issue since it's a design issue.
Bug: The Firefox Account icon is displayed in the toolbar overflow menu when the user is not signed in
Status: VERIFIED
Priority: P1
Resolution: FIXED
Created: 2021-03-12 12:42:40+00:00
Resolved: 2021-03-25 13:26:06+00:00

**Affected Version:**
Latest Nightly 88.0a1 (2021-03-12)
browser.proton.enabled
browser.proton.toolbar.enabled

**Tested Platforms:**
Windows 7/10, MacOs 

**Steps to reproduce:**
1. Launch Firefox and add some Toolbar icons using the Customize Toolbar...setting
2. Shrink the window until the overflow >> button is displayed for the toolbar
3. Click on the overflow menu button

**Expected Result:**
Only the icons the are placed on the toolbar should be displayed in the overflow menu

**Actual Result:**
The Firefox Account icon is displayed in the overflow menu (no signed in user)
Gif: https://drive.google.com/file/d/1e7GhzX6R84-ALEwgjvdE4c2nfwC4RZcn/view

**Note:**
This is specific to Proton Related changes. On Firefox Release 86 if I remove the Firefox Account icon from the toolbar (on Proton it is already removed when the user is not signed in), the icon will not be displayed in the overflow menu.
Bug: Adding a topsite manually shows a white logo for some seconds.
Status: RESOLVED
Priority: --
Resolution: INVALID
Created: 2021-03-12 14:46:16+00:00
Resolved: 2022-01-10 12:41:36+00:00

When I add a topsite manually for some seconds the image is completely blank.
On older versions of firefox (for example firefox 85) when i add a topsite manually i see an image with the first letter of the word. (see image attached)


**Tested on**

Windows10 64bit, MacOS 10.15, Ubuntu 20 64bit

Firefox Release   86    Reproducible
Firefox nightly 88.0a1  Reproducible
Firefox Beta 87.0b9     Reproducible

**Steps**
- Launch Firefox
- Open new tab
- Add new topsite manually
- For topsite enter Title: Sony  , url : www.sony.com
- Check for some seconds the newly added topsite


**Actual result**
 1) the image is completely blank
 2) there is a black image some seconds after with an S in the corner.


**Expected result**
 1) At first, Instead of blank, an "S" should appear as the topsite image.





**regression**

2021-03-12T14:58:26: DEBUG : Found commit message:
Bug 1680531 - top sites icons. r=prathiksha,thecount
Differential Revision: https://phabricator.services.mozilla.com/D99149
2021-03-12T14:58:26: DEBUG : Did not find a branch, checking all integration branches
2021-03-12T14:58:26.005000: INFO : The bisection is done.
2021-03-12T14:58:26.005000: INFO : Stopped
Bug: Fix session restore for about:reader
Status: RESOLVED
Priority: P2
Resolution: FIXED
Created: 2021-03-12 15:00:22+00:00
Resolved: 2021-03-24 04:13:44+00:00

The non-SHIP code restores about:reader scroll position after receiving ["AboutReaderContentReady"](https://searchfox.org/mozilla-central/rev/9ae77e4ce3378bd683ac9a86b729ea6b6bd22cb8/toolkit/components/reader/AboutReader.jsm#959-962). The SHIP code that was written in bug 1597499 doesn't do this yet. We'll need to wait for this event or the similar ["AboutReader:Ready" window notification](https://searchfox.org/mozilla-central/rev/9ae77e4ce3378bd683ac9a86b729ea6b6bd22cb8/toolkit/components/reader/AboutReader.jsm#956) when restoring an about:reader page.

This will fix browser/components/sessionstore/test/browser_scrollPositionsReaderMode.js.

Anny is looking into this.
Bug: Hiding Top sites is slow  for the last 10%
Status: RESOLVED
Priority: --
Resolution: INVALID
Created: 2021-03-12 15:32:13+00:00
Resolved: 2023-12-19 03:41:30+00:00

**Note**
This issue only occurs  when Firefox is in the default window mode(Not fullscreen)
This issue  is not proton related put is still visible with proton active.

**Affected versions**
* Fx 86.0.1
  Fx  87.0b9

**Affected platforms**
*Windows 10
 Ubuntu 18.04 

**Steps to reproduce**
1. Start Firefox.
(Optional) Switch Firefox to dark theme.
2. Open a new tab with about:newtab.
3. Click on the arrow next to top sites to hide the section.

**Expected result**

*The transition to hidden for top sites is smooth.

**Actual result**

* The transition is not  smooth because of slowing  down on the last 10%. 

**Suggested Severity**

*  S3

**Regression range**

* First bad:2020-07-17

* Last good:2020-07-16

* Pushlog: https://hg.mozilla.org/integration/autoland/pushloghtml?fromchange=5c0655bc9561b1b55a7c4f3067372feef2f9c750&tochange=e6d05205d337b1d737f228103ea261205d4a1cf6

* Potential regressor
Bug 1649292 - Make multistage about:welcome as default UX r=Mardak

**Additional notes**
This issue  is not proton related put is still visible with proton active.
This issue only occurs  when Firefox is in the default window mode(Not fullscreen)
This issue is fixed in the currently  Nightly (03.12.2021)
Bug: Can not add search engine behind HTTP basic auth
Status: RESOLVED
Priority: --
Resolution: WORKSFORME
Created: 2021-03-12 15:39:09+00:00
Resolved: 2021-04-13 13:29:52+00:00

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

Steps to reproduce:

Go to a search engine behind HTTP authentication (over https, might not matter).
Enter correct username & password and save.
Click triple dots in address bar -> Add search engine


Actual results:

Error:
Firefox could not download the search plugin from: <host>/opensearch.xml



Expected results:

opensearch.xml file downloaded using the saved http auth data and added.
Bug: Focus not visible on web content dialog (alert) prompt buttons when the containing window is not active/focused at the moment the dialog appears
Status: RESOLVED
Priority: P3
Resolution: WORKSFORME
Created: 2021-03-12 17:55:09+00:00
Resolved: 2021-03-22 16:16:10+00:00

Reported by Vicky via slack: the focus indicator isn't always present in content modal dialogs. She's seeing it missing on Windows when gcal switches tabs because it alerts for an event. With a quick manual test using `setTimeout` to invoke `alert`, I'm not able to reproduce quickly on current nightly, so not entirely sure what is happening, but we should probably look into it...
Bug: Intermittent TV toolkit/components/normandy/test/browser/browser_RecipeRunner.js | getCapabilities should be called -
Status: RESOLVED
Priority: P5
Resolution: INCOMPLETE
Created: 2021-03-12 21:11:20+00:00
Resolved: 2021-04-06 17:06:52+00:00

**Filed by:** btara [at] mozilla.com
**Parsed log:** https://treeherder.mozilla.org/logviewer?job_id=333047003&repo=autoland
**Full log:** https://firefox-ci-tc.services.mozilla.com/api/queue/v1/task/RSprINZcSc-R65gmYZBtPg/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/RSprINZcSc-R65gmYZBtPg/runs/0/artifacts/public/logs/live_backing.log&only_show_unexpected=1

---
```
...
[task 2021-03-12T19:01:52.780Z] 19:01:52     INFO - Entering test bound test_run_includesCapabilities
[task 2021-03-12T19:01:52.780Z] 19:01:52     INFO - Buffered messages finished
[task 2021-03-12T19:01:52.780Z] 19:01:52     INFO - TEST-UNEXPECTED-FAIL | toolkit/components/normandy/test/browser/browser_RecipeRunner.js | getCapabilities should be called - 
[task 2021-03-12T19:01:52.780Z] 19:01:52     INFO - Stack trace:
[task 2021-03-12T19:01:52.780Z] 19:01:52     INFO - chrome://mochikit/content/browser-test.js:test_ok:1331
[task 2021-03-12T19:01:52.780Z] 19:01:52     INFO - chrome://mochitests/content/browser/toolkit/components/normandy/test/browser/browser_RecipeRunner.js:test_run_includesCapabilities:281
[task 2021-03-12T19:01:52.780Z] 19:01:52     INFO - Leaving test bound test_run_includesCapabilities
...```
Bug: Accessing currentURI of a lazy browser while the browser is swapped corrupts the cached currentURI
Status: RESOLVED
Priority: --
Resolution: FIXED
Created: 2021-03-12 21:33:01+00:00
Resolved: 2021-03-27 09:46:01+00:00

There was a regression in extensions (bug 1694699) due to an incorrect value for `currentURI`. I have fixed the trigger in bug 1694699 for that specific test case and fixed another trigger in bug 1695346. But these fixes didn't touch the root cause in the tabbrowser/session restore code. I'll attach the fix for the root cause along with a regression test to this bug.

See https://bugzilla.mozilla.org/show_bug.cgi?id=1695346#c1 for a concise explanation of the bug (and the fix).
Bug: Newtab linting scripts that rely on top level mach lint aren't working in a Windows dev environment
Status: NEW
Priority: P3
Created: 2021-03-12 23:13:59+00:00
Resolved: 2023-01-06 20:08:48+00:00

While investigating [bug 1694772](https://bugzilla.mozilla.org/show_bug.cgi?id=1694772) I came across an issue where any of the newtab yamscripts that start with `cd $npm_package_config...` fail to run with the error message "The system cannot find the path specified". (this includes mochitest and lint scripts.)

As well, running `./mach lint` directly fails with a couple errors, 
'The system cannot find the file specified`,
'AttributeError: "Process" object has no attribute "_job"'

...though this could be related to the first problem, if `./mach lint` isn't running from the correct location.

I'm mostly wondering if anyone can duplicate this, or if I can put it down to an issue with my local build.
Bug: Intermittent browser/components/preferences/tests/browser_search_within_preferences_command.js | Test timed out - | Found a tab after previous test timed out: about:preferences#privacy -
Status: RESOLVED
Priority: P5
Resolution: INCOMPLETE
Created: 2021-03-12 23:56:54+00:00
Resolved: 2021-04-06 17:07:04+00:00

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

---
```
[task 2021-03-12T22:51:43.195Z] 22:51:43     INFO - TEST-START | browser/components/preferences/tests/browser_search_within_preferences_command.js
[task 2021-03-12T22:56:22.800Z] 22:56:22     INFO - TEST-INFO | started process screentopng
[task 2021-03-12T22:56:23.521Z] 22:56:23     INFO - TEST-INFO | screentopng: exit 0
[task 2021-03-12T22:56:23.524Z] 22:56:23     INFO - Buffered messages logged at 22:51:43
[task 2021-03-12T22:56:23.524Z] 22:56:23     INFO - Entering test bound 
[task 2021-03-12T22:56:23.524Z] 22:56:23     INFO - Buffered messages finished
[task 2021-03-12T22:56:23.524Z] 22:56:23     INFO - TEST-UNEXPECTED-FAIL | browser/components/preferences/tests/browser_search_within_preferences_command.js | Test timed out - 
[task 2021-03-12T22:56:24.430Z] 22:56:24     INFO - GECKO(1561) | MEMORY STAT | vsize 130552373MB | residentFast 4609MB
[task 2021-03-12T22:56:24.430Z] 22:56:24     INFO - TEST-OK | browser/components/preferences/tests/browser_search_within_preferences_command.js | took 281226ms
[task 2021-03-12T22:56:24.430Z] 22:56:24     INFO - Not taking screenshot here: see the one that was previously logged
[task 2021-03-12T22:56:24.430Z] 22:56:24     INFO - TEST-UNEXPECTED-FAIL | browser/components/preferences/tests/browser_search_within_preferences_command.js | Found a tab after previous test timed out: about:preferences#privacy - 
[task 2021-03-12T22:56:24.807Z] 22:56:24     INFO - checking window state
[task 2021-03-12T22:56:24.988Z] 22:56:24     INFO - TEST-START | browser/components/preferences/tests/browser_searchsuggestions.js
[task 2021-03-12T23:02:36.176Z] 23:02:35     INFO - Buffered messages logged at 22:56:25
[task 2021-03-12T23:02:37.160Z] 23:02:36     INFO - Entering test bound setup
[task 2021-03-12T23:02:38.235Z] 23:02:37     INFO - Leaving test bound setup
[task 2021-03-12T23:02:39.561Z] 23:02:38     INFO - Entering test bound test_suggestions_start_enabled
[task 2021-03-12T23:02:40.021Z] 23:02:38     INFO - Buffered messages finished
[task 2021-03-12T23:02:40.892Z] 23:02:40    ERROR - TEST-UNEXPECTED-TIMEOUT | browser/components/preferences/tests/browser_searchsuggestions.js | application timed out after 370 seconds with no output
[task 2021-03-12T23:02:41.616Z] 23:02:40    ERROR - Force-terminating active process(es).```
Bug: Proton Tab Styling Conflicts with Container Tabs Indicator - Compact Mode
Status: RESOLVED
Priority: --
Resolution: WORKSFORME
Created: 2021-03-13 00:20:12+00:00
Resolved: 2021-03-20 05:17:03+00:00

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

Steps to reproduce:

Similar to https://bugzilla.mozilla.org/show_bug.cgi?id=1690186, enable Proton and Compact Mode with Container Tabs, and play some media, such as any youtube video.


Actual results:

The now playing indicator has insufficient space between itself and the Container indicator, looking unintended. This can be seen in the attached screenshot.


Expected results:

The now playing indicator should have sufficient space between itself and the container indicator.
Bug: Reconsider how much vertical space Proton toolbars consume
Status: RESOLVED
Priority: P2
Resolution: FIXED
Created: 2021-03-13 08:18:59+00:00
Resolved: 2025-03-02 14:51:26+00:00

(In reply to Kirk Steuber (he/him) [:bytesized] from bug 1693028 comment #60)
> > FWIW, the Lenovo Yoga C630 has a resolution of 1920x1080 and defaults to 150% scaling (Windows 10).
> 
> I believe this works out to `1080px/1.5 = 720px` in available height. Bug 1693028 comment 1 indicates that Windows has a taskbar height of 40px. I believe that this leaves 680 pixels of usable height. This is substantially less than the 768 pixel minimum height that the user story says that we are planning to optimize for.

This begs the question whether we need to reduce vertical space consumption with normal density. Proton makes us consume significantly more space than competitors, see attachment 9204237. If this was done based on the same shaky data that led to bug 1693028 (see bug 1693028 comment 53), that's a problem; it means we've optimized for a fictive user population.
Bug: LockException: Firefox Sync not working
Status: RESOLVED
Priority: --
Resolution: INVALID
Created: 2021-03-13 10:32:41+00:00
Resolved: 2021-03-14 23:21:08+00:00

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

Steps to reproduce:

I have been trying to setup Firefox Sync for my account several times, but it is still not working. I have deleted my old Firefox account and created a new one, I have disabled add-ons which might block traffic to the Sync servers, I have deleted the "weave" folder in my Firefox profile. Still, Sync is not behaving properly.


Actual results:

See attached log. I suspect that this is the error:
"Exception calling anonymous function: LockException: Could not acquire lock. Label: "service.js: sync".(resource://services-sync/util.js:62:5) JS Stack trace: LockException@util.js:62:5
throwLockException@util.js:148:11
WrappedLock@util.js:162:15
_lockedSync@service.js:1370:6
sync/<@service.js:1334:18
WrappedCatch@util.js:133:27
sync@service.js:1335:7"

However, I have no idea what causes this error. The bookmarks seem to sync correctly (although I can't see the synced bookmarks in my mobile browser). In my profile's "weave" folder, empty JSON documents are generated within the folders "changes", "failed" and "toFetch", for "addons", "bookmarks", "clients", and so on.


Expected results:

Sync should have completed successfully. I remember that years ago it did, but I haven't used Sync much ever since. However, in the recent weeks, I have tried several times to get it working again - still without success.
Bug: Session restored even if forbidden by preferences
Status: RESOLVED
Priority: --
Resolution: INCOMPLETE
Created: 2021-03-13 10:39:06+00:00
Resolved: 2021-11-09 05:51:11+00:00

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

Steps to reproduce:

1. Go to preferences and uncheck "Restore previous session" under "Startup"
2. When you reopen Firefox, the tabs that were open when you closed it are restored


Actual results:

See 2


Expected results:

Firefox should open with no tabs, since the session should not be saved
Bug: in hcm, date and time subfields should be highlighted when focused
Status: RESOLVED
Priority: --
Resolution: FIXED
Created: 2021-03-13 14:32:53+00:00
Resolved: 2021-04-21 12:54:08+00:00

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

Steps to reproduce:

In any win HCM theme, tab to any date or time control


Actual results:

no highlighting of focused subfields


Expected results:

focused subfields should be highlighted (preferably using Highlight/HighlightText system color pair)
Bug: [Non-Proton] Compact mode icon spacing is larger now, even larger than normal mode
Status: RESOLVED
Priority: --
Resolution: DUPLICATE
Created: 2021-03-13 14:37:42+00:00
Resolved: 2021-03-14 13:48:30+00:00

User Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:88.0) Gecko/20100101 Firefox/88.0
Build ID: 20210313094300

Please see the attached screenshot.

:ntim, thank you for trying to keep Proton compact mode alive.
Bug: Dark Reader Addon Not Rendering Properly
Status: RESOLVED
Priority: --
Resolution: DUPLICATE
Created: 2021-03-13 14:44:28+00:00
Resolved: 2021-03-13 14:56:00+00:00

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

Steps to reproduce:

Enable Dark Reader Add On
Run Firefox Nightly
Goto https://www.usatoday.com/ 



Actual results:

Dark web site rendering does not appear correctly. Most noticeable in the header, and body of the page. Colors not properly inverted.


Expected results:

Dark colors should appear in header. And text should be readable in the body of the page.
Bug: nearly? invisible next/prev arrows on find-in-page w/o any text entered yet
Status: RESOLVED
Priority: --
Resolution: WORKSFORME
Created: 2021-03-13 15:43:44+00:00
Resolved: 2023-09-27 16:09:59+00:00

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

Steps to reproduce:

Ctrl-F to open find in page widget


Actual results:

nearly? invisible next/prev arrows on find-in-page w/o any text entered yet


Expected results:

visible next/prev arrows on find-in-page w/o any text entered yet.
Suggest at least 3:1 contrast ratio, but not much more.
Bug: "MUTE TAB"/"UNMUTE TAB" tooltip should update after clicking the button
Status: NEW
Priority: P3
Created: 2021-03-14 10:12:50+00:00
Resolved: 2021-04-21 13:34:40+00:00

* Hover mute button
* See the "MUTE TAB" tooltip
* click the button

AR:
"MUTE TAB" still shows until you mouse out and mouse back in

ER:
"MUTE" should change to "UNMUTE"