av9ash/GitBugs huggingface dataset:
Bug: sidebar tools and extensions are not wrapping
Status: VERIFIED
Priority: P2
Resolution: FIXED
Created: 2024-12-19 11:05:38+00:00
Resolved: 2025-01-13 12:24:16+00:00

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

Steps to reproduce:

Problem issues due to having multiple addons in the sideview.


Actual results:

symbols in the sideview are not displayed correctly, see image. Pretty self-explanatory


Expected results:

Symbols should be stacked in multiple lines or alternatively in an overhang like at the top right for plugins etc.
Bug: Adding a removed default engine via contextual search does not restore the engine
Status: NEW
Priority: P3
Created: 2024-12-19 12:49:11+00:00
Resolved: 2025-01-06 16:45:07+00:00

**Found in**
* Nightly 135.0a1;

**Affected versions**
* Nightly 135.0a1;

**Affected platforms**
* Windows 10;
* Ubuntu 22;
* macOS 14; 

**Steps to reproduce**
1. Launch Firefox.
2. Navigate to about:preferences#search and remove a default app provided search engine.
3. In a new tab, navigate to the home page of the removed search engine. 
4. Perform a few searches via contextual search and accept to add the engine. 
5. Go to about:preferences#search and observe the Search Shortcuts panel. 
  
**Expected result**
* Search engine is restored to the Search Shortcuts panel. 

**Actual result**
* Search engine is missing from the Search Shortcuts panel. 

**Regression range**
* N/A.
Bug: Perma browser/components/urlbar/tests/browser/browser_searchModeSwitcher_telemetry.js | false == true - when Gecko 135 merges to beta on 2025-01-06
Status: VERIFIED
Priority: --
Resolution: FIXED
Created: 2024-12-19 14:24:27+00:00
Resolved: 2025-01-04 17:22:03+00:00

