av9ash/GitBugs huggingface dataset:
Bug: PROTON: Search bar missing 2 borders in Contrast Mode
Status: VERIFIED
Priority: P2
Resolution: FIXED
Created: 2021-04-16 19:24:18+00:00
Resolved: 2021-05-03 19:52:32+00:00

**Affected platforms**
Ubuntu 20 64bit  is not affected
Mac OSX 10.14    is not affected
Windows 10 64bit affected

**version**
Fx89.0a1   affected

**Preconditions**
-Have high contrast mode enabled (winsows10 OS high contrast mode)
-proton On, (its on by default in nightly)

**Steps to reproduce**
-Launch Firefox nightly (proton is enabled by default) 
-enable the search bar. in about:preferences#search
-type some words in search bar

Expected result
Borders should be visible on all sides

Actual result
Border is visible in only 1 side.
Bug: Rally-study-01 study sends the wrong studyNamespace for all pings
Status: RESOLVED
Priority: P1
Resolution: FIXED
Created: 2021-04-16 20:58:44+00:00
Resolved: 2021-10-07 17:27:21+00:00

The rally-study-01 is rejecting data because the pioneer envelope is incorrect. Because of a pathological case in the princeton study, we are also immediately forwarding pings to the incorrect namespace (for enrollment) that are effectively non-recoverable.

From the console, I see a non-zero number of counters for `rally-study-01@mozilla.org.deletion-request.1 `, ` rally-study-01@mozilla.org.pioneer-enrollment.1 ` and `unknown_namespace/unknown_doctype/error_invalid_doc_type `.

https://console.cloud.google.com/dataflow/jobs/us-west1/2021-04-14_19_58_17-6715464223716968889?project=moz-fx-data-pioneer-prod-2a54

I confirmed that the schemaNamespace is incorrect, I missed this in a casual review of the the ping envelope:

```
{
  "encryptedData": "[...],
  "schemaVersion": 1,
  "schemaName": "measurement",
  "schemaNamespace": "rally-study-01@mozilla.org",
  "encryptionKeyId": "zero-one",
  "pioneerId": "235a4b4e-72fe-d14c-bd92-2eeca9381226",
  "studyName": "rally-study-01@mozilla.org"
}
```

This is certainly a client bug, it can be handled like bug 1674847 as an exceptional case, but I would prefer to limit logic in the decoder.
Bug: Shortcut count setting controls row count, but row count varies depending on window size
Status: NEW
Priority: P3
Created: 2021-04-16 23:05:08+00:00
Resolved: 2021-12-08 23:16:45+00:00

STR:
 1. Resize the browser window to be quite small
 1. Open the new tab page
 1. Change the new tab page's shortcut settings to "1 row"

Expected Results:
The shortcut setting picked should match what I see. If it says "1 row", I should see 1 row of shortcuts.

Actual Results:
There are multiple rows of shortcuts even though the setting reads "1 row".
Bug: Toolbar icons in dark and light themes have 70% opacity
Status: RESOLVED
Priority: P1
Resolution: FIXED
Created: 2021-04-17 00:46:31+00:00
Resolved: 2021-05-19 07:14:24+00:00

The fill color we end up with is an rgba() value, with 0.7 in the alpha channel. This should be 1 (full opacity).
Bug: Proton newtab have way too much padding and cause page scroll
Status: VERIFIED
Priority: P2
Resolution: FIXED
Created: 2021-04-17 02:50:46+00:00
Resolved: 2021-05-26 12:19:04+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. open firefox on windows on a screen equal to 1080P with taskbar to always present.
2. open new tab
3. open the config on new tab
4. set the row to 2


Actual results:

The new tab have a useless scrollbar.
All contents are visible, but the extra margin caused a scrollbar.


Expected results:

There shouldn't be a scrollbar when there is only whitespace (did it use margin to replace padding and cause such problem? I remember that Firefox don't cause scrollbar in that case.).
Bug: The background color of the zoom indicator should be reconsidered
Status: RESOLVED
Priority: --
Resolution: WONTFIX
Created: 2021-04-17 14:26:43+00:00
Resolved: 2021-04-20 11:19:14+00:00

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

