av9ash/GitBugs huggingface dataset:
Bug: Defaulting to showing the bookmarks toolbar on new tabs is problematic because of sidebars
Status: NEW
Priority: P3
Created: 2020-10-29 11:04:23+00:00
Resolved: 2020-10-30 19:11:33+00:00

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

Steps to reproduce:

1. Have browser.toolbars.bookmarks.visibility set to its recent new default of “newtab”.
2. Have a sidebar open.
3. Open a new tab.


Actual results:

The bookmarks toolbar opens, and the sidebar shifts vertically. If you’re using the sidebar for important things like Tree Style Tab, this can be distressing, especially until bug 1673363, which makes this happen more often, is fixed.


Expected results:

One of three things, I think:

1. The default should not be newtab, so that the bookmarks toolbar will either always be open or won’t open at all. In short, keep things the way they always were, rather than changing things in a way that is going to annoy a fairly large number of users until and unless they figure out how to return it to how they had it before (and it’s *not* easy or obvious—the bookmarks toolbar context menu should have an option to change it, but that’s bug 1003364). This is my own strong preference.

2. Make the bookmarks toolbar sit beside any sidebar, rather than above. This introduces the same issue in the *other* direction, that users that always have the bookmarks toolbars visible will find *it* moved when they open a temporary sidebar. I have no idea which of sidebars and bookmarks toolbars users are more likely to have persistent and which temporary.

3. Iff the bookmarks toolbar is set to show on new tabs, make the bookmarks toolbar sit beside any sidebar rather than above. This solves the conflict from the previous suggestion, and I think it matches the mental model—“show bookmarks toolbar on new tabs” is roughly saying “add the bookmarks toolbar to the top of the new tab page”, making the bookmarks toolbar effectively kind of a part of the page.

Chromium doesn’t have this issue because it doesn’t have sidebars, so it’s only the new tab page being pushed down by showing the bookmarks toolbar, so it doesn’t matter as the two are always thus paired.
Bug: Bookmarks toolbar height shrinks when empty, and is shown on new tab even when empty
Status: RESOLVED
Priority: P3
Resolution: FIXED
Created: 2020-10-29 11:11:38+00:00
Resolved: 2024-06-13 18:11:52+00:00

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

Steps to reproduce:

1. Take an empty profile.
2. Have browser.toolbars.bookmarks.visibility set to its recent new default of “newtab”.
3. Go to a new tab.
4. Delete the “Get Involved” bookmark that’s in the Bookmarks Toolbar, so that the Bookmarks Toolbar folder is empty.


Actual results:

The bookmarks toolbar remains, but starts taking up less vertical space.


Expected results:

The bookmarks toolbar should either retain its original height, or disappear.

I’m inclined to think that disappearing is better, at least in the case of newtab. If it’s always, I dunno. (As I’ve alluded to in bug 1674090, I feel that newtab makes this toolbar less a *toolbar* and more a part of about:newtab.)
Bug: Firefox ESR 78.4 urlbar in Linux selects entire URL but Fails to fill Select-Buffer or copy
Status: RESOLVED
Priority: --
Resolution: DUPLICATE
Created: 2020-10-29 12:39:56+00:00
Resolved: 2021-09-29 01:23:16+00:00

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

Steps to reproduce:

Update from Firefox 68.12 ESR to 78.4 ESR on Linux. Attempting to select URL in urlbar. Entire url selected on focus - nothing placed in Select-Buffer (except trivial text like "auto select" or "arch" ?


Actual results:

On clicking on url the Entire URL is automatically selected but NOTHING is placed in the Select-Buffer ready to be middle-mouse pasted anywhere else. I have used Firefox on Linux since the browser wars of the 90's and the entire URL should not be selected on-click on Linux to preserve the existing Select-Buffer. That is why Linux required a double-click to select to URL to ensure the user really wanted to replace the content of his current Select-Buffer.


Expected results:

Clicking on the url should NOT select the entire URL until a double-click as it has been since Firefox 2.X on Linux. When the whole URL is selected either by double-click or otherwise, the complete url should be copied to the Select-Buffer ready to be middle-mouse pasted wherever needed. This does not happen (worked fine on 68 - broken on 78 after update last night)

Further, I cannot find anywhere in about:config to restore the normal Linux urlbar behavior.
Bug: Don't show the bookmarks toolbar on the New Tab page if the toolbar will appear empty, including managed-bookmarks
Status: RESOLVED
Priority: P3
Resolution: FIXED
Created: 2020-10-29 16:33:52+00:00
Resolved: 2020-11-07 13:15:08+00:00

Bug 1673402 covered the use case that most users will encounter, but left out the case of managed-bookmarks in the toolbar.
Bug: Managed Bookmarks Placement sometimes ends up on right
Status: RESOLVED
Priority: P1
Resolution: FIXED
Created: 2020-10-29 18:02:18+00:00
Resolved: 2020-11-23 13:41:40+00:00

Some folks are doing some early testing of the ManagedBookmarks policy and seeing that the button ends up on the right sometimes (we have not officially released).

I believe this is result of the old static ManagedBookmarks code. For Firefox 83, we made things completely dynamic.

In order to make sure we are good for Firefox 83, I should be removing the old button from UI placement to make sure that we only use the dynamic button.

This is not an issue for ESR because it never had a release with the old code.
Bug: Don't show the bookmarks toolbar when New Tab page is disabled
Status: VERIFIED
Priority: P1
Resolution: FIXED
Created: 2020-10-29 18:43:34+00:00
Resolved: 2021-09-21 18:51:10+00:00

Currently when a user disables the New Tab page via about:preferences when setting New Tab to "Blank page", we will show the Bookmarks Toolbar on top-level about:blank pages.

This might not be what users actually want if they want a blank page for new tabs, and it opens us up to a number of bugs that occur since about:blank is used for many other cases than just a blank new tab page.
Bug: Intermittent browser/base/content/test/tabcrashed/browser_withoutDump.js | application crashed [None]
Status: RESOLVED
Priority: P5
Resolution: INCOMPLETE
Created: 2020-10-29 19:34:42+00:00
Resolved: 2023-06-28 12:02:42+00:00

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

---
```
[task 2020-10-29T17:44:00.949Z] 17:44:00     INFO - TEST-START | browser/base/content/test/tabcrashed/browser_withoutDump.js
[task 2020-10-29T17:44:01.335Z] 17:44:01     INFO - GECKO(1596) | Et tu, Brute?
[task 2020-10-29T17:44:01.534Z] 17:44:01     INFO - GECKO(1596) | [GFX1-]: Receive IPC close with reason=AbnormalShutdown
[task 2020-10-29T17:44:01.534Z] 17:44:01     INFO - GECKO(1596) | Exiting due to channel error.
[task 2020-10-29T17:44:01.534Z] 17:44:01     INFO - GECKO(1596) | Exiting due to channel error.
[task 2020-10-29T17:44:01.534Z] 17:44:01     INFO - GECKO(1596) | Exiting due to channel error.
[task 2020-10-29T17:44:01.534Z] 17:44:01     INFO - GECKO(1596) | Exiting due to channel error.
[task 2020-10-29T17:44:01.535Z] 17:44:01     INFO - GECKO(1596) | Exiting due to channel error.
[task 2020-10-29T17:44:06.481Z] 17:44:06     INFO - GECKO(1596) | ** Unknown exception behavior: -2147483647
[task 2020-10-29T17:44:06.581Z] 17:44:06     INFO - TEST-INFO | Main app process: exit 1
[task 2020-10-29T17:44:06.581Z] 17:44:06     INFO - Buffered messages logged at 17:44:00
[task 2020-10-29T17:44:06.581Z] 17:44:06     INFO - Entering test bound setup
[task 2020-10-29T17:44:06.581Z] 17:44:06     INFO - Leaving test bound setup
[task 2020-10-29T17:44:06.582Z] 17:44:06     INFO - Entering test bound test_without_dump
[task 2020-10-29T17:44:06.582Z] 17:44:06     INFO - Buffered messages logged at 17:44:01
[task 2020-10-29T17:44:06.582Z] 17:44:06     INFO - Console message: [JavaScript Error: "The character encoding of the HTML document was not declared. The document will render with garbled text in some browser configurations if the document contains characters from outside the US-ASCII range. The character encoding of the page must be declared in the document or in the transfer protocol." {file: "data:text/html,<html><body>A%20regular,%20everyday,%20normal%20page." line: 0}]
[task 2020-10-29T17:44:06.582Z] 17:44:06     INFO - Buffered messages finished
[task 2020-10-29T17:44:06.582Z] 17:44:06    ERROR - TEST-UNEXPECTED-FAIL | browser/base/content/test/tabcrashed/browser_withoutDump.js | application terminated with exit code 1
[task 2020-10-29T17:44:06.582Z] 17:44:06     INFO - runtests.py | Application ran for: 0:00:23.158795```
Bug: urlbar.searchmode.typed increments even if the search was not made
Status: RESOLVED
Priority: --
Resolution: INVALID
Created: 2020-10-29 20:22:31+00:00
Resolved: 2020-10-30 14:11:48+00:00

**[Sugested Severity:]**
S3

**[Description:]**
When you type in an alias in the urlbar, urlbar.searchmode.typed counts it even if the search is not done.

**[Steps:]**
1. Launch Firefox and open a new tab
2. Type an engine alias in the Urlbar. (eg: @amazon) and **don't** perform a search
3. Open about:telemetry
4. Left bottom corner, open Raw JSON and then left top corner, under refresh button, press Raw Data
5. Using the find function, look for urlbar.searchmode.typed

**[Actual Result:]**
Something similar to the following entry should be present, where the number represents the total of searches from the search field in about:newtab:
"urlbar.searchmode.typed": {
"Amazon": 1
},

**[Expected Result:]**
The typing of the alias shouldn't have been taken into account since the search was not done.
Bug: DOS of browser across restarts or a DOS requiring reboot of user’s computer when import passwords from another browser
Status: RESOLVED
Priority: P3
Resolution: INCOMPLETE
Created: 2020-10-29 21:22:43+00:00
Resolved: 2024-05-30 17:20:36+00:00

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

Steps to reproduce:

I found the password field for saved login not have limitation length  ,and when add long length password that lead to DOS of browser and maybe lead to restart of user computer .

1-Add text in below file as password for login account on chrome browser  .
>https://drive.google.com/file/d/1tLKaR6a0LvEaK3SHeY5dIQDHPQjFAtAf/view?usp=sharing

2-In firefox browser ,go to import data and setting 

3-Import data from chrome browser and then in firefox  go to saved login account in step #1

4-As you can see ,the browser is crash and there is memory loss .
Bug: Don't hide pref browser.pagethumbnails.capturing_disabled
Status: UNCONFIRMED
Priority: P4
Created: 2020-10-29 21:57:58+00:00
Resolved: 2021-04-26 16:04:59+00:00

The pref `browser.pagethumbnails.capturing_disabled` should be unhidden because there are reasons for not wanting thumbnails generated that go beyond test purposes.

A web search for this preference will show many discussions by end users wishing to disable thumbnails on their New Tab page.

On my New Tab page, I only want the automatically detected high resolution favicon images or Custom Image Urls that I specify. Never captured thumbnails.

To accomplish this goal, I discovered the `browser.pagethumbnails.capturing_disabled` which I set to **True**. 

However, now all my Custom Image Urls that I specified stopped working. This is bug 1551132.  But that bug won't be fixed because pref `browser.pagethumbnails.capturing_disabled` is hidden and, therefore, thought to be only for testing purposes.
Bug: No option to remember download preferences for files sent with application/octet-stream
Status: NEW
Priority: P3
Created: 2020-10-29 22:58:59+00:00
Resolved: 2023-07-31 19:58:56+00:00

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

Steps to reproduce:

Download a zoom.us meeting.

It triggers downloads of 4 files (sometimes 3) which includes `.txt`, `.vtt`, `.mp4`, and `.m4a`



Actual results:

`.txt`, `.vtt`, `.mp4`, and `.m4a` prompts or "Remember[ed] my selection" regarding Download's Open/Save preferences for each file extension.


Expected results:

`.txt`, `.mp4`, and `.m4a` prompts or "Remember[ed] my selection" regarding Download's Open/Save preferences for each file extension.

`.vtt` does not allow you to remember download preferrences.
Bug: Remove default topsites search shortcuts that match the current default engine, even if specified in the topsites collection
Status: RESOLVED
Priority: P3
Resolution: WONTFIX
Created: 2020-10-29 23:20:03+00:00
Resolved: 2021-01-27 13:22:12+00:00

Follow-up from bug 1663630, which handles the default topsites which are not search shortcuts.
This bug should cover the remaining case in which the topsite is a search shortcut.(see https://bugzilla.mozilla.org/show_bug.cgi?id=1663630#c4)

For steps check the steps from https://bugzilla.mozilla.org/show_bug.cgi?id=1663630#c0

Suggested severity S4, IMO, this is more on the polish side.
Bug: Change background fill colour of Custom Images for Top Sites with transparency (Dark Theme)
Status: NEW
Priority: --
Created: 2020-10-29 23:25:27+00:00
Resolved: 2022-06-26 21:48:49+00:00

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

Steps to reproduce:

I added a Top Site to my New Tab page with a Custom Image URL pointing to a image that has transparency:

https://upload.wikimedia.org/wikipedia/commons/thumb/1/12/Google_Photos_icon_%282020%29.svg/240px-Google_Photos_icon_%282020%29.svg.png



Actual results:

The transparency was filled with a white colour, even though I was using the Dark theme. 


Expected results:

The transparency should be filled with a dark colour, as was fixed for favicon images for Top Sites in bug 1454730.
Bug: Intermittent TV browser/base/content/test/protectionsUI/browser_protectionsUI_milestones.js | Uncaught exception - undefined - timed out after 50 tries.
Status: RESOLVED
Priority: P5
Resolution: INCOMPLETE
Created: 2020-10-30 00:09:26+00:00
Resolved: 2020-12-01 17:05:02+00:00

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

---
```
[task 2020-10-29T23:57:42.874Z] 23:57:42     INFO - TEST-START | browser/base/content/test/protectionsUI/browser_protectionsUI_milestones.js
[task 2020-10-29T23:57:48.382Z] 23:57:48     INFO - TEST-INFO | started process screenshot
[task 2020-10-29T23:57:48.438Z] 23:57:48     INFO - TEST-INFO | screenshot: exit 0
[task 2020-10-29T23:57:48.439Z] 23:57:48     INFO - Buffered messages logged at 23:57:42
[task 2020-10-29T23:57:48.439Z] 23:57:48     INFO - Entering test bound setup
[task 2020-10-29T23:57:48.439Z] 23:57:48     INFO - Leaving test bound setup
[task 2020-10-29T23:57:48.439Z] 23:57:48     INFO - Entering test bound doTest
[task 2020-10-29T23:57:48.439Z] 23:57:48     INFO - Buffered messages finished
[task 2020-10-29T23:57:48.439Z] 23:57:48     INFO - TEST-UNEXPECTED-FAIL | browser/base/content/test/protectionsUI/browser_protectionsUI_milestones.js | Uncaught exception - undefined - timed out after 50 tries.
[task 2020-10-29T23:57:48.440Z] 23:57:48     INFO - Leaving test bound doTest
[task 2020-10-29T23:57:48.440Z] 23:57:48     INFO - GECKO(4580) | MEMORY STAT | vsize 779MB | vsizeMaxContiguous 553MB | residentFast 209MB | heapAllocated 82MB
[task 2020-10-29T23:57:48.440Z] 23:57:48     INFO - TEST-OK | browser/base/content/test/protectionsUI/browser_protectionsUI_milestones.js | took 5529ms
[task 2020-10-29T23:57:48.440Z] 23:57:48     INFO - Not taking screenshot here: see the one that was previously logged
[task 2020-10-29T23:57:48.440Z] 23:57:48     INFO - TEST-UNEXPECTED-FAIL | browser/base/content/test/protectionsUI/browser_protectionsUI_milestones.js | Found an unexpected tab at the end of test run: https://example.com/ - 
[task 2020-10-29T23:57:48.440Z] 23:57:48     INFO - checking window state
[task 2020-10-29T23:57:48.447Z] 23:57:48     INFO - GECKO(4580) | Completed ShutdownLeaks collections in process 5204```
Bug: --headless --screenshot is broken, consistently hangs: Use Web Console :screenshot or Firefox Screenshots source code at --headless
Status: RESOLVED
Priority: --
Resolution: DUPLICATE
Created: 2020-10-30 00:33:45+00:00
Resolved: 2023-03-09 13:52:09+00:00

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

Steps to reproduce:

`firefox --headless --screenshot URL` 




Actual results:

consistently hangs at Nightly on Linux. For example https://bugzilla.mozilla.org/show_bug.cgi?id=1589978.


Expected results:

Web Console `:screenshot` and Firefox Screenshots do not hangs, and produce images that capture the entire screen when `--fullpage` is set as parameter. 

Substitute Web Console `:screenshot` https://developer.mozilla.org/en-US/docs/Tools/Taking_screenshots code or Firefox Screenshots https://screenshots.firefox.com/ code for the current `--headless` code, if they are different, so that users of Nightly can take screenshots with `--headless` option.
Bug: Keyword searches intermittently don't work, end up doing a Google search
Status: RESOLVED
Priority: P2
Resolution: DUPLICATE
Created: 2020-10-30 01:48:31+00:00
Resolved: 2023-07-14 14:35:18+00:00

This is a recent regression; I've only seen this in today's Nightly.

Steps to reproduce:
 1. Have a Bugzilla bookmark with the search keyword "b".
 2. Copy a bug number to the clipboard, e.g. 1235467. Then, do the following in very quick succession:
 3. Open a new tab with Cmd+T.
 4. Press "b", space, Cmd+V, Enter.

Expected results:
The new tab should execute the keyword search, e.g. navigate to https://bugzilla.mozilla.org/show_bug.cgi?id=1235467.

Actual results:
Sometimes, the new tab initiates a Google search for the string "b 1234567" instead.

This has happened to me about five times today.
Bug: 94.91 - 140.43% about_newtab_with_snippets (linux64-shippable, macosx1014-64-shippable, windows10-64-shippable, windows7-32-shippable) regression on push 9dfa75f6ec73f10849e81c214271f8dd4a20ad45 (Sat October 24 2020)
Status: RESOLVED
Priority: P3
Resolution: FIXED
Created: 2020-10-30 06:27:23+00:00
Resolved: 2020-11-13 12:11:48+00:00

Perfherder has detected a talos performance regression from push [9dfa75f6ec73f10849e81c214271f8dd4a20ad45](https://hg.mozilla.org/integration/autoland/pushloghtml?changeset=9dfa75f6ec73f10849e81c214271f8dd4a20ad45). As author of one of the patches included in that push, we need your help to address this regression.

### Regressions:

| **Ratio** | **Suite** | **Test** | **Platform** | **Options** | **Absolute values (old vs new)**| 
|--|--|--|--|--|--| 
| 140% | about_newtab_with_snippets |  | windows10-64-shippable | e10s stylo | 29.11 -> 70.00 |
| 140% | about_newtab_with_snippets |  | windows7-32-shippable | e10s stylo | 28.08 -> 67.33 |
| 116% | about_newtab_with_snippets |  | linux64-shippable | e10s stylo | 30.72 -> 66.29 |
| 95% | about_newtab_with_snippets |  | macosx1014-64-shippable | e10s stylo | 36.37 -> 70.90 |

### Improvements:

| **Ratio** | **Suite** | **Test** | **Platform** | **Options** | **Absolute values (old vs new)**| 
|--|--|--|--|--|--| 
| 26% | startup_about_home_paint_realworld_webextensions | startup_about_home_paint_realworld_webextensions | windows7-32-shippable | e10s stylo | 718.17 -> 529.58 |
| 25% | startup_about_home_paint_realworld_webextensions | startup_about_home_paint_realworld_webextensions | windows10-64-shippable | e10s stylo | 712.42 -> 533.25 |
| 11% | startup_about_home_paint_realworld_webextensions | startup_about_home_paint_realworld_webextensions | linux64-shippable | e10s stylo | 685.08 -> 610.75 |
| 11% | startup_about_home_paint_realworld_webextensions | startup_about_home_paint_realworld_webextensions | linux64-shippable | e10s stylo | 685.17 -> 611.33 |


Details of the alert can be found in the [alert summary](https://treeherder.mozilla.org/perf.html#/alerts?id=27363), including links to graphs and comparisons for each of the affected tests. Please follow our [guide to handling regression bugs](https://wiki.mozilla.org/TestEngineering/Performance/Handling_regression_bugs) and **let us know your plans within 3 business days, or the offending patch(es) will be backed out** in accordance with our [regression policy](https://www.mozilla.org/en-US/about/governance/policies/regressions/).

For more information on performance sheriffing please see our [FAQ](https://wiki.mozilla.org/TestEngineering/Performance/FAQ).
Bug: browser.urlbar.maxHistoricalSearchSuggestions does not work anymore
Status: RESOLVED
Priority: --
Resolution: DUPLICATE
Created: 2020-10-30 11:15:04+00:00
Resolved: 2020-11-03 14:15:34+00:00

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

Steps to reproduce:

Go to about:config.
Set browser.urlbar.maxHistoricalSearchSuggestions to 0.
Open a new tab.
Start typing in the url bar.


Actual results:

It shows historical search suggestions.


Expected results:

It doesn't show historical search suggestions.
Bug: External protocol permission dialog labels for file URIs are misleading
Status: RESOLVED
Priority: --
Resolution: FIXED
Created: 2020-10-30 11:35:34+00:00
Resolved: 2020-11-04 21:48:21+00:00

When we show the external protocol permission dialog for a file URI, we label the site as "file://". This is confusing to the user and doesn't make it clear that the permission is only stored for this specific file.

Perhaps something like "Always allow this local file to open ..." would be better.

We do something similar for the geolocation permission prompt:
https://searchfox.org/mozilla-central/rev/d866b96d74ec2a63f09ee418f048d23f4fd379a2/browser/locales/en-US/chrome/browser/browser.properties#620