av9ash/GitBugs huggingface dataset:
Bug: Wrong vertical tab bar color regressed by bug 1915805
Status: RESOLVED
Priority: --
Resolution: INVALID
Created: 2024-09-26 14:08:56+00:00
Resolved: 2024-09-27 01:13:43+00:00

STR:
1. Open Firefox nightly with "Fall Foggy Forest" theme is applied.
2. Open multiple web pages in tabs.

Actual result:
Icons on the vertical tab bar (AI chatbot, Preferences, etc.) are drawn in white with light gray background.

Expected result:
Icons on the vertical tab bar are drawn in white with black background.

Regression windows by mozregression:
https://hg.mozilla.org/integration/autoland/pushloghtml?fromchange=53238ac70a6f5251c218bb86f999499bb2c1d6f0&tochange=fb3f20098be7fc5a6ceb7f1a5e164f8c8b6989be

Testing environment:
The latest Firefox nightly Win64 on Windows 11 x64.
Bug: Content area box-shadow and outline cut off when sidebar is set to positionend in revamp.
Status: VERIFIED
Priority: P1
Resolution: FIXED
Created: 2024-09-26 15:02:33+00:00
Resolved: 2024-12-20 18:43:10+00:00

Regressed by:

Bug 1916004 - Use a box shadow for chrome/content separator. r=dao,desktop-theme-reviewers,tabbrowser-reviewers

This makes it work in fullscreen and regardless of whether the sidebar
(or the toolbox for that matter) is shown.

Differential Revision: https://phabricator.services.mozilla.com/D220770
Bug: Drag-and-drop of multiple files to HTML5 drag-n-drop area is broken in KDE sinse FF 128.0.b1
Status: RESOLVED
Priority: --
Resolution: DUPLICATE
Created: 2024-09-26 15:12:32+00:00
Resolved: 2024-09-27 18:55:24+00:00

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

Steps to reproduce:

Drag and drop multiple files to some file upload area in website. This issue first appears in Firefox 128.0.b1 and alive to now. In previous version (FF 127.0.2) this bug is not present.

1) go to https://www.dragdrop.com/test/ or any "cloud storage" site.
2) drag and drop more than one file to upload it to the site.
3) you see only one (first) file is uploaded.




Actual results:

Only one (first) file of set is uploaded.


Expected results:

All dragged files should be uploaded.
Bug: Intermittent browser/components/tests/browser/browser_browserGlue_upgradeDialog_trigger.js | single tracking bug
Status: RESOLVED
Priority: P5
Resolution: INCOMPLETE
Created: 2024-09-26 17:02:02+00:00
Resolved: 2024-10-21 12:07:35+00:00

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

---
```
TEST-PASS | browser/components/tests/browser/browser_browserGlue_upgradeDialog_trigger.js | Sanity check the temporary file doesn't exist. - true == true - 
[task 2024-09-26T12:57:02.313Z] 12:57:02     INFO - Entering setup bound 
[task 2024-09-26T12:57:02.313Z] 12:57:02     INFO - Leaving setup bound 
[task 2024-09-26T12:57:02.314Z] 12:57:02     INFO - Entering test bound not_major_upgrade
[task 2024-09-26T12:57:02.314Z] 12:57:02     INFO - Buffered messages finished
[task 2024-09-26T12:57:02.316Z] 12:57:02     INFO - TEST-UNEXPECTED-FAIL | browser/components/tests/browser/browser_browserGlue_upgradeDialog_trigger.js | Test timed out - 
[task 2024-09-26T12:57:02.316Z] 12:57:02     INFO - GECKO(1876) | Completed ShutdownLeaks collections in process 5304
[task 2024-09-26T12:57:02.317Z] 12:57:02     INFO - TEST-START | Shutdown
```
Bug: Firefox doesn't remember window height on Linux Wayland
Status: RESOLVED
Priority: --
Resolution: DUPLICATE
Created: 2024-09-26 17:51:30+00:00
Resolved: 2024-09-26 17:54:30+00:00

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

Steps to reproduce:

- use Firefox (deb package or Flatpak) on Linux with Wayland (Ubuntu/Gnome or Kubuntu/KDE)
- change the window size
- close Firefox
- reopen Firefox