Steps to reproduce:

In the Proton theme refresh, the background color of the zoom indicator should be reconsidered.
Proton is attempting to change the background color of the address bar to gray and the zoom indicator to white for the Light Theme.
As a result, in the address bar, the zoom indicator has more contrast than the URL itself, making it more prominent and eye-catching.

Is there any reason for highlighting zoom rather than URL?
This bug can be WONTFIX if it is intentionally highlighted for good reason.
Otherwise, you should change the background color of the zoom indicator.
Bug: View Source not showing latest source
Status: RESOLVED
Priority: --
Resolution: INCOMPLETE
Created: 2021-04-17 17:23:14+00:00
Resolved: 2021-05-21 12:07:42+00:00

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

Steps to reproduce:

Change content. Reload. Page holds changed content.
Open up view source. Still holds the initial source.


Actual results:

View source is stuck with the initial source of the page, regardless of how many times I reload. 


Expected results:

When selecting view source, it should hold the actual source of the page. Each time it has changed. That is, if I reloaded the page prior to selecting view source.
Bug: Site Identity "tracking-protection on/off" slider looks like it's disabled/unclickable when it's in its "off" state
Status: NEW
Priority: P5
Created: 2021-04-17 17:45:09+00:00
Resolved: 2022-09-06 12:34:50+00:00

[EDIT: Initially I had a paragraph here about how I thought this was a MR1/proton-related change, but actually it looks like this slider's been the same for a few years. So: this isn't proton/MR1-related]

STR:
1. Start Firefox Nightly
2. Visit some site, e.g. https://www.wikipedia.org/
3. Click the shield icon at the left edge of the URL bar.
4. Click the "Enhanced Tracking Protection" slider to turn tracking protection **off**.
5. Reload and then click the shield icon again.

ACTUAL RESULTS:
The tracking protection slider is pretty hard to see, and it looks like it's grayed-out/disabled (like it might be unclickable, even though it is in fact clickable). See attached screenshot.

EXPECTED RESULTS:
The slider should remain clearly visible and shouldn't look disabled.
Bug: Proton small icons with thin lines makes them hard to "read"
Status: NEW
Priority: P3
Created: 2021-04-17 18:15:18+00:00
Resolved: 2025-03-02 14:51:03+00:00

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

Steps to reproduce:

Start new Nigthly profile 20210417095008 and look at some icons.


Actual results:

Some icons like sidebars or bookmarks menu have weird horizontal shadows, like broken antialiasing, which make them not pleasant to look at.

Other are so thin that is hard to distinguish they are active or not - back/forward arrows for example.

Some are so tiny that it's difficult to see what they mean, for example I had to look from 20cm to see arrow in update available marker (I was curious what this tiny "scratch" is) and to figure out that "fullscreen" button in hamburger menu are actually two arrows.

Additionally all these thin horizontal lines are difficult to me because of my astigmatism.

In general - there are lot of whitespace which should make them easier to read but it is pointless, because in the same time icons are small and thin which make them far worse to read than before.

This is on 24'' HD monitor.
Bug: Block encoded JavaScript in url address bar
Status: RESOLVED
Priority: --
Resolution: INCOMPLETE
Created: 2021-04-18 02:33:35+00:00
Resolved: 2021-05-01 02:15:08+00:00

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

Steps to reproduce:

An attacker could modify the contents of a webpage or send data to an attacker’s server by using encoded JavaScript in the url address bar.


Actual results:

Emailed financial alerts could be searched for and deleted.


Expected results:

Maybe encoded JavaScript in the url address bar could be blocked/sanitized/checked for malicious commands.
Bug: POST searches do not work with drag-and-drop text
Status: NEW
Priority: P3
Created: 2021-04-18 09:04:40+00:00
Resolved: 2021-05-27 16:40:57+00:00

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

Steps to reproduce:

I added a search engine that uses POST (searx.be) using OpenSearch ('Add search engine'). I set it as the default search engine. I made a search by dragging and dropping text from the current tab to a new tab.


