av9ash/GitBugs huggingface dataset:
Bug: 'Manage Devices..." loads page whose main content is missing (no device list), link looks wrong
Status: RESOLVED
Priority: --
Resolution: DUPLICATE
Created: 2021-04-10 18:47:35+00:00
Resolved: 2021-04-11 00:31:50+00:00

Firefox 89.0a1 20210410091448, 88.0b9, 87.0 on Windows 8.1

The "Manage Devices..." menu items in the Sync panel and the the Synced Tabs panel opens a page which doesn't show the device list (main area is empty).

Link is: https://accounts.firefox.com/settings/clients?context=fx_desktop_v3&entrypoint=syncedtabs-menupanel&uid=<auid>&email=<youremailaddress>#

Link should be (?): https://accounts.firefox.com/settings?context=fx_desktop_v3&entrypoint=fxa_discoverability_native&uid=<auid>&email=<youremailaddress>#connected-services

Steps to reproduce (Nightly):
1. In the app menu, click on the button to sign in to Sync.
2. Sign in with a Firefox account.
3. Enable synchronization of tabs in Preferences > Synchronization.
4. Repeat 1-3 in a different Firefox profile.
5. In the toolbar, click on the Sync button.
6. Click on the command to send the tab to a device (have a tab with content opened).
7. Click on "Manage Devices" in the submenu.

Actual result: Page loads but no content to manage devices.
Expected result: content to manage devices

Similar issue if the toolbar button with the synced tabs gets added and used.
Bug: Disabling proton design not reverting back the old context menu
Status: RESOLVED
Priority: --
Resolution: INVALID
Created: 2021-04-10 19:05:28+00:00
Resolved: 2021-04-12 14:59:26+00:00

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

Steps to reproduce:

Set the browser.proton.enable to false


Actual results:

The context menu on web pages are the same as the new


Expected results:

To be the old context menu, with no round corners and the icons / text aligned to rows correctly
Bug: Windows 10 20H2 custom theme overrides Proton context menu
Status: RESOLVED
Priority: --
Resolution: INVALID
Created: 2021-04-10 20:35:06+00:00
Resolved: 2021-04-13 11:00:09+00:00

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

Steps to reproduce:

Patched and applied a custom theme [1] using SecureUxTheme [2]
Expected to see the new Proton context menu

[1] https://www.deviantart.com/kdr3w/art/Dark-845402016
[2] https://github.com/namazso/SecureUxTheme


Actual results:

It shows pre-Proton context menu


Expected results:

Shown Proton context menu
Bug: Proton context menu to large
Status: RESOLVED
Priority: P3
Resolution: WONTFIX
Created: 2021-04-10 20:45:33+00:00
Resolved: 2021-09-12 08:53:22+00:00

The proton context menu is way to long.
On my 1080P Notebook the proton context menu is 50% longer as the old one and now it takes nearly the full display height.
Bug: Intermittent browser/components/protocolhandler/test/browser/browser_registerProtocolHandler_notification.js | We expect this notification to have an icon. - Got "none", expected "url(\"chrome://global/skin/icons/info.svg\")"
Status: RESOLVED
Priority: P5
Resolution: FIXED
Created: 2021-04-10 21:15:37+00:00
Resolved: 2021-04-19 06:02:23+00:00

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