Actual results:

Firefox always resets to the same (unwanted) height.


Expected results:

Firefox should remember the previous height of the window.
The bug happens with Firefox deb package and Firefox Flatpak, but it works as expected with Firefox Snap.
Bug: Vertical pinned tabs scrollable area is tab focusable
Status: VERIFIED
Priority: P1
Resolution: FIXED
Created: 2024-09-26 20:43:36+00:00
Resolved: 2025-02-11 04:23:40+00:00

When the vertical pinned tabs area is overflowing it is possible to focus the scrollable container (`#vertical-pinned-tabs-container`). This adds an extra tabstop that isn't very useful since the next tab will jump to whatever tab is selected so scrolling the container doesn't help with anything.

STR
1. Enable vertical tabs
2. With the sidebar collapsed pin 6 or more tabs
3. Focus the address bar (Cmd/Ctrl+L)
4. Tab, Tab, Tab (foc the vertical tabs area)

Expected results: Selected tab is focused
Actual results: The pinned tab container is focused

This should just need a `tabindex="-1"` to remove it from the tab order.
Bug: Resizing bookmark folder creates gap when moving bookmarks into nested folder
Status: NEW
Priority: P3
Created: 2024-09-26 22:03:21+00:00
Resolved: 2024-12-12 16:28:39+00:00

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

Steps to reproduce:

1. Enable Bookmarks Toolbar > Always Show
2. Create a bookmark folder on the toolbar
3. Inside that folder, create a nested folder with a reasonably short name
4. In the initial folder, add a bookmark with a very long name.
5. Drag the bookmark into the nested folder while hovering more to the right of the collider


Actual results:

The main folder shrinks, and the nested folder appears where it would've if the main folder hadn't shrunk- much farther to the right than it should've. 
Hovering over any other folder or bookmark in the main folder fixes this, but naturally this doesn't work if there are no other things in the folder.


Expected results:

The nested folder should've opened right next to the main folder, as it would if the main folder didn't shrink.
Bug: Space inbetween sidebar components doesn't allow clicking
Status: NEW
Priority: P3
Created: 2024-09-26 22:48:58+00:00
Resolved: 2024-09-30 14:43:18+00:00

STR:

1. Open up Sidebar
2. Go to "Tab from other Devices" or "History" tabs
3. Try to click the space between the text and delete/dismiss buttons

Expectation:
- Opens the history or tab 

Actual:
- Shows a click but nothing happens
Bug: With website appearance set to Dark, flickering happens when navigating to a website from about:blank
Status: RESOLVED
Priority: --
Resolution: INVALID
Created: 2024-09-27 11:27:46+00:00
Resolved: 2024-09-28 04:37:09+00:00

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

Steps to reproduce:

1) Set Firefox's "Website Appearance" setting (under Language and Appearance) to Dark.
2) Visit about:blank (appearance should be dark instead of white)
3) Navigate to another website


Actual results:

The contents of the about:blank page briefly changes to a brighter colour (ideally it shouldn't), then briefly becomes solid white (ideally it shouldn't) and then finally the website's contents/background are loaded.


Expected results:

Ideally the colour of about:blank should persist until the website's background is loaded.
Bug: [Unifed Ads API Integr] Update nimbus variables for spocs/tiles prefs
Status: RESOLVED
Priority: --
Resolution: FIXED
Created: 2024-09-27 16:35:28+00:00
Resolved: 2024-09-29 17:08:02+00:00

- Remove [unifiedAdsEnabled in Feature Manifest](https://searchfox.org/mozilla-central/source/toolkit/components/nimbus/FeatureManifest.yaml#802-820)
- Add two new entroes: 
  - `browser.newtabpage.activity-stream.unifiedAds.spocs.enabled`
  - `browser.newtabpage.activity-stream.unifiedAds.tiles.enabled`
Bug: Thumbs up/down buttons jump to a different location (no longer in bottom-right corner) after "Saved to Pocket" appears
Status: NEW
Priority: P3
Created: 2024-09-27 17:28:55+00:00
Resolved: 2024-11-19 03:07:26+00:00

STR:
1. Be signed in to Pocket (so that the pocket button can work, on new-tab suggested-story tiles)
2. Click the "Save" button on a new-tab suggested-story tile.
3. Hover that tile and compare the thumbs-up/down button locations, vs. another tile for a pocket story that you haven't saved.

ACTUAL RESULTS:
The thumbs-up/down buttons shift upwards, leaving the bottom-right corner (where they previously were) awkwardly empty.  (It seems that they're pushed up by the "Saved to Pocket" badge.)

EXPECTED RESULTS:
Thumbs-up/down buttons should remain in the same location at bottom-right corner; they look awkward in their shifted-upwards location.

If we don't want these buttons to be alongside the "Saved to pocket" badge, then I'd suggest we move "Saved to pocket" badge upwards, rather than the thumbs-up/down buttons.  The thumbs-up/down buttons are present on every tile (when hovered) so it looks a bit odd if they're in a different place on some tiles vs. others.
Bug: Sidebar no longer remembers which panel you had open
Status: NEW
Priority: P2
Created: 2024-09-27 19:28:09+00:00
Resolved: 2025-02-28 00:07:52+00:00

With the "Show and hide sidebar" setting, the selected sidebar panel needs to be reselected when you re-show/open the sidebar. My understanding is that this mode is supposed to more or less emulate the current sidebar button behavior. 

STR: 
- Set sidebar.revamp to true
- Open the history panel in the sidebar but clicking its icon in the narrow sidebar launcher
- Close the sidebar by clicking the sidebar button
- Re-open the sidebar by clicking the sidebar button

ER:
- The history panel would be opened

AR: 
- No panel is open, I need to click again on the history icon to open it.
Bug: Sidebar settings says "Show on left" in RTL when the sidebar is on the right and vice-versa
Status: RESOLVED
Priority: P2
Resolution: FIXED
Created: 2024-09-27 19:36:40+00:00
Resolved: 2025-02-03 15:16:48+00:00

Sidebar settings say "Show on left" in RTL when the sidebar is on the right and vice-versa. When the sidebar is in the "inline-start" position in RTL it is actually on the right of the window, and similarly if you move it to position end, it appears on the left. The labels in settings should reflect this. 

STR: 
- set `sidebar.revamp` preference to true. 
- use a RTL locale or set the `intl.l10n.pseudo` preference to `bidi`
- open the sidebar settings panel

ER: 
- The settings labels should reglect the actual position the sidebar will apear in if we are using explicit, positional terms like "left" and "right" 

AR: 
- The settings labels are effectively reversed, indicating the sidebar is on the left when its on the right, and right when its on the left.
Bug: Sidebar button has no label when moved to the overflow menu
Status: VERIFIED
Priority: P1
Resolution: FIXED
Created: 2024-09-27 19:38:24+00:00
Resolved: 2024-10-04 08:01:29+00:00

If you move the sidebar button to the overflow menu via the More tools > Customize toolbars UI, it only shows the icon and no label.
Bug: Prevent opt-in screen from pulling focus away from sidebar
Status: NEW
Priority: P2
Created: 2024-09-27 21:39:04+00:00
Resolved: 2025-02-21 16:08:13+00:00

After testing some WIP patches, I realized that displaying the integrated sidebar variant of the RC opt-in screen immediately applies keyboard focus on the opt-in button: https://searchfox.org/mozilla-central/rev/837f3a1ff2622c8303750c35d84bdc41a5cd079c/browser/components/aboutwelcome/actors/AboutWelcomeChild.sys.mjs#468.

I don't think this is something that we want UX and a11y-wise. We probably want to keep focus on the RC sidebar icon until a user feels ready to opt-in and willingly navigates to the CTA to enable RC.
Bug: Newtab spocs load is not properly checking isStartup anymore
Status: VERIFIED
Priority: --
Resolution: FIXED
Created: 2024-09-27 21:53:18+00:00
Resolved: 2024-10-14 12:09:37+00:00

Essentially we're now using startup cache way too often, which is impacting pacing, which can impact revenue and impressions.

Bug 1906989 started passing `startupCache` value in the place of `isStartup`, which should have been passing both with an `&&`.

Making too many requests hold cache for much much longer.
Bug: Fix close / X button for integrated Review Checker
Status: RESOLVED
Priority: P2
Resolution: FIXED
Created: 2024-09-27 22:39:59+00:00
Resolved: 2024-12-19 05:07:01+00:00

While integrated RC is still WIP, this is a reminder to verify the X button behaviour and ensure it closes the RC panel. At the moment, while the RC actors are not yet hooked up, pressing the X button nothing. We should also ensure that the vertical launcher is still visible after pressing X, even when hidden sidebar setting is true; inversely, pressing the sidebar toggle would close both the RC panel and the launcher.

Another option is to make use of the sidebar's optional X button instead, but doing so would force us to update the RC header and remove the Beta label from it.
Bug: High frequency Linux shippable browser/components/customizableui/test/browser_876926_customize_mode_wrapping.js | Widget save-page-button was moved using drag and should now be wrapped in palette in customizing when Gecko 132 merges to beta on 2024-09-30
Status: RESOLVED
Priority: --
Resolution: FIXED
Created: 2024-09-28 14:26:21+00:00
Resolved: 2024-10-02 01:00:23+00:00

[Central-as-beta-simulation](https://treeherder.mozilla.org/jobs?repo=try&group_state=expanded&resultStatus=success%2Ctestfailed%2Cbusted%2Cexception%2Cusercancel&revision=d8e7d02213e18f824441fbc95e26d45ecc10a2df&searchStr=linux%2C18.04%2Cx64%2Cwebrender%2Cshippable%2Copt%2Cmochitests%2Cwith%2Csoftware%2Cwebrender%2Cenabled%2Ctest-linux1804-64-shippable-qr%2Fopt-mochitest-browser-chrome-swr%2Cbc4&selectedTaskRun=W21ZGcGFRyGBfRKvO0ei7g.0)

[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=476122428&repo=try)

```
[task 2024-09-28T11:31:55.799Z] 11:31:55     INFO - TEST-PASS | browser/components/customizableui/test/browser_876926_customize_mode_wrapping.js | Should end in default state - 
[task 2024-09-28T11:31:55.799Z] 11:31:55     INFO - Buffered messages finished
[task 2024-09-28T11:31:55.803Z] 11:31:55     INFO - TEST-UNEXPECTED-FAIL | browser/components/customizableui/test/browser_876926_customize_mode_wrapping.js | Widget save-page-button was moved using drag and should now be wrapped in palette in customizing window. - Got "cui-mode-wrapping-some-panel-item", expected "save-page-button"
[task 2024-09-28T11:31:55.803Z] 11:31:55     INFO - Stack trace:
[task 2024-09-28T11:31:55.803Z] 11:31:55     INFO - chrome://mochikit/content/browser-test.js:test_is:1625
[task 2024-09-28T11:31:55.803Z] 11:31:55     INFO - chrome://mochitests/content/browser/browser/components/customizableui/test/browser_876926_customize_mode_wrapping.js:checkPalette:218
[task 2024-09-28T11:31:55.803Z] 11:31:55     INFO - chrome://mochitests/content/browser/browser/components/customizableui/test/browser_876926_customize_mode_wrapping.js:MoveWidgetsInTwoWindows:275
[task 2024-09-28T11:31:55.803Z] 11:31:55     INFO - chrome://mochikit/content/browser-test.js:handleTask:1145
[task 2024-09-28T11:31:55.803Z] 11:31:55     INFO - chrome://mochikit/content/browser-test.js:_runTaskBasedTest:1217
[task 2024-09-28T11:31:55.803Z] 11:31:55     INFO - chrome://mochikit/content/browser-test.js:Tester_execTest:1358
[task 2024-09-28T11:31:55.803Z] 11:31:55     INFO - chrome://mochikit/content/browser-test.js:nextTest/<:1134
[task 2024-09-28T11:31:55.803Z] 11:31:55     INFO - chrome://mochikit/content/tests/SimpleTest/SimpleTest.js:SimpleTest.waitForFocus/<:1058
[task 2024-09-28T11:31:55.803Z] 11:31:55     INFO - TEST-PASS | browser/components/customizableui/test/browser_876926_customize_mode_wrapping.js | There should be exactly 1 wrapper for save-page-button in the customizing window. - 
```
Bug: Sync never fully connects. "Account Disconnected"
Status: RESOLVED
Priority: --
Resolution: DUPLICATE
Created: 2024-09-28 23:15:48+00:00
Resolved: 2024-10-28 21:42:14+00:00

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

Steps to reproduce:

New install of windows
install firefox via winget (newest version of winget and firefox.) 
used the winget package Mozilla.Firefox
Attempted to sign into sync


Actual results:

Sync authenticates but never pulls down bookmarks, extensions, etc
The sync icon in the top right has an exclamation mark and it states "Account Disconnected"

----------------------------
Troubleshooting done:
reinstalled after deleting the following 

rm C:\Users\Drew\AppData\Local\Mozilla -Recurse -Force
rm C:\Users\Drew\AppData\Roaming\Mozilla -Recurse -Force
rm C:\ProgramData\Mozilla* -Recurse -Force

Registry:
Any mention of mozilla in HKCU:\Software
Any mention of mozilla in HKLM:\Software
Any mention of mozilla in HKLM:\Software\WOW6432Node

Same issue occurred. 

Also attempted to do the above but reinstalled v129.0. 





Expected results:

Firefox Sync stays connected and pulls down account information
Bug: mozjexl && and || operators don't short-circuit, causing the sticky clause to fail if there are errors in the rest of the targeting
Status: NEW
Priority: P2
Created: 2024-09-28 23:23:15+00:00
Resolved: 2024-10-14 17:14:55+00:00

There are more [details here](https://bugzilla.mozilla.org/show_bug.cgi?id=1920698#c4). We're having issues with the following targeting expression:

```
(browserSettings.update.channel == "release") && ((experiment.slug in activeExperiments) || (((!os.isWindows || os.windowsVersion < 10) || hasActiveEnterprisePolicies || isDefaultHandler.pdf || (defaultPDFHandler.registered && !defaultPDFHandler.knownBrowser)) && (version|versionCompare('131.!') >= 0) && (locale in ['de', 'en-CA', 'en-GB', 'en-US', 'fr', 'it'])))
```

Ignoring the release channel check, it basically has the pattern `stickyClause || mainTargeting`. So the sticky clause should be preventing evaluation of all the other stuff. But it seems not to, because the later clause `defaultPDFHandler.registered && !defaultPDFHandler.knownBrowser` throws a TypeError (bug 1920698). From Beth:

> The sticky clause should be preventing the defaultPDFHandler clause from ever being evaluated. I'm very confused about what is going on here.
>
> Unfortunately e don't really have the capability to answer these questions right now. Long term, we would want to build some amount of evaluation debugging into mozjexl.jsm that we can enable in cases like this. We've talked about it before in the scope of submitting telemetry about failed sub-expressions, but that is likely out of the question due to the targeting context including potentially sensitive data (and submitting information about the targeting evaluation would be category 3 or higher telemetry).
>
> In the near term, we can add some logging to mozjexl, compile it, and pull it into a build that we can hand off to someone that can reproduce this issue. I don't know if I have time to do that work, but I can definitely help guide someone towards how to do that work. This would also hopefully be a stepping stone to building a real solution into moxjexl that can provide detailed evaluation and context information.

So we think the first step in debugging why the sticky clause isn't working here would be to work with Beth on adding logging to [mozjexl](https://github.com/mozilla/mozjexl).
Bug: With "Bookmarks toolbar: only show on new tab", tab-switches to/from a new-tab cause the viewport-height to change (bug 1705215 has returned somewhat)
Status: REOPENED
Priority: P3
Created: 2024-09-29 09:58:14+00:00
Resolved: 2025-02-20 16:49:02+00:00

Steps to reproduce:
1. Navigate to about:config
2. Ensure the value of `browser.toolbars.bookmarks.visibility` is `newtab`
3. Navigate to attachment 9215907
4. Open a new tab
5. Switch back and forth between the new tab and the tab with attachment 9215907 loaded

Actual results:
The tab with attachment 9215907 loaded will log that it has been resized.

Expected results:
The tab with attachment 9215907 loaded will not log that it has been resized.

Regression range:
https://hg.mozilla.org/integration/autoland/pushloghtml?fromchange=b0132e48226f8caabc77d2850fd22e900120ffc4&tochange=308329f23acd5524dbb5b2a8179690a8bc60709f
Bug: firefox on GNU/Linu deep bookmark folders, deep folders inside "Open All Bookmarks" doesn't work, it's not even clickable
Status: NEW
Priority: P5
Created: 2024-09-29 13:21:59+00:00
Resolved: 2024-10-17 18:40:06+00:00

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

Steps to reproduce:

create a "bookmark folder" on "Bookmarks Toolbar", then inside that folder create another "bookmark folder", then inside that folder put some links or sites say about 4, now open those 4 links by opening the "outer folder" which will expose or be able to see the "inner folder" this "inner folder" has the 4 links or sites, right click the "inner folder" then click "Open All Bookmarks", this "Open All Bookmarks" doesn't work


Actual results:

it should open all 4 links but, it doesn't open, "Open All Bookmarks" is not even clickable


Expected results:

it should open all 4 links
Bug: Fullscreen url disappears when trying to click on url
Status: RESOLVED
Priority: --
Resolution: DUPLICATE
Created: 2024-09-30 00:43:15+00:00
Resolved: 2024-09-30 19:52:47+00:00

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

Steps to reproduce:

-> Make screen fullscreen in i3 (Mod + F)
-> Try to use url bar

See gif. It explains it 100x better than words can.


Actual results:

-> Thing keeps doing a bait and switch

It feels like that scene in the Simpsons where Homer is trying to catch a car but the car keeps driving off and stopping just out of range, but close enough that Homer keeps running after it. IDK if that's a cultural reference that people know.


Expected results:

The URL bar should be clickable.
Bug: [Linux] Crash at nsGNOMEShellHistorySearchResult::HandleSearchResultReply()
Status: RESOLVED
Priority: P3
Resolution: FIXED
Created: 2024-09-30 07:16:35+00:00
Resolved: 2024-10-07 19:36:05+00:00

Crash at nsGNOMEShellHistorySearchResult::HandleSearchResultReply(), after Bug 1634961 mHistResultContainer can be nullptr.
Bug: Secondary Actions Result buttons dropdown flickers after exiting Actions mode
Status: VERIFIED
Priority: P3
Resolution: FIXED
Created: 2024-09-30 09:14:53+00:00
Resolved: 2024-11-15 09:27:42+00:00

**Notes**
* Does not reproduce if closed via Escape key. 
* This is a follow-up from bug 1914604 .

**Found in**
* Nightly 132.0a1;

**Affected versions**
* Nightly 132.0a1;


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

**Preconditions**
* Have browser.urlbar.scotchBonnet.enableOverride set to true.

**Steps to reproduce**
1. Launch Firefox and open a new tab.
2. From the Dedicated Search Button click on the Actions button.
3. Exit Actions mode by clicking on the x(close) button.

**Expected result**
* Actions mode is closed, address bar returns to default state. 

**Actual result**
* Actions mode dropdown flickers before disappearing from the address bar. 


**Regression range**
* Not a regression.
Bug: Compute maxTabsPerRow dynamically based on sidebar width (dynamically determine maximum number of pinned tabs per row in expanded sidebar)
Status: RESOLVED
Priority: P1
Resolution: FIXED
Created: 2024-09-30 12:12:01+00:00
Resolved: 2024-10-09 10:03:13+00:00

Via https://phabricator.services.mozilla.com/D221078#inline-1232215 . Not 100% sure how this relates to bug 1921081.
Bug: Partially dragged tabs no longer smoothly reset their position
Status: VERIFIED
Priority: P1
Resolution: FIXED
Created: 2024-09-30 12:12:32+00:00
Resolved: 2024-10-24 11:28:40+00:00

Steps to reproduce:
1) Start dragging a tab horizontally 
2) Let go before you've dragged it enough to swap positions with another tab

Actual results:
Tab immediately snaps back to its original position

Expected results:
Tab smoothly transitions back to its original position