av9ash/GitBugs huggingface dataset:
Bug: Empty tab left open after opening external app using custom protocol handler
Status: NEW
Priority: P3
Created: 2021-04-13 10:54:11+00:00
Resolved: 2021-09-22 02:37:20+00:00

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

Steps to reproduce:

Steps for running the attached test case - Python 3 based http.server

1. Register custom protocol scheme foo:// on the operating system, eg:

-- begin ff_bug_foo_handler.reg --
Windows Registry Editor Version 5.00

[HKEY_CLASSES_ROOT\foo]
@="URL:foo Protocol"
"URL Protocol"=""

[HKEY_CLASSES_ROOT\foo\Shell]

[HKEY_CLASSES_ROOT\foo\Shell\Open]

[HKEY_CLASSES_ROOT\foo\Shell\Open\Command]
@="\"C:\\Windows\\System32\\notepad.exe\""
-- end ff_bug_foo_handler.reg --

2. Start the HTTP server (python http_server.py)
3. Open index.html
4. Click on the hyperlink to page2.html in new tab using Javascript (window.open())
5. In the new tab, GET page2.html results in a status 302 response with new Location being /page3.html
6. In the new tab, GET page3.html results in a status 302 response with new Location being a URI having a custom protocol scheme foo://
7. The external application is opened on the client as expected
8. The new tab is left open but it does not have any HTML content and serves no further purpose to the user


Actual results:

The external application is opened on the client as expected. Firefox leaves the new tab which has no HTML content open.


Expected results:

Firefox should automatically close the extra tab that it opened because all URLs that processed within the new tab were redirects driven by the HTTP header Location.

Browser comparison
------------------
* New tab left open
   * Firefox ESR 78.9.0
   * Firefox 87.0
* New tab automatically closed by the browser  
   * Google Chrome 89.0.4389.114
   * Edge (Chromium) 89.0.774.76
Bug: [Windows 10] Addon context menu checkbox items show icons instead of checkboxes, are misaligned
Status: VERIFIED
Priority: P2
Resolution: FIXED
Created: 2021-04-13 11:08:34+00:00
Resolved: 2023-01-14 15:47:53+00:00

See attached screenshot.

OS: Windows 10, arm64.
Display: 1920x1080 @ 150% scaling.
Bug: [Proton] [Windows] Keyboard access key for `Open a New Tab` is in conflict with the same key attributed to a disabled label
Status: VERIFIED
Priority: --
Resolution: FIXED
Created: 2021-04-13 12:24:56+00:00
Resolved: 2021-04-18 00:12:45+00:00

**Affected versions**
* Latest Nightly 89.0a1

**Affected platforms**
* Windows 10
* Windows 7 

**Unaffected platforms**
* Ubuntu 18.04

**Steps to reproduce**
1. Start Firefox with a new profile
2. Right click the opened tab or in the tab bar
3. Hit 'O' key from keyboard to open a new tab
- `Reopen closed tab` option is disabled in context menu.

**Expected result**
* A new Tab is opened

**Actual result**
* Focus selector also jumps to `Reopen closed tab` (even if disabled) preventing opening a new tab.

**Regression range**
* This is not a regression since it was introduced when this was first implemented in bug 1692840.

**Additional notes**
* On Ubuntu this issue does not happen, even if Reopen closed tab is visible and disabled a new tab will open when hitting 'O' key.

**Suggested severity**
* This is of S3 severity in my Opinion since it prevents users (in certain conditions) to use the newly added option.
Bug: Unable to open local files
Status: RESOLVED
Priority: --
Resolution: WORKSFORME
Created: 2021-04-13 12:34:29+00:00
Resolved: 2021-04-20 07:12:30+00:00

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

Steps to reproduce:

Trying to open a PDF saved in My Documents folder with Firefox


Actual results:

Firefox tries to load, but closes the document immediately


Expected results:

Firefox should be able to open local supported file
Bug: 17.4 - 8.01% tart / tart + 3 more (Linux, OSX, Windows) regression on Sat April 10 2021
Status: RESOLVED
Priority: P3
Resolution: WORKSFORME
Created: 2021-04-13 12:51:11+00:00
Resolved: 2021-05-05 09:54:06+00:00

Perfherder has detected a talos performance regression from push [135c5397086dac5623bc45d92bd6e7709806d89d](https://hg.mozilla.org/integration/autoland/pushloghtml?changeset=135c5397086dac5623bc45d92bd6e7709806d89d). 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)**| 
|--|--|--|--|--|--| 
| 17% | tart |  | windows10-64-shippable | e10s stylo | 2.24 -> 2.63 |
| 17% | tart |  | linux1804-64-shippable | e10s stylo | 2.74 -> 3.21 |
| 15% | tart |  | linux1804-64-shippable | e10s stylo | 2.81 -> 3.23 |
| 14% | tart |  | macosx1015-64-shippable | e10s stylo | 2.08 -> 2.38 |
| 8% | tart |  | windows10-64-shippable-qr | e10s stylo webrender | 2.58 -> 2.78 |

### Improvements:

| **Ratio** | **Suite** | **Test** | **Platform** | **Options** | **Absolute values (old vs new)**| 
|--|--|--|--|--|--| 
| 9% | tresize |  | macosx1015-64-shippable | e10s stylo | 9.71 -> 8.87 |
| 7% | tp5o_scroll |  | macosx1015-64-shippable | e10s stylo | 1.52 -> 1.41 |
| 7% | tresize |  | macosx1015-64-shippable-qr | e10s stylo webrender-sw | 7.82 -> 7.28 |


Details of the alert can be found in the [alert summary](https://treeherder.mozilla.org/perfherder/alerts?id=29677), 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: App Menu/Library dropdown items don't use theme focus ring color
Status: RESOLVED
Priority: P2
Resolution: FIXED
Created: 2021-04-13 14:21:46+00:00
Resolved: 2021-05-13 18:50:28+00:00

## steps to reproduce/what did you do?

* First, tab through the chrome to observe the dark/neon blue focus ring color (depending on the theme you have chosen)
* Now tab into one of the dropdown menus like Application menu or Library

## expected behavior/ what did you think will happen?

* Focus ring color is blue like the rest of the chrome

## actual behavior/ what actually happened

* Focus ring color uses my system accent color (in my case, orange)

## additional notes

For me, the issue is not so much that it's one color or the other, it's that it's inconsistent. Especially in dark theme where the orange sticks out.
Bug: --toolbarbutton-icon-fill-attention should be Primary Blue
Status: RESOLVED
Priority: --
Resolution: FIXED
Created: 2021-04-13 14:57:31+00:00
Resolved: 2021-04-16 15:18:12+00:00

`var(--toolbarbutton-icon-fill-attention)` is used for the filled bookmarks star, the download success indicator, and in the active reader mode icon. I can't find a part of the Figma spec that shows any of these buttons in their blue state, but it makes sense that they be Primary Blue (#0061E0, #00DDFF in dark mode).
Bug: awesomebar items with bookmark tag has unreadable tag when selected
Status: RESOLVED
Priority: --
Resolution: DUPLICATE
Created: 2021-04-13 15:01:06+00:00
Resolved: 2021-04-26 09:59:51+00:00

## steps to reproduce/what did you do?
* Create a bookmark and give it a tag
* Enter awesomebar text that displays that bookmarked item
* Arrow down to focus that bookmark tagged item

## expected behavior/ what did you think will happen?
* Should be able to read tag when item selected

## actual behavior/ what actually happened?
* Bookmark tag is a black box that's unreadable
Bug: Skeleton UI should be disabled if using non-default UI density
Status: RESOLVED
Priority: --
Resolution: FIXED
Created: 2021-04-13 16:41:42+00:00
Resolved: 2021-04-16 03:12:25+00:00

This is a temporary solution. I think we should adjust the heights of all of the relevant pieces of the skeleton UI based on this pref value. However, given that I don't know what has and has not been finalized for Proton and compact mode, I think the safest bet here is to just turn the skeleton UI off entirely if we have a non-default density.
Bug: [widget.macos.respect-system-appearance] In System Dark Mode some elements in History Window are not readable
Status: RESOLVED
Priority: --
Resolution: DUPLICATE
Created: 2021-04-13 17:17:54+00:00
Resolved: 2021-04-13 17:25:48+00:00

MacOS 11.2.3
Nightly 89.0a1 (2021-04-13) (64-Bit)

1.) Enable widget.macos.respect-system-appearance
2.) Open History Window or Site Information Window