---
```
[task 2021-04-10T20:39:58.881Z] 20:39:58     INFO - TEST-PASS | browser/components/protocolhandler/test/browser/browser_registerProtocolHandler_notification.js | We expect this notification to have the type of 'info'. - 
[task 2021-04-10T20:39:58.881Z] 20:39:58     INFO - Buffered messages finished
[task 2021-04-10T20:39:58.881Z] 20:39:58     INFO - TEST-UNEXPECTED-FAIL | browser/components/protocolhandler/test/browser/browser_registerProtocolHandler_notification.js | We expect this notification to have an icon. - Got "none", expected "url(\"chrome://global/skin/icons/info.svg\")"
[task 2021-04-10T20:39:58.881Z] 20:39:58     INFO - Stack trace:
[task 2021-04-10T20:39:58.881Z] 20:39:58     INFO - chrome://mochikit/content/browser-test.js:test_is:1362
[task 2021-04-10T20:39:58.881Z] 20:39:58     INFO - chrome://mochitests/content/browser/browser/components/protocolhandler/test/browser/browser_registerProtocolHandler_notification.js:null:50
[task 2021-04-10T20:39:58.882Z] 20:39:58     INFO - TEST-PASS | browser/components/protocolhandler/test/browser/browser_registerProtocolHandler_notification.js | We expect see one button. - ```
Bug: Tab label's fadeout effect jumps to the left, when hovered
Status: RESOLVED
Priority: --
Resolution: DUPLICATE
Created: 2021-04-11 04:09:54+00:00
Resolved: 2021-04-11 04:35:54+00:00

STR:
1. Ensure you have Proton enabled (`browser.proton.enabled` = `true`, the default in Nightly)
2. Open a tab with a long title (long enough that some of it fades out & is clipped), e.g.:
```
data:text/html,<title>This is a long tab title so that it triggers the fadeout effect
```
3. While viewing that tab, hover its tab-title.

ACTUAL RESULTS:
The tab-title seems to change one thing (and only one thing) when hovered: the fadeout effect jumps leftwards a bit.  See attached screencast.

EXPECTED RESULTS:
Fadeout threshold shouldn't move.

(Under the hood, it looks like in fact the label itself gets skinnier, though you can't really tell since its right edge is fully transparent. So it ends up looking like the fadeout point is just jumping, which looks quite odd.)

I'm using latest Nightly on macOS.
Bug: It is difficult to identify between active and inactive window in windows10.
Status: RESOLVED
Priority: --
Resolution: DUPLICATE
Created: 2021-04-11 04:52:39+00:00
Resolved: 2021-04-13 16:10:55+00:00

It is difficult to identify between active and inactive windows in Nightly89.0a1 window10.

Steps to reproduce:
1. Open multiple browser window

Regression window:
https://hg.mozilla.org/integration/autoland/pushloghtml?fromchange=8aa1b80a8c6b66cccc2e37080fbf6197eee8d801&tochange=1716229005d8b97f305bd663b8bc8d3fec4a4f3a
Bug: After disabling ETP for a site, the striped background of the ETP toggle at the top of the protections panel has an odd padding on the left and right
Status: RESOLVED
Priority: P3
Resolution: DUPLICATE
Created: 2021-04-11 06:57:38+00:00
Resolved: 2021-04-14 16:17:59+00:00

STR:

1. Open any website in a tab
2. Click the shield icon in the URL bar
3. Click the toggle next to "Enhanced Tracking Protection is ON for this site" at the top
4. Wait for the page to reload, then click the shield icon again.

Expected result:
The striped background spans all the way across the width of the panel, or isn't there at all, or something.

Actual result:
Whitespace on the left and right, looks odd.

Screenshot attached!
Bug: It's less easy to distinguish the current tab since activation of proton
Status: REOPENED
Priority: P2
Created: 2021-04-11 07:05:47+00:00
Resolved: 2024-10-02 19:19:45+00:00

Hello,

I'm Using Debian GNU/Linux 10 with the GTK3 built-in HighContrast theme.

I'm a low-vision person and sensible to contrast issue.

Steps to reproduce:
0) I don't reproduce this under Windows because on Windows Firefox doesn't currently apply properly the HighContrast theme (I'll fill a bug about this later).
(I don't have a mac to check)
1) Set the HighContrast theme (on GNOME, I assume you should use GNOME Tweak, on the Mate desktop you can use mate-appearance-properties, for other desktop environment I don't know)
2) Start Firefox Nightly

Result with Nightly with proton enabled:
The active tab has just a depth effect  on it. With many tabs opened, I no longer can determine which tab is the active one.

Result before proton enabled:
A colored line appears on the top of the current tab which makes it really easy to distinguish.

Mozregression gives me this:
https://hg.mozilla.org/integration/autoland/pushloghtml?fromchange=8aa1b80a8c6b66cccc2e37080fbf6197eee8d801&tochange=1716229005d8b97f305bd663b8bc8d3fec4a4f3a

Thanks in advance.
Bug: Confirmation hint should not set "open" attribute on toolbarbuttons
Status: NEW
Priority: P3
Created: 2021-04-11 08:15:58+00:00
Resolved: 2024-02-27 15:50:39+00:00

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

Steps to reproduce:

- Have the bookmarks or library button in the customizable nav bar.
- Press the bookmark page action button to save a bookmark.
- When the bookmark is saved, the confirmation hint [opens](https://searchfox.org/mozilla-central/source/browser/base/content/browser.js#9678), anchored to the bookmarks toolbar button.


Actual results:

- The bookmarks toolbar button gains an "open" attribute, so it's affected by the styles meant to highlight toolbar buttons when their interactive popups are open, by giving them a background color.


Expected results:

The openPopup method needs some kind of toggle for when the anchor is being set purely for visual reasons, vs. when the popup is anchored to a button because it's meant to have a functional, hierarchical relationship with that button.

In this case the popup in question isn't some kind of dropdown menu that you can trigger by clicking a button. It's more like a tooltip than a panel. It's not triggered by activating the bookmarks toolbar button so the bookmarks toolbar button shouldn't be highlighted when the confirmation hint is open. I imagine the `[open]` toolbar button styles are meant to convey the fact that the button is in an active state, so clicking it will now close the menu instead of open it. Like a light switch.

So having that style apply in this situation is visually confusing, since 1) the toolbar button is not necessarily in its "active" state when the confirmation hint appears, and 2) clicking the toolbar button while the confirmation hint is visible will open the bookmarks toolbar popup, not close it.