Actual results:

No search was made; instead, a normal GET request was made to the website, hence losing the text search.


Expected results:

I expected the search with dragging and dropping to use POST like all the other methods of searching. The normal search works (typing into the Awesome Bar), dragging and dropping works in the same tab, but when opening a new tab or replacing an active tab with drag-and-drop the search parameters are lost. This is a major inconvenience for people who use search engines that use POST.
Bug: Crash in [@ shutdownhang | NtUserMsgWaitForMultipleObjectsEx | CCliModalLoop::SetPointerInputModeAsAppropriateForQueueAttachmentConditions]
Status: RESOLVED
Priority: --
Resolution: DUPLICATE
Created: 2021-04-18 17:10:20+00:00
Resolved: 2021-04-20 08:09:39+00:00

Crash report: https://crash-stats.mozilla.org/report/index/6193dc9b-5c19-4c54-a1e0-6a0070210402

MOZ_CRASH Reason: ```Shutdown hanging at step quit-application. Something is blocking the main-thread.```

Top 10 frames of crashing thread:
```
0 win32u.dll NtUserMsgWaitForMultipleObjectsEx 
1 user32.dll unsigned long RealMsgWaitForMultipleObjectsEx 
2 combase.dll CCliModalLoop::SetPointerInputModeAsAppropriateForQueueAttachmentConditions onecore\com\combase\dcomrem\callctrl.cxx:1678
3 combase.dll CCliModalLoop::BlockFn onecore\com\combase\dcomrem\callctrl.cxx:2156
4 combase.dll ClassicSTAThreadWaitForCall onecore\com\combase\dcomrem\threadtypespecific.cpp:172
5 combase.dll CSyncClientCall::SendReceive2 onecore\com\combase\dcomrem\channelb.cxx:5459
6 combase.dll ClassicSTAThreadSendReceive onecore\com\combase\dcomrem\callctrl.cxx:547
7 combase.dll CSyncClientCall::SendReceive onecore\com\combase\dcomrem\ctxchnl.cxx:778
8 combase.dll CClientChannel::SendReceive onecore\com\combase\dcomrem\ctxchnl.cxx:655
9 combase.dll NdrExtpProxySendReceive onecore\com\combase\ndr\ndrole\proxy.cxx:1998
```
Bug: Crash in [@ shutdownhang | NtUserMsgWaitForMultipleObjectsEx | CCliModalLoop::SetPointerInputModeAsAppropriateForQueueAttachmentConditions]
Status: RESOLVED
Priority: --
Resolution: DUPLICATE
Created: 2021-04-18 17:14:44+00:00
Resolved: 2021-04-20 08:11:10+00:00

Crash report: https://crash-stats.mozilla.org/report/index/6193dc9b-5c19-4c54-a1e0-6a0070210402

MOZ_CRASH Reason: ```Shutdown hanging at step quit-application. Something is blocking the main-thread.```

Top 10 frames of crashing thread:
```
0 win32u.dll NtUserMsgWaitForMultipleObjectsEx 
1 user32.dll unsigned long RealMsgWaitForMultipleObjectsEx 
2 combase.dll CCliModalLoop::SetPointerInputModeAsAppropriateForQueueAttachmentConditions onecore\com\combase\dcomrem\callctrl.cxx:1678
3 combase.dll CCliModalLoop::BlockFn onecore\com\combase\dcomrem\callctrl.cxx:2156
4 combase.dll ClassicSTAThreadWaitForCall onecore\com\combase\dcomrem\threadtypespecific.cpp:172
5 combase.dll CSyncClientCall::SendReceive2 onecore\com\combase\dcomrem\channelb.cxx:5459
6 combase.dll ClassicSTAThreadSendReceive onecore\com\combase\dcomrem\callctrl.cxx:547
7 combase.dll CSyncClientCall::SendReceive onecore\com\combase\dcomrem\ctxchnl.cxx:778
8 combase.dll CClientChannel::SendReceive onecore\com\combase\dcomrem\ctxchnl.cxx:655
9 combase.dll NdrExtpProxySendReceive onecore\com\combase\ndr\ndrole\proxy.cxx:1998
```
Bug: Lost bookmarks and backups
Status: RESOLVED
Priority: --
Resolution: INVALID
Created: 2021-04-18 19:30:14+00:00
Resolved: 2021-04-19 21:51:03+00:00