Actual: Some elements are not readable and table lines are too bright

Expected: Readable elements and darker lines

A screenshot is attached.
Bug: The notificationbar "stack" lazy getter is called when closing a tab
Status: RESOLVED
Priority: --
Resolution: FIXED
Created: 2021-04-13 17:29:16+00:00
Resolved: 2021-04-20 14:41:01+00:00

I noticed in the profile of closing many tabs from bug 1379174 comment 6 that 2.2% of the time spent in `removeTabs` is spent in `notificationbox.js: get stack` https://share.firefox.dev/3g8aLPC

The code at https://searchfox.org/mozilla-central/rev/3de2db87f3c9001ae478318d47a2ca3427574382/browser/base/content/tabbrowser.js#3811-3812 tries to avoid triggering the notification box lazy getter, but then doesn't check if the stack has already been initialized before accessing it.

Unfortunately, the `getNotificationBox` method is called at https://searchfox.org/mozilla-central/rev/3de2db87f3c9001ae478318d47a2ca3427574382/browser/base/content/browser.js#5859, so any tab that has already had a location change event will have a notification box.
Bug: Save file to function does not work to save files to a network path
Status: RESOLVED
Priority: --
Resolution: DUPLICATE
Created: 2021-04-13 19:11:00+00:00
Resolved: 2021-10-04 13:41:47+00:00

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

Steps to reproduce:

1. Open Tools/Options menu in Firefox
2. Find Files and Applications section in General setting
3. In Download setting set 'Save files to' location to point to a network drive

For example \\computername\directory

This feature worked fine on version 86 and before.


Actual results:

Firefox saves files to '\Users\%username%\Downloads' directory.


Expected results:

Firefox should saves files to '\\computername\directory'
Bug: Intermittent TV browser/base/content/test/contextMenu/browser_contextmenu_linkopen.js | This test exceeded the timeout threshold. It should be rewritten or split up. If that's not possible, use requestLongerTimeout(N), but only as a last resort. -
Status: RESOLVED
Priority: P5
Resolution: INCOMPLETE
Created: 2021-04-13 20:41:58+00:00
Resolved: 2021-05-11 17:03:44+00:00

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