I think this should be fixed at a lower level, because the confirmation hint is a really nice bit of a design and I think its applications could be expanded. So if this was only fixed by changing the bookmarks-related buttons or methods I think it'd be a missed opportunity. If the confirmation hint is ever used in other situations, or if in the future a similar element is created which uses the openPopup method but isn't an ordinary popup panel, this problem might come back again. It seems like the method itself should just have an extra parameter you can pass to tell it that the anchor should not be given the `open` attribute.
Bug: synced tabs sidebar has label of button 'Sign in to Sync' cropped for German (longer string)
Status: NEW
Priority: P4
Created: 2021-04-11 18:28:29+00:00
Resolved: 2022-04-12 07:39:54+00:00

Firefox 89.0a1 20210410214333 on Windows 8.1

The "Sign in to sync" button in the Synced Tabs sidebar gets cropped for German because it's too long (see screenshot). The string got longer after the "Sync" brand got dropped (bug 1700638). It fits in the Synced Tabs panel.

`Synchronisationseinstellungen öffnen` is even longer.
Bug: [macOS] Light strip at bottom of "About Firefox" dialog (in dark mode)
Status: RESOLVED
Priority: P3
Resolution: FIXED
Created: 2021-04-11 18:39:35+00:00
Resolved: 2021-12-10 19:35:54+00:00

STR:
1. Open the "About Nightly" dialog. (in MacOS, click the Firefox Nightly menu, and then choose "About Nightly")
2. Drag that dialog over a dark background (to make its edges easier to see)

ACTUAL RESULTS:
The dialog itself is entirely dark, but the very bottom of the dialog has a 1px-tall strip of a light color (white or gray).

EXPECTED RESULTS:
No such strip of light color.

This is a regression, with range:
https://hg.mozilla.org/integration/autoland/pushloghtml?fromchange=a673fcbd7a067815aa8b8966e134283aae5a4e56&tochange=b1628ddad29124227e334e82e9fac863bc877e4d
--> regression from bug 1660848