[Central-as-beta-simulation](https://treeherder.mozilla.org/jobs?repo=try&group_state=expanded&resultStatus=testfailed%2Cbusted%2Cexception&revision=fea279f61d2034760b4d369cd2c22408ba8d2627&searchStr=bc7&selectedTaskRun=fLpuvO4HTMaXSWoZjX4ohg.0&test_paths=browser%2Fcomponents%2Furlbar%2Ftests%2Fbrowser)
 
[How to run these simulations](https://wiki.mozilla.org/Sheriffing/How_To/Beta_simulations#TRUNK_AS_EARLY_BETA)
 
 
[Failure log](https://treeherder.mozilla.org/logviewer?job_id=487603678&repo=try)

```
[task 2024-12-19T13:50:39.446Z] 13:50:39     INFO - TEST-PASS | browser/components/urlbar/tests/browser/browser_searchModeSwitcher_telemetry.js | null == null - 
[task 2024-12-19T13:50:39.446Z] 13:50:39     INFO - Open search mode switcher popup
[task 2024-12-19T13:50:39.447Z] 13:50:39     INFO - Buffered messages finished
[task 2024-12-19T13:50:39.448Z] 13:50:39     INFO - TEST-UNEXPECTED-FAIL | browser/components/urlbar/tests/browser/browser_searchModeSwitcher_telemetry.js | false == true - 
[task 2024-12-19T13:50:39.448Z] 13:50:39     INFO - Stack trace:
[task 2024-12-19T13:50:39.448Z] 13:50:39     INFO - resource://testing-common/UrlbarTestUtils.sys.mjs:openSearchModeSwitcher:1386
[task 2024-12-19T13:50:39.448Z] 13:50:39     INFO - chrome://mochitests/content/browser/browser/components/urlbar/tests/browser/browser_searchModeSwitcher_telemetry.js:test_opened:20
[task 2024-12-19T13:50:39.448Z] 13:50:39     INFO - chrome://mochikit/content/browser-test.js:handleTask:1147
[task 2024-12-19T13:50:39.448Z] 13:50:39     INFO - chrome://mochikit/content/browser-test.js:_runTaskBasedTest:1219
[task 2024-12-19T13:50:39.448Z] 13:50:39     INFO - chrome://mochikit/content/browser-test.js:Tester_execTest:1360
[task 2024-12-19T13:50:39.449Z] 13:50:39     INFO - chrome://mochikit/content/browser-test.js:nextTest/<:1136
[task 2024-12-19T13:50:39.449Z] 13:50:39     INFO - chrome://mochikit/content/tests/SimpleTest/SimpleTest.js:SimpleTest.waitForFocus/<:1058
[task 2024-12-19T13:50:39.676Z] 13:50:39     INFO - TEST-PASS | browser/components/urlbar/tests/browser/browser_searchModeSwitcher_telemetry.js | 1 == 1 - 
```
Bug: "Turn on Syncing" doesn't always show engine choices.
Status: RESOLVED
Priority: P2
Resolution: FIXED
Created: 2024-12-19 15:13:44+00:00
Resolved: 2025-02-05 12:50:10+00:00

STR:
* Sign in to the browser without sync
* From the hamburger menu, select "Turn on Syncing"
* Note about:preferences#sync is shown and the "choose what to sync" dialog is correctly shown.
* Cancel that dialog, switch to some other tab.
* Again, from the hamburger menu, select "Turn on Syncing"

Actual:
* The previous about:preferences#sync tab is selected but no CWTS dialog is shown.

Expected:
* The previous about:preferences#sync tab is selected and the CWTS dialog is again shown.

Notes:
* The reproduces if *any* tab is already on about:preferences - doesn't need to be the "sync" tab.
* This is after bug 1925377, and reproduces whether the "new treatment" is active or not. It's almost certainly not a regression from that bug.
Bug: PDF comments show as a blank comment window
Status: RESOLVED
Priority: --
Resolution: DUPLICATE
Created: 2024-12-19 15:20:36+00:00
Resolved: 2025-01-02 10:12:11+00:00

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

Steps to reproduce:

Using Workfront I open a marked up PDF file. 


Actual results:

PDF file opens and you can see the comment windows but all of them are empty


Expected results:

when PDF with comments is opened you should be able to see the comments from sender. This started happening after the most recent update.
Bug: Kiosk mode user still has access to password manager
Status: UNCONFIRMED
Priority: P3
Created: 2024-12-19 15:33:09+00:00
Resolved: 2025-01-14 15:08:29+00:00

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

Steps to reproduce:

Opening a web site with a shortcut on a windows 10 platform: 
start "C:\Program Files\Mozilla Firefox\firefox.exe" -private-window --kiosk=https://www.website.com


Actual results:

If the web site has input for user name and password right clicking on fields providers the user with password manager even though its in Kiosk mode


Expected results:

The user should not have access to password manager while in Kiosk mode.
Bug: [Rollout] The chatbot CSAT Micosurvey title overlaps the "X" button on the Firefox "de" locale build
Status: VERIFIED
Priority: P1
Resolution: FIXED
Created: 2024-12-19 15:39:31+00:00
Resolved: 2025-01-09 08:31:15+00:00

**[Affected versions]:**
- Firefox Beta 134.0b10 de locale - Build ID: 20241213091550

**[Affected Platforms]:**
- Windows 10
- macOS 15.1.1
- Ubuntu 24.04

**[Prerequisites]:**
- Have a Firefox Beta 134.0b10 "de" locale build installed.
- Client is enrolled in the "[Existing users: Sidebar + GenAI](https://experimenter.services.mozilla.com/nimbus/sidebar-vertical-tabs-layout-and-new-tools/summary)" experiment.
- Have a profile with the "nimbus.debug" pref set to true in the "about:config" page.
  
**[Steps to reproduce]:**
1. Open the browser using the profile from the prerequisites.
2. Navigate to the "about:studies?optin_slug=microsurvey-chatbot-csat-and-productivity-left-position&optin_branch=control&optin_collection=nimbus-preview" URL.
3. Go to the bottom-left part of the screen and click the "Open AI chatbot" sidebar button.
4. Click the "X" button from the top right part of the sidebar.
5. Repeat steps 3 and 4 for two more times.
6. Go to the bottom-left part of the screen and click the "Open AI chatbot" sidebar button.
7. Observe the chatbot CSAT Micosurvey title.

**[Expected result]:**
- The title of the Chatbot CSAT Microsurvey is displayed correctly and does not overlap with the "X" button.
    
**[Actual result]:**
- The chatbot CSAT Micosurvey title overlaps the "X" button

**[Additional Notes]:**
- This issue is reproducible on both screens of the chatbot CSAT Micosurvey.
- The issue may be reproducible on other locales with long strings in the title.
- Attached a screen recording of the issue.
Bug: [Rollout] The sidebar CSAT Microsurvey title overlaps the "X" button on the Firefox "de" locale build
Status: VERIFIED
Priority: P1
Resolution: FIXED
Created: 2024-12-19 16:11:52+00:00
Resolved: 2025-01-09 08:28:23+00:00

**[Affected versions]:**
- Firefox Beta 134.0b10 Build ID: 20241213091550

**[Affected Platforms]:**
- Windows 10 x64
- Ubuntu 22.04 x64
- macOS 15.1.1

**[Prerequisites]:**
- Have a Firefox Beta 134.0b10 "de" locale build installed.
- Client is enrolled in the ["Existing users: Sidebar + GenAI"](https://experimenter.services.mozilla.com/nimbus/sidebar-vertical-tabs-layout-and-new-tools/summary) experiment.
- Have a profile with the "nimbus.debug" pref set to true in the "about:config" page.

**[Steps to reproduce]:**
1. Open the browser using the profile from the prerequisites.
2. Navigate to the "about:studies?optin_slug=134-sidebar-microsurvey&optin_branch=control&optin_collection=nimbus-preview" URL.
4. Go to the bottom-left part of the screen and click the "History" sidebar button.
5. Open and close the “History” section for 4 more times.
6. Observe the sidebar CSAT Microsurvey title.

**[Expected result]:**
-  The title of the sidebar CSAT Microsurvey is displayed correctly and does not overlap with the "X" button.

**[Actual result]:**
-  The sidebar CSAT Microsurvey title overlaps the "X" button.

**[Notes]:**
- This issue is reproducible on all 3 screens of the sidebar CSAT Microsurvey.
- The issue may be reproducible on other locales with long strings in the title.
- This issue is reproducible with both the left and right side microsurveys.
- Attached is a screen shot of the issue.
Bug: [Rollout] The radio buttons from the “Microsurvey: sidebar CSAT and productivity” rollouts are misaligned with the text of the survey options
Status: RESOLVED
Priority: P1
Resolution: WONTFIX
Created: 2024-12-19 16:29:42+00:00
Resolved: 2025-03-05 16:59:38+00:00

**[Affected versions]:**
- Firefox Beta 134.0b10 Build ID: 20241213091550

**[Affected Platforms]:**
- Windows 10 x64
- Ubuntu 22.04 x64

**[Prerequisites]:**
- Have a Firefox Beta 134.0b10 build installed with the channel changed to “release”.
- Client is enrolled in the ["Existing users: Sidebar + GenAI"](https://experimenter.services.mozilla.com/nimbus/sidebar-vertical-tabs-layout-and-new-tools/summary) experiment.
- Have a profile with the "nimbus.debug" pref set to true in the "about:config" page.

**[Steps to reproduce]:**
1. Open the browser using the profile from the prerequisites.
2. Navigate to the "about:studies?optin_slug=134-sidebar-microsurvey&optin_branch=control&optin_collection=nimbus-preview" URL.
4. Go to the bottom-left part of the screen and click the "History" sidebar button.
5. Open and close the “History” section for 4 more times.
6. Observe the sidebar CSAT Microsurvey radio buttons.

**[Expected result]:**
-  The radio buttons are evenly aligned with the text of the survey options.

**[Actual result]:**
-  The radio buttons are slightly above the text of the survey options with several pixels.

**[Notes]:**
- This issue is reproducible on all 3 screens of the sidebar CSAT Microsurvey.
- This issue is reproducible with both the left and right side microsurveys.
- Attached is a screen shot of the issue.
Bug: Enable ungrouped and grouped tabs to be dragged and dropped anywhere along the tab bar
Status: NEW
Priority: --
Created: 2024-12-19 16:51:05+00:00
Resolved: 2025-01-23 23:58:18+00:00

Steps to reproduce [can add screenshots or video recordings for reference  if needed]:

1. Open new window
2. Create multiple tab groups
3. Create a new, ungrouped tab using CMD+T
4. See that tab created to the right of the groups
5. Attempt to drag and drop any tab, whether grouped or an ungrouped. Drag it:
6. A. between two tabs
6. B. between two groups
7. C. to the left of all groups (outside of any group)
8. D. to the right of all groups (outside of any group)

Expected behavior [What should have happened?]:

It should be possible to drag and drop any (initially grouped or ungrouped) tab to place it 
- between two tabs
- between two groups
- to the left of all groups, even if there are no ungrouped tabs in this location
- to the right of all groups, even if there are no ungrouped tabs in this location

Actual behavior [What actually happened?]:
It is _not_ possible to drop a grouped or ungrouped tab
-  in between any group
- to the right of all groups (unless there is already an ungrouped tab in that location)
- to the left of all groups (unless there is already an ungrouped tab in that location)

**Discussion**: People organize their browser tab bar to fit their mental model and their ergonomic needs. Because users have always been able to reposition tabs along the bar, they will continue to expect to be able to reposition tabs wherever they want them: to the right or left of all groups, in between groups, etc. The same expectation is true for the group labels themselves. Users will expect to be able to reorder groups by dragging them to the left or right, and will expect to be able to drop a group anywhere along the tab bar, whether between two groups, or among a mix of tabs and groups, or just tabs.
Bug: Unified Search Button dropdown-menu has unnecessary extra padding at the bottom (looking almost like a blank menu-item)
Status: RESOLVED
Priority: --
Resolution: DUPLICATE
Created: 2024-12-19 17:50:30+00:00
Resolved: 2024-12-20 08:42:19+00:00

STR:
1. Open a new tab.
2. Click the Unified Search Button to open its menu.
3. Compare to other menus

ACTUAL RESULTS:
There's some padding at the bottom, approximately enough to fit a whole other menu-item.

EXPECTED RESULTS:
Some padding, but not quite that much. It should be consistent with our other dropdown-menus.
Bug: Address bar autocompletion suggestions jiggle up and down when I hover/unhover suggestions that have a badge for being a sync'ed tab
Status: VERIFIED
Priority: --
Resolution: FIXED
Created: 2024-12-19 19:48:47+00:00
Resolved: 2025-01-23 15:29:15+00:00

I'm still seeing a version of bug 1901161 for synced tabs -- mbeier, maybe you'd be up for taking a look, since you looked at bug 1901161?

STR:
1. Sign into a Firefox account in two different Firefox profiles (e.g. on two different machines)
2. Visit https://example.org on one profile (let's call this the "remote profile"), and trigger a sync (Tools | Sync Now) to be sure that gets noticed.
3. On your other profile (let's call it the "local profile"), trigger a sync to be sure it's aware that example.org is open elsewhere.
4. Still on the local profile, focus your URLbar and type "example".
5. Hover the autocomplete suggestion for the remote tab at example.org , or traverse it using uparrow/downarrow to move the selection-highlight.

ACTUAL RESULTS:
When the autocomplete suggestion is hovered or selected, the synced-tab badge disappears and that seems to make the entry get ever-so-slightly shorter (the same as in bug 1901161), and that makes the following content jiggle upwards slightly.

EXPECTED RESULTS:
No such jiggling (no such change in height when the badge disappears)
Bug: Address bar has no spacing between the "switch to tab" badge and the URL, with Unified Search Button (scotch bonnet) enabled
Status: VERIFIED
Priority: P1
Resolution: FIXED
Created: 2024-12-19 20:05:57+00:00
Resolved: 2024-12-31 11:04:04+00:00

STR:
1. Visit https://example.org/
2. Open a new tab and type "example"
3. Press downarrow to focus the Firefox Suggest suggestion to switch-to-tab.
4. Look at your URL bar.

EXPECTED RESULTS:
There should be some space between the right edge of the `Switch to tab:` badge and the URL itself (the leading "h" character)

ACTUAL RESULTS:
There's no space between them; the rightmost pixel of the badge is directly adjacent to the leftmost (antialiased) pixel of the "h" in the URL.

Notes:
* After reproducing the bug, if I press Ctrl to hide the Switch-to-tab badge (so that the address bar just shows the unified-search-button and the URL), then I get expected-results in that context -- there's space to the left of the "h".
* If I set `browser.urlbar.scotchBonnet.enableOverride` to `false`, I get EXPECTED RESULTS.  Interestingly, the URL remains in precisely the same pixel location (as you can see in upcoming screenshots if you open them in side-by-side tabs and compare back and forth); but the buttons to the left of the URL just get a bit skinnier which leaves a reasonable amount of space.
Bug: Closing the only tab outside of the group, while group is collapsed, closes the whole window
Status: RESOLVED
Priority: --
Resolution: DUPLICATE
Created: 2024-12-20 03:16:32+00:00
Resolved: 2024-12-24 12:33:55+00:00

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

Steps to reproduce:

Firefox: 133.0.3 (64-bit) on Windows 10

Create a tab group with a few tabs.
Double click on group name to collapse the group
Open another tab that is not part of the group
Close that tab


Actual results:

The whole window got closed despite having some tabs in the tab group.


Expected results:

It should keep the window open.
Bug: switching away from and then back to about:addons tab refreshes it, to detriment of usability
Status: RESOLVED
Priority: --
Resolution: INVALID
Created: 2024-12-20 06:58:50+00:00
Resolved: 2024-12-20 07:06:12+00:00

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

Steps to reproduce:

1. open about:addons
2. find specific addon and disable it
3. switch to another tab
4. switch back to about:addons tab


Actual results:

2. the addon you disabled remains where you found it
4. the addon "disappeared" - it has moved to the "Disabled" section


Expected results:

2. should remain as is, it's good
4. the page - and addon on it - should be found exactly as you left them

why doesn't browser move the addon from one section to the other right when you toggle it On/Off? because it would be obvious usability error - things that you work with must not run around the page

and this should be so even if you for whatever reason need to do something in another tab

if browser needs to rerender a tab when it is activated (for example, because it doesn't keep rendered pages in memory to save memory - i'm not sure how it works) - that's okay, but it should exactly rerender it - not reload! imagine regular web pages would be reloaded every time you switch between tabs - even if that happened instantly, it's not what anyone would want
Bug: www.youtube.com - When using a non-light theme, it adds to the end of the URL "/?themeRefresh=1" and refreshes the page on first load
Status: RESOLVED
Priority: P3
Resolution: DUPLICATE
Created: 2024-12-20 09:02:44+00:00
Resolved: 2025-01-27 13:48:37+00:00

From github: https://github.com/webcompat/web-bugs/issues/145353.

> <!-- @browser: Firefox 133.0 -->
> <!-- @ua_header: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:133.0) Gecko/20100101 Firefox/133.0 -->
> <!-- @reported_with: unknown -->
> <!-- @public_url: https://github.com/webcompat/web-bugs/issues/145353 -->
> 
> **URL**: https://www.youtube.com/
> 
> **Browser / Version**: Firefox 133.0
> **Operating System**: Windows 10
> **Tested Another Browser**: Yes Edge
> 
> **Problem type**: Something else
> **Description**: Using a theme other than "light" adds themeRefresh=1
> **Steps to Reproduce**:
> When using a theme other than "light" and opening a youtube page in private browsing it adds "&themeRefresh=1" to the end of the URL, this causes the entire page to refresh after 1 second beyond being frustrating it occasionally seems to cause issues depending on the timing of the refresh with the page displaying correctly or being unresponsive thereafter.
> 
> <details>
> <summary>Browser Configuration</summary>
> <ul>
>   <li>None</li>
> </ul>
> </details>
> 
> _From [webcompat.com](https://webcompat.com/) with ❤️_

Change performed by the [Move to Bugzilla add-on](https://addons.mozilla.org/en-US/firefox/addon/move-to-bugzilla/).
Bug: Unified Search Button icon is not refreshed on private window when changing default search engine for private mode
Status: VERIFIED
Priority: P3
Resolution: FIXED
Created: 2024-12-20 13:17:43+00:00
Resolved: 2025-01-23 09:50:08+00:00

**Notes**
* This is a small follow-up of bug 1937074

**Found in**
Nightly 135.0a1 2024-12-19;

**Affected versions**
Nightly 135.0a1;

**Affected platforms**
Windows 10/11;
Ubuntu 22;
macOS 14; 

**Steps to reproduce**
1. Set the following pref to true:
`browser.search.separatePrivateDefault.ui.enabled`
2. Open a private window and place it next to the normal window (both normal and private windows are in view)
3. Set a default private search engine in about:settings#search 
4. Observe the engine changing in the private window
 
**Expected result**
New engine is displayed everywhere on the private window (USB, urlbar label and websearch)

**Actual result**
USB icon shows the icon of the normal window default engine - until switching tabs. Refresh won't solve the issue. 
Searches from urlbar/websearch are correctly done with the private set engine.

**Regression range**
bug 1937074
Bug: When persist search terms is enabled, other icons in address bar should be shown
Status: UNCONFIRMED
Priority: P3
Created: 2024-12-20 13:36:13+00:00
Resolved: 2025-01-07 16:34:05+00:00

Steps to reproduce:

1. Use latest nightly and install extensions which show icon in address bar, such as Flagfox https://addons.mozilla.org/zh-CN/firefox/addon/flagfox
2. Search something in https://cn.bing.com/ via address bar


Actual results:

Extension doesn't show in address bar, unless click "earth" button. 


Expected results:

When persist search terms is enabled, other icons should be shown
Bug: "Firefox crashes when opening multiple tabs with heavy JavaScript content"
Status: RESOLVED
Priority: --
Resolution: DUPLICATE
Created: 2024-12-20 13:48:07+00:00
Resolved: 2024-12-20 14:39:04+00:00

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

Steps to reproduce:

Steps to Reproduce:

Open Firefox version 118.0.2.
Visit a website with heavy JavaScript content (e.g., https://example.com).
Open 10+ tabs with similar content in quick succession.
Observe the browser behavior.


Actual results:

Firefox becomes unresponsive and crashes after opening the 8th or 9th tab.


Expected results:

irefox handles multiple tabs smoothly without any crashes or slowdowns.
Bug: Tab groups that are saved and closed don't reappear in the "List all tabs" menu after restart
Status: VERIFIED
Priority: P1
Resolution: FIXED
Created: 2024-12-20 15:00:44+00:00
Resolved: 2025-01-10 12:39:35+00:00

STR

1. Enable "Open previous tabs & windows" on startup (not sure if this is necessary or not).
2. Create a tab group on the latest nightly
3. Collapse the group.
4. Right-click on it and select "Save and Close"

=> At this stage the group appears in the "List all tabs" menu.

5. Restart Firefox

Expected Results

=> The group is still listed in "List all tabs"

Actual Results

=> The group is no longer listed in "List all tabs"
Bug: Tab overflow menu – tab groups aren't left aligned properly
Status: RESOLVED
Priority: --
Resolution: DUPLICATE
Created: 2024-12-20 16:24:26+00:00
Resolved: 2024-12-20 17:10:30+00:00

**Steps to reproduce [can add screenshots or video recordings for reference]:**

Create a tab group
Open the Tab overflow menu

**Expected behavior [What should have happened?]:**
Tabs inside tab group should be left aligned according to spec

**Actual behavior [What actually happened?]:**
Tabs inside tab group aren't left aligned correctly so it's hard to tell whats in side a group and what's not (see screenshot)
Bug: Make navigator.clipboard.read() do all DLP requests at once
Status: NEW
Priority: --
Created: 2024-12-20 17:00:30+00:00
Resolved: 2025-03-05 08:59:13+00:00

Unlike the clipboard event case, `navigator.clipboard.read()` does separate requests for each flavor of the clipboard, meaning that we can't use the same `user_action_id` for them.

To fix this we'd need to make `ClipboardDataSnapshot::GetData()` analyze the full contents of the clipboard, like we do in `ClipboardContentAnalysisParent::RecvGetAllClipboardDataSync()`.

I don't think this is a blocker for 1.0 because if we only analyze one format on the clipboard this doesn't matter.

See comments in `browser_clipboard_read_async_content_analysis.js` for how to fix up the test after doing this.