---
```
[task 2021-04-13T16:34:07.660Z] 16:34:07     INFO - TEST-START | browser/base/content/test/contextMenu/browser_contextmenu_linkopen.js
[task 2021-04-13T16:34:55.739Z] 16:34:55     INFO - TEST-INFO | started process screencapture
[task 2021-04-13T16:34:55.822Z] 16:34:55     INFO - TEST-INFO | screencapture: exit 0
[task 2021-04-13T16:34:55.822Z] 16:34:55     INFO - <snipped 7 output lines - if you need more context, please use SimpleTest.requestCompleteLog() in your test>
[task 2021-04-13T16:34:55.822Z] 16:34:55     INFO - Buffered messages logged at 16:34:09
[task 2021-04-13T16:34:55.823Z] 16:34:55     INFO - TEST-PASS | browser/base/content/test/contextMenu/browser_contextmenu_linkopen.js | DOM context menu item tab shouldn't be disabled - 
[task 2021-04-13T16:34:55.823Z] 16:34:55     INFO - Waiting for the link to open
<...>
[task 2021-04-13T16:34:55.861Z] 16:34:55     INFO - TEST-PASS | browser/base/content/test/contextMenu/browser_contextmenu_linkopen.js | Should have opened a private window. - 
[task 2021-04-13T16:34:55.861Z] 16:34:55     INFO - Waiting for the opened window/tab to close
[task 2021-04-13T16:34:55.861Z] 16:34:55     INFO - Buffered messages logged at 16:34:55
[task 2021-04-13T16:34:55.861Z] 16:34:55     INFO - Leaving test bound test_select_text_link
[task 2021-04-13T16:34:55.861Z] 16:34:55     INFO - Buffered messages finished
[task 2021-04-13T16:34:55.861Z] 16:34:55     INFO - TEST-UNEXPECTED-FAIL | browser/base/content/test/contextMenu/browser_contextmenu_linkopen.js | This test exceeded the timeout threshold. It should be rewritten or split up. If that's not possible, use requestLongerTimeout(N), but only as a last resort. - 
[task 2021-04-13T16:34:55.862Z] 16:34:55     INFO - GECKO(2060) | MEMORY STAT | vsize 7891MB | residentFast 458MB | heapAllocated 137MB
[task 2021-04-13T16:34:55.862Z] 16:34:55     INFO - TEST-OK | browser/base/content/test/contextMenu/browser_contextmenu_linkopen.js | took 48089ms
[task 2021-04-13T16:34:55.862Z] 16:34:55     INFO - checking window state
[task 2021-04-13T16:34:55.993Z] 16:34:55     INFO - TEST-START | browser/base/content/test/contextMenu/browser_contextmenu_linkopen.js```
Bug: Icon for custom search engine too dark on dark theme
Status: VERIFIED
Priority: P3
Resolution: FIXED
Created: 2021-04-14 03:20:44+00:00
Resolved: 2021-06-06 08:52:51+00:00

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

Steps to reproduce:

1. Enable dark theme on nightly with proton enabled
2. Set a custom search engine as default (i.e. qwant)



Actual results:

The icon in the search bar on the new tab/home page is too dark, making it difficult to see in contrast to the dark background


Expected results:

The icon should be light, in order to contrast better with the background. This is achieved in the url bar, but currently not in the new tab/homepage search bar.
Bug: Write about:newtab and the tab icon does not change.
Status: NEW
Priority: --
Created: 2021-04-14 06:10:05+00:00
Resolved: 2021-04-15 14:49:10+00:00

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

Steps to reproduce:

- Open any internet address.
- Write in the address bar:
about:newtab



Actual results:

- The tab is cleans well but remains with the same icon as the last tab. 


Expected results:

- The icon tab should be removed or put the Firefox new tab icon.
Bug: Background in address bar moves around when it receives focus
Status: RESOLVED
Priority: P5
Resolution: FIXED
Created: 2021-04-14 07:23:36+00:00
Resolved: 2021-04-21 07:26:28+00:00

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

Steps to reproduce:

1. Start firefox via https://github.com/mozilla/web-ext
2. Focus address bar


Actual results:

The striped background in the address bar moves around when its focused. This happens because the background is anchored at the bottom and not at the top. See the attached video for a demonstration of the issue.


Expected results:

The background should not move around.
Bug: Syncing of add-ons fails when a profile is refreshed
Status: RESOLVED
Priority: --
Resolution: WORKSFORME
Created: 2021-04-14 08:03:59+00:00
Resolved: 2021-04-30 04:30:50+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 use a single profile and the same FF en-US version 86.0.1 everywhere. Refreshed my profile in Linux Mint and reinstalled my add-on selection while sync was active.  Then, opened Firefox in Windows 10. . . .


Actual results:

Windows Firefox is set up identically, but none of the add-ons worked. They were listed in about:addons, and their web page indicated as installed. I had to un-install, and re-install them, but then, the next cycle of sync disabled them again.


Expected results:

It should have synced smoothly and not disable the addons due to some incompatibility.
Bug: Proton UI: manage bookmarks using wrong colors for icon buttons and top row on macOS in dark mode
Status: RESOLVED
Priority: --
Resolution: DUPLICATE
Created: 2021-04-14 08:51:06+00:00
Resolved: 2021-04-14 09:05:50+00:00

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

Steps to reproduce:

Open Firefox > Bookmarks > Manage Bookmarks from menubar
macOS 11.2.3
dark mode
Firefox 89.0a1 (2021-04-13) (64-Bit)


Actual results:

Manage Bookmark dialog opens
Notice the wrong color used for the buttons at the top as well as the top row


Expected results:

use correct dark mode color scheme
Bug: Hover on tab mute button shows white square when PiP is active
Status: RESOLVED
Priority: --
Resolution: WORKSFORME
Created: 2021-04-14 09:56:00+00:00
Resolved: 2021-04-30 16:22:55+00:00

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

Steps to reproduce:

1) Start any Youtube video directly on Youtube
2) Open video in Picture-in-Picture mode
3) While Picture-in-Picture is still open, switch tab to Youtube startpage
4) Hover over tab where the mute button was before

See: https://lpnsk.com/stuff/ff_dev_88-0b9_hoverovermutebutton.mov (40MB, file seems to be too large for the upload here)


Actual results:

Picture-in-Picture frame doesn't hide although there is no video to play. When hovering over the area where the mute button was before a white square appears.


Expected results:

There should not be a mute button as there is no video/sound playing. Therefor it should not appear a white square while hovering over it.
Furthermore it seems strange that the Picture-in-Picture window stays open even though there is no video to play in on the startpage.
Bug: Copying url from status bar (with protection shield, add to favorites, etc) copied with http://https://site.com
Status: RESOLVED
Priority: --
Resolution: DUPLICATE
Created: 2021-04-14 09:59:20+00:00
Resolved: 2021-04-15 19:31:40+00:00

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

Steps to reproduce:

1. Open Firefox 
2. Navigate to https:// supported site
3. Copy url from url address bar and paste to 



Actual results:

Pasted with http:// prefix
And look like - http://https://site.org


Expected results:

Paste only original address - https://site.org
Bug: after the update firefox closed all my tabs and windows
Status: RESOLVED
Priority: --
Resolution: WORKSFORME
Created: 2021-04-14 10:18:42+00:00
Resolved: 2021-04-20 18:10:42+00:00

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

Steps to reproduce:

I restarted the computer with firefox open (multi windows and many tabs)


Actual results:

All tabs and windows have been closed and Firefox started up in one window with "what's new"


Expected results:

firefox starts up with all tabs from the previous session !
Bug: Overflow button is slightly moved after Pin to overflow animation is completed
Status: VERIFIED
Priority: P2
Resolution: FIXED
Created: 2021-04-14 11:45:45+00:00
Resolved: 2023-05-04 12:06:21+00:00

*Affected versions*
* 89.0a1(20210412213434)


*Affected platforms*
* macOS 11.2.3
* Windows 10x64
* Ubuntu 20.04



*Steps to reproduce*
1. Open Firefox and select the Pin to Overflow context menu option on a random item from the toolbar.
2. Observe the Overflow animation.


*Expected result*
* Animation icon have the same size as the button itself.

*Actual result*
* When the animation is completed the Overflow button has a slight movement. I think this is because the animation has bolded lines like the new implemented chevron icon.

*Regression range*
* Last good revision: ca8aff8285cadc7fb74b0f05676ebcd98b4f77d3
First bad revision: f160141317e9c764ac698e7dab08c36820e7e922
Pushlog:
https://hg.mozilla.org/integration/autoland/pushloghtml?fromchange=ca8aff8285cadc7fb74b0f05676ebcd98b4f77d3&tochange=f160141317e9c764ac698e7dab08c36820e7e922