I'm using a MacBook Pro (15-inch, 2019) with MacOS Big Sur, and latest Firefox Nightly.
(I have dark mode enabled in the OS settings, too, though I don't think that matters for this dialog/bug. I can reproduce in Light mode as well.)
Bug: Excessive tab height when displaying page titles including Unicode math symbols
Status: VERIFIED
Priority: P2
Resolution: FIXED
Created: 2021-04-11 23:11:43+00:00
Resolved: 2024-04-02 14:46:01+00:00

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

Steps to reproduce:

Opened a web page composed of the following HTML code (the title was originally found in a YouTube video):

    <html>
    <head>
    <title>𝗧𝗛𝗘 𝗜𝗡𝗖𝗜𝗗𝗘𝗡𝗧 - YouTube</title>
    </head>
    </html>

Note: I tested it on a clean profile, and it still happens.


Actual results:

The tab bar became much taller than required to show the title. (see attached screenshot)


Expected results:

The tab bar staying the same size, as no additional height is required to display the title.
Bug: about:logins applies a light theme when privacy.resistFingerprinting is set to true, even when the theme is dark
Status: RESOLVED
Priority: --
Resolution: DUPLICATE
Created: 2021-04-11 23:15:00+00:00
Resolved: 2021-04-12 18:14:40+00:00

about:logins applies a light theme when privacy.resistFingerprinting is set to true.

Since this is an in-content, internal Firefox page, shouldn't it follow the browser (dark) theme?
Bug: Proton: page zoom button inside URL bar has barely visible hover feedback when Dark theme is selected
Status: VERIFIED
Priority: P2
Resolution: FIXED
Created: 2021-04-12 02:22:53+00:00
Resolved: 2021-04-19 20:18:06+00:00

Go to Customize > Themes and select "Dark". Change page zoom, then hover cursor over the button that appears in the URL bar. Observe there is no hover feedback. Strangely though, when I select "Default" theme, there IS hover feedback, even though nothing appears to have changed (I have Windows 10 in dark mode).
Bug: Double-tap to zoom doesn't work on osx
Status: RESOLVED
Priority: --
Resolution: INVALID
Created: 2021-04-12 03:04:25+00:00
Resolved: 2021-04-27 23:42:03+00:00

Using Nightly 89.0a1 (2021-04-11) on OSX Catalina. 
Double-tap on any webpage does not zoom on webpage (even Bugzilla).
Bug: Address Bar Spoofing due to Arabic RTL characters (fix domain highlighting)
Status: VERIFIED
Priority: P3
Resolution: FIXED
Created: 2021-04-12 04:57:05+00:00
Resolved: 2024-06-12 12:39:01+00:00

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

Steps to reproduce:

Tested on:
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:87.0) Gecko/20100101 Firefox/87.0
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.15; rv:87.0) Gecko/20100101 Firefox/87.0


STEP 1: Click on "run" in attached file ("firefox-desktop-PoC.html")
The address bar will point to "www.mozilla.org", however the actual content is being delivered by "اختبار.اختبار"

The URL is not handled properly. Arabic characters in the domain name are being rendered from Right to Left(RTL) direction rather than Left to Right(LTR).


Actual results:

http://www.mozilla.org/hello/1/index.html/رابتخا.رابتخا


Expected results:

http://اختبار.اختبار/www.mozilla.org/hello/1/index.html
The address bar should point to "اختبار.اختبار" instead of "www.mozilla.org"
Bug: Add-On "Firefox Multi-Account Containers" icon in address bar uses wrong color in dark theme
Status: RESOLVED
Priority: --
Resolution: MOVED
Created: 2021-04-12 07:11:08+00:00
Resolved: 2021-04-12 11:22:22+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:

In dark theme, icon for Add-On "Firefox Multi-Account Containers" in address bar uses wrong color (dark) in dark theme. The icon in toolbar is fine and uses a light color.


Actual results:

Address bar icon uses dark color on dark background.


Expected results:

Should use light color on dark background (as seen in toolbar).
Bug: update-badge.svg isn't properly horizontally centered
Status: VERIFIED
Priority: P2
Resolution: FIXED
Created: 2021-04-12 09:42:29+00:00
Resolved: 2021-04-28 09:47:28+00:00

The arrow in [update-badge.svg](https://searchfox.org/mozilla-central/rev/fa48ebee58d59fa846919c3e2c3122b08db57c9c/browser/themes/shared/update-badge.svg) isn't horizontally centered (it's too close to the right-side)
You can see in the attached screenshot that there's more space between the border of the svg and the left edge of the arrow than on the right.
Bug: keyword search creates wrong utf8 query which causes bad request errors (on GitLab)
Status: RESOLVED
Priority: --
Resolution: DUPLICATE
Created: 2021-04-12 10:30:55+00:00
Resolved: 2021-04-13 04:14:24+00:00

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

Steps to reproduce:

1. Create a new keyword (gl) search for GitLab. (https://gitlab.com/)
2. Try search: `gl my-project`
3. See the error: `Bad Request`





Actual results:

URL: https://gitlab.com/search?utf8=%u2713&group_id=&project_id=&snippets=false&repository_ref=&nav_source=navbar&search=splunk

utf8=%u2713: (This is wrong)


Expected results:

https://gitlab.com/search?utf8=%E2%9C%93&search=splunk&group_id=&project_id=&snippets=false&repository_ref=&nav_source=navbar

utf8=%E2%9C%93: Tick ✓ (This is correct)
Bug: Duplicated commands in context menu for icons in address bar
Status: VERIFIED
Priority: P2
Resolution: FIXED
Created: 2021-04-12 10:53:47+00:00
Resolved: 2021-11-29 11:23:11+00:00

I have two extensions adding an icon to the address bar, and the add/remove commands are duplicated. Tried on a clean en-US profile, and same issue.

macOS, nightly 89 (20210411210108)
Bug: Screen Readers will not read the email text in the Hamburger menu notification banner
Status: VERIFIED
Priority: P2
Resolution: FIXED
Created: 2021-04-12 11:30:06+00:00
Resolved: 2023-06-02 15:21:26+00:00

[Affected platforms]:
Platforms: Windows 10

[Preconditions]:

Reach about:config and set browser.proton.enabled = true
[Steps to reproduce]:

Launch the Firefox Browser and Create a new account without verifying it.
Reach the Fxa Notification from the Hamburger menu using NVDA or other screen readers.
Move the Mouse cursor on top of the email address.
Restart the Browser and reach the Fxa Notification from the Hamburger menu using NVDA and hover over the email address.

Expected Result:
NVDA should read the Email address when the user hovers over it.

Actual Results:
NVDA does not read the email adress at all.
Bug: [proton] Fuzzy icons and text on toolbar with proton dark theme
Status: RESOLVED
Priority: P1
Resolution: DUPLICATE
Created: 2021-04-12 12:56:08+00:00
Resolved: 2021-04-19 15:17:59+00:00

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

Steps to reproduce:

Enable proton dark theme on 11th April's nightly


Actual results:

Fuzzy icons and text


Expected results:

Clear, crisp icons and text
Bug: Firefox's Tabs bar does not respect the Light app mode with Proton ON
Status: RESOLVED
Priority: P2
Resolution: WORKSFORME
Created: 2021-04-12 15:00:28+00:00
Resolved: 2021-04-21 14:17:01+00:00

**Affected platforms:**
Windows 10 

**Affected versions:**
Nightly 89.0a1

**Pre-requisites:**
Go to Settings -> Colors -> Choose a Custom color and set your Default Windows mode to DARK and your default app mode to LIGHT.

**Steps to reproduce:**
1. Launch Firefox from the Start Menu
2. Observe the Tabs Bar.

**Expected Result:**
Firefox should properly be opened respecting the selected app mode (Light in this case).

**Actual Results:**
When Firefox is launched, the tabs bar is dark and turns to light afterward.  Please see the screencast for more details.

**Notes:**
I can't reproduce this issue on the latest Firefox 88 beta 9.
Bug: Copy/download/X buttons for screenshots should be sticky
Status: RESOLVED
Priority: P3
Resolution: DUPLICATE
Created: 2021-04-12 15:02:59+00:00
Resolved: 2024-05-09 18:53:48+00:00

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

Steps to reproduce:

Navigate to a website with a sticky/fixed header and a very tall page, such as Facebook.
Open the screenshot tool.
Select a tall vertical desired region, taller than the viewport.


Actual results:

It is impossible to take such a screenshot without including the website's header in it. This is because, in order to take it, I am forced to scroll down, at the bottom of the screenshot region. Otherwise, the screenshot buttons Copy/Download/X are not visible on the screen.


Expected results:

The screenshot buttons should always be visible, even when the bottom of the selected region is outside the screen.

See also the attached images: In scrolled_up.png, the region is not obstructed by the header, but the Copy/Download/X buttons are not visible, so it's impossible to take a screenshot. In scrolled_down.png, the buttons are visible, but the region is obstructed by the header. Taking a screenshot in this state leads to scrolled_down.png.
Bug: Wrong badge is displayed on the Hamburger menu Icon for the Unable to Update system incompatible notification
Status: VERIFIED
Priority: --
Resolution: FIXED
Created: 2021-04-12 16:05:20+00:00
Resolved: 2021-05-04 07:18:19+00:00

[Affected platforms]:
Platforms: Windows 10

[Preconditions]:

Reach about:config and set browser.proton.enabled = true
[Steps to reproduce]:

Launch an older version of the Firefox browser.
Trigger the "Unable to Update" notification.

Expected Result:
The Badge icon displayed on the Hamburger menu should be an orange Warning sign.

Actual Results:
The Badge displayed on the Hamburger menu icon when the Unable to update notification is triggered is a Yellow Update Icon instead of the Orange warning sign
Bug: Open Redirect on Firefox Account link to play store via adjust.com
Status: RESOLVED
Priority: --
Resolution: INVALID
Created: 2021-04-12 16:08:43+00:00
Resolved: 2024-06-07 16:24:06+00:00

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

Steps to reproduce:

1. Visit https://accounts.firefox.com/settings
2. Scroll down => Get In on Google Play / Download on the App Store => Copy Link Location
3. Change the link after redirect= to evil.com or other urls such as google.com,bing.com,facebook.com etc.


Actual results:

An attacker can use this vulnerability to redirect users to other malicious websites, which can be used for phishing and similar attacks.


Expected results:

The URL should be the correct redirect but the parameters used are incorrect so it causes the URL to be able to Redirect to another site.
Bug: Nightly Firefox - Spanish Shortcuts do not work as expected.
Status: RESOLVED
Priority: --
Resolution: WORKSFORME
Created: 2021-04-12 16:28:36+00:00
Resolved: 2021-04-16 05:28:23+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) Opened the Menu from the upper-right corner of the browser.
2) Followed the steps to verify if shortcuts displayed (in Spanish) worked as expected.
3) Pressed CTRL + Mayúsc. + P to open a New Private Window.
Pressed CTRL + Mayúsc. + Q to exit.
4) Followed the same steps for all shortcuts displayed in Menu.
5) Verified the steps in another laptop which was set in English.
6) Reproduced the steps in English CTRL + Shift + P.



Actual results:

The keyboard shortcuts (Spanish) did not work as expected. 
CTRL + Mayúsc. + P : Print Window was opened, instead of a New Private Window.
CTRL + Mayúsc. + Q: nothing happened. But when pressing CTRL + Shift + Q= MemoQ window was opened, instead of exiting as expected when following English shortcut instructions (instead of using Mayúsc., used shift). 
Even though the keyboard and the language were set in Spanish, shortcuts could be only performed by following the steps in English (CTRL + SHIFT + (letter). In Spanish (as displayed in the menu), the shortcuts didn't work as expected (CTRL + SHIFT + (letter). I had to do research on other ways of using shortcuts.



Expected results:

Keyboard shortcuts (Spanish) displayed in the menu next to each option should have worked as expected.
Example: CTRL + Mayúsc. + P to open a New Private Window.
                 CTRL + Mayúsc. + Q to exit.