Hello. I am writing to you because I do not know exactly where to write with this problem and letters sent to @ mozilla.org come back. I lost all the bookmarks on my account, in general, I installed a new system and immediately installed Firefox and logged into the account, but not the one that was the main one and it turned out that when I entered the main one, I synchronized with the account on which there was nothing, actions: Bookmarks - Show all bookmarks - Restore from backup does not help, there are no backups. Help restore bookmarks. Thanks.
Bug: Blank page will be saved in the bookmarks when a new tab is opened
Status: RESOLVED
Priority: --
Resolution: INCOMPLETE
Created: 2021-04-18 20:14:23+00:00
Resolved: 2021-05-07 12:35:26+00:00

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

Steps to reproduce:

I opened a new tab by clicking on the ,+'


Actual results:

Everytime i open a new tab, a blankpage will be saved to my bookmarks.


Expected results:

The new blank tab should't be saved in the bookmarks.
I already cleaned up 40 tabs. But they come back evertime i open a new tab.
Very annoying
Bug: Firefox opens downloaded archive TWICE
Status: RESOLVED
Priority: --
Resolution: INCOMPLETE
Created: 2021-04-18 20:52:45+00:00
Resolved: 2021-11-26 14:27:33+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 click on a link that downloads a zip archive
- FF informs me (with a red spot next to the download arrow) that there is very dangerous stuff in that archive: "This file contains a virus or malware" (which is not true, btw)
- I click nonetheless, and FF informs me a second time that "This file contains a virus or malware"
- my fingers are aching now from all the clicking, but nonetheless I click once on "Open"



Actual results:

- Firefox launches TWICE my zip archiver (7-zip in this case)


Expected results:

- Firefox should have launched my zip archiver only ONCE

Btw it would be incredibly helpful if there was an option "don't check archives from http://myutterlydangerousprogrammingsite.com ;-)
Bug: [Proton] The warning icon from download panel lacks a fill colour (isn't yellow anymore)
Status: VERIFIED
Priority: P2
Resolution: FIXED
Created: 2021-04-19 09:35:42+00:00
Resolved: 2021-04-28 14:47:49+00:00

**Affected versions**
* latest Nightly 89.0a1

**Affected platforms**
* Windows 10 x64
* Ubuntu 18.04 x64
* macOS 10.15

**Steps to reproduce**
1. Launch Firefox.
2. Go to http://testsafebrowsing.appspot.com/s/pua.exe and download the file.
3. Click on the download icon from toolbar.

**Expected result**
* The warning sign has a yellow color.

**Actual result**
* The warning sign has a black color.

**Suggested Severity**
* S2, since this is a regression.

**Regression range**
* Changeset: 88c44defb4d3c0199dfdedf65b6bb963f2e37e48
* Pushlog: pushlog_url: https://hg.mozilla.org/integration/autoland/pushloghtml?fromchange=88c44defb4d3c0199dfdedf65b6bb963f2e37e48&tochange=b088b7f2c9d3e56a5a3890db3813d673d5941b0c
* Potential regressor: Bug 1704945

**Additional notes**
* please see the attached screenshot.
Bug: Crash in [@ mozilla::glue::LoaderObserver::OnEndDllLoad]
Status: RESOLVED
Priority: --
Resolution: FIXED
Created: 2021-04-19 10:53:08+00:00
Resolved: 2021-11-23 07:45:18+00:00

Crash report: https://crash-stats.mozilla.org/report/index/72c44512-c27f-44a5-85e6-94d5a0210417

Reason: ```EXCEPTION_ACCESS_VIOLATION_READ```

Top 10 frames of crashing thread:
```
0 mozglue.dll mozilla::glue::LoaderObserver::OnEndDllLoad mozglue/dllservices/LoaderObserver.cpp:88
1 firefox.exe mozilla::freestanding::LoaderPrivateAPIImp::NotifyEndDllLoad browser/app/winlauncher/freestanding/LoaderPrivateAPI.cpp:196
2 firefox.exe mozilla::freestanding::ModuleLoadFrame::~ModuleLoadFrame browser/app/winlauncher/freestanding/ModuleLoadFrame.cpp:40
3 firefox.exe mozilla::freestanding::patched_LdrLoadDll browser/app/winlauncher/freestanding/DllBlocklist.cpp:359
4 kernelbase.dll LoadLibraryExW 
5 user32.dll _ClientLoadLibrary 
6 ntdll.dll KiUserCallbackDispatch 
7 win32u.dll NtUserMessageCall 
8 user32.dll int64_t RealDefWindowProcWorker 
9 user32.dll DefWindowProcW 
```
Tentatively filing this in the launcher component because the launcher seems involved though I don't know exactly how. I'm trying to get a better stack trace using Visual Studio.

This is a use-after-free crash, rax contains the poison value in every crash I looked at.
Bug: 25.13 - 21.63% tresize / tresize (Linux) regression on Thu April 15 2021
Status: RESOLVED
Priority: --
Resolution: WONTFIX
Created: 2021-04-19 11:40:57+00:00
Resolved: 2021-05-18 19:53:59+00:00

Perfherder has detected a talos performance regression from push [e718c31620b4ab8efc075b58c8f6839589af16d5](https://hg.mozilla.org/integration/autoland/pushloghtml?changeset=e718c31620b4ab8efc075b58c8f6839589af16d5). 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)**| 
|--|--|--|--|--|--| 
| 25% | tresize |  | linux1804-64-shippable | e10s stylo | 14.31 -> 17.91 |
| 22% | tresize |  | linux1804-64-shippable | e10s stylo | 14.62 -> 17.78 |
### Improvements:

| **Ratio** | **Suite** | **Test** | **Platform** | **Options** | **Absolute values (old vs new)**| 
|--|--|--|--|--|--| 
| 31% | about_newtab_with_snippets |  | linux1804-64-shippable-qr | e10s stylo webrender-sw | 58.09 -> 40.13 |


Details of the alert can be found in the [alert summary](https://treeherder.mozilla.org/perfherder/alerts?id=29735), 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: The font of the “Learn more” link in the “Import Error” modal seems thicker than it should be
Status: VERIFIED
Priority: --
Resolution: FIXED
Created: 2021-04-19 11:40:58+00:00
Resolved: 2021-04-26 14:02:20+00:00

**[Affected Versions]:**
- Firefox Nightly 89.0a1 (Build ID: 20210418213620)

**[Affected Platforms]:**
- Linux Mint 20
- Windows 10
- macOS 11.1

**[Prerequisites]:**
- Have Firefox open.
- From the “about:config” page, have `signon.management.page.fileImport.enabled` set to `true`.
- Have a CSV file containing login data for which the header row has been deleted.

**[Steps to reproduce]:**
1. Navigate to “about:logins”.
2. Click the meatball menu button (“...”).
3. Choose the “Import from a File...” option.
4. Choose a CSV file without a header and import it.
5. Observe the text of the “Import Error” modal.

**[Expected result]:**
- The font of the “Learn more” link is slightly thinner.

**[Actual result]:**
- The font of the “Learn more” link seems to now be slightly thicker than it should be compared to the [documentation](https://mozilla.invisionapp.com/share/R3XX2AF2XN5#/screens/423736091).

**[Notes]:**
- Attached is a screenshot of the issue compared to the documentation.
Bug: [macOS] Scrollbar in panels is offset
Status: VERIFIED
Priority: P2
Resolution: FIXED
Created: 2021-04-19 11:49:03+00:00
Resolved: 2021-06-07 08:44:50+00:00

**Affected versions**
- Firefox 89.0a1

**Affected platforms**
- macOS 10.15.7

**Steps to reproduce**
1. Launch Firefox
2. Open a panel which has a scrollbar (ex. library)

**Expected result**
- The scrollbar is centered in its place

**Actual result**
- The scrollbar is a bit offset to the right

**Regression range**
- Will see for a regression

**Additional notes**
- The issue can be seen in the attachment
Bug: Show more bookmarks remains if Bookmarks Toolbar Items is added back to bookmarks toolbar
Status: NEW
Priority: P5
Created: 2021-04-19 12:17:26+00:00
Resolved: 2024-06-07 04:05:26+00:00

*Affected versions*
* 89.0a1(20210418213620)
* 88.0 (20210415204500)
* 87.0 (20210318103112)
* 78.10esr (20210412162915)

*Affected platforms*

* Windows 10x64
* macOS 10.15
* Ubuntu 20.04


*Preconditions*
* Have 2-3 bookmarks.


*Steps to reproduce*
1. Open Firefox enable bookmarks toolbar.
2. Add Bookmarks Toolbar Items to the toolbar, exit Customize and resize the browser so the overflow bookmarks are displayed.
3. Put Bookmarks Toolbar Items back on the bookmarks toolbar and exit customize.

*Expected result*
* No additional overflow menu is displayed.

*Actual result*
* An empty Show more bookmarks buttons is displayed.

*Regression range*
* Last good revision: b4c1ad9565ee9d00d96501c4a83083daf25c1413 (2017-09-07)
First bad revision: ea7b55d65d76214f97aaae502d65cb26fc6f5659 (2017-09-08)
Pushlog:
https://hg.mozilla.org/mozilla-central/pushloghtml?fromchange=b4c1ad9565ee9d00d96501c4a83083daf25c1413&tochange=ea7b55d65d76214f97aaae502d65cb26fc6f5659




*Notes*
* Attached a screen recording.
* This issue manifest with proton enabled and disabled as well.
Bug: Firefox accounts button is hidden when exiting customize mode if not signed in
Status: NEW
Priority: P3
Created: 2021-04-19 12:47:24+00:00
Resolved: 2021-04-22 15:38:21+00:00

In a fresh profile going into customize mode shows the FxA accounts button in the toolbar but it disappears when you exit (same thing when you move it to a new location in the toolbar).
Bug: Overflow menu jumps and re-stretches back to position if profiler is opened
Status: NEW
Priority: P3
Created: 2021-04-19 13:22:34+00:00
Resolved: 2021-05-12 15:18:55+00:00

**Affected versions**
- Firefox 89.0a1

**Affected platforms**
- macOS 10.15.7
- Windows 10
- Ubuntu 20.04

**Steps to reproduce**
1. Launch Firefox
2. Enter customize mode
3. Drag profiler to the Overflow menu and save the changes
4. Open the Overflow menu and click on profiler

**Expected result**
- The menu is opened smoothly

**Actual result**
- The menu jumps and re-stretches back to its position

**Regression range**
- Will see for a regression

**Additional notes**
- The issue can be seen in the following [attachment](https://drive.google.com/file/d/1Dq6YVJNlCct15Yp88KOwZgwQo3g1B6qX/view?usp=sharing)
- The issue is not happening if the main proton pref is deactivated
Bug: The Firefox/Nightly chiclet shrinks, hiding the displayed chiclet text
Status: NEW
Priority: P3
Created: 2021-04-19 13:25:31+00:00
Resolved: 2021-04-26 10:02:27+00:00

**Affected versions**
* Fx89.0a1

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

**Steps to reproduce**
1. Launch Firefox.
2. Navigate to about:support.
3. Grab the side of the Firefox window and make it narrower.
4. Observe the Firefox/Nightly chiclet in the address bar.

**Expected result**
* The chiclet is fully displayed even if the window is narrower.

**Actual result**
* The button in the text is partly hidden.

**Regression range**
* This is not a regression.

**Additional notes**
* See the attachment for more details.
* The issue occurs on all pages where the nightly/firefox chiclets are displayed in the address bar.