*Notes*
* Attached a screen recording.
Bug: When you have more tabs than your available width, it's difficult to understand at first glance if you're at the start / middle / end of the tabs
Status: RESOLVED
Priority: --
Resolution: DUPLICATE
Created: 2021-04-14 12:24:58+00:00
Resolved: 2021-04-15 18:52:50+00:00

This started to happen with the proton changes. My analysis is that we now snap the tab edges with the edge of the tab bar, on both sides. Previously we were seeing a bit of the next or previous tabs, which was a good affordance to know that there was more.

I'll add a few screenshots.
Bug: UX review for new pdf signature infobar
Status: RESOLVED
Priority: --
Resolution: FIXED
Created: 2021-04-14 12:29:30+00:00
Resolved: 2021-05-05 11:46:44+00:00

Bug 854315 landed with ability to show pdf signatures that were previously hidden. 
PDF documents with signatures will now always display a new inforbar (can be tested on latest nightly with https://bug854315.bmoattachments.org/attachment.cgi?id=728861) that informs the users that the digital signature is not validated with a button allowing users to open with a different viewer - Edge in most cases for Windows users.

Here are some concerns I'd like UX help with:
 - Most users will follow OS defaults and Edge does not support digital signature validation either (and also does not inform users that they do not support it) - essentially we send users to another browser where they think a feature is supported that is not supported in Firefox, although it's not true
- In general I feel like most users won't understand what the infobar means. Competing browsers (Chrome and Edge) also don't support digital signature validation but don't warn users - I'd recommend not showing a notification here to avoid confusing users on something that is not critical to their security (users now see a signature in a PDF document but nothing in the UI signals that the piece of previously hidden text has any form of official warranty)
Bug: Items inside sidebar hard to see with Dark theme enabled in Firefox
Status: VERIFIED
Priority: --
Resolution: FIXED
Created: 2021-04-14 12:37:39+00:00
Resolved: 2021-04-23 13:01:28+00:00

**Affected versions**
* Latest Nightly 89.0a1

**Affected platforms**
* Windows 10
* Ubuntu 18.04
* macOS 11.3

**Steps to reproduce**
1. Launch Firefox
2. Change the theme of the Firefox to Dark
3. Toggle the Bookmark/History Sidebar

**Expected result**
* Sidebar respects the Dark theme, having the background dark but the text white so it can be visible.

**Actual result**
* Background is dark but also is the text of the bookmarks/history.

**Regression range**
* First bad: dc67a43df7384b22eb61822c0b1b020ad45989cb
* Last good: 5ca21d05036cd0768676001c29b2445c3d7be20a
* Pushlog: https://hg.mozilla.org/integration/autoland/pushloghtml?fromchange=5ca21d05036cd0768676001c29b2445c3d7be20a&tochange=dc67a43df7384b22eb61822c0b1b020ad45989cb
* Potential regressor: Bug 1704164 - Dark mode colors set too late in activity stream startup

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

**Suggested severity**
* I would say this should be of a high severity (S2) since this is very visible to users making the items inside sidebar very hard to see
Bug: Lack of contrast in tab strip/urlbar/toolbar makes some things hard to distinguish
Status: RESOLVED
Priority: P3
Resolution: DUPLICATE
Created: 2021-04-14 13:08:26+00:00
Resolved: 2023-06-02 15:21:26+00:00

See attached screenshot.
OS: Windows 10 on Lenovo C630. Default Windows theme (AFAIK).
The urlbar/searchbox background color is, if not identical, very close to the color of non-selected tabs. They don't have borders, and the toolbar they are in is only a slightly lighter shade of grey, making them hard to distinguish. Even the selected tab might be difficult to distinguish from the other tabs.
The alpenglow theme is much clearer.