Tab strip displays the "Open in a new tab" animation outside the browser window in Arabic builds
Categories
(Firefox :: Tabbed Browser, defect, P2)
Tracking
()
People
(Reporter: vlucaci, Assigned: kpatenio)
References
(Blocks 2 open bugs)
Details
(Whiteboard: [fidefe-2022-mr1-firefox-view])
Attachments
(2 files, 1 obsolete file)
Affected versions
- 106.0a1
Tested platforms
- Affected platforms: macOS12 , Windows 10, Win11
- Unaffected platforms: Ubuntu 22
Steps to reproduce
- Launch FF (Arabic build)
- Open multiple tabs
- Open wikipedia.org
- Click the Firefox View button
- Go back to wikipedia page
- Select any link from the wikipedia homepage and drag it to the tab strip
Expected result
- The tab strip displays the animation for a new opened tab at the end of the tab carousel.
Actual result
- The tab strip displays the animation for a new opened tab outside the browser window.
Additional notes
- This issue occurs in the Arabic build.
- This issue does not happen if the user removes the Firefox View button from the tab strip (via Customize or by disabling the FF View pref)
- This issue does not occur for Ubuntu 22.
- This issue occurs in the latest 105.0b9 beta build as well (if activating the FF View pref)
Updated•2 years ago
|
Comment 1•2 years ago
|
||
(In reply to Vlad Lucaci, QA (:vlucaci) from comment #0)
- This issue does not happen if the user removes the Firefox View button from the tab strip (via Customize or by disabling the FF View pref)
Does this issue also happen if you remove the fxview button and replace it with a different toolbar button?
Reporter | ||
Comment 2•2 years ago
|
||
(In reply to :Gijs (he/him) from comment #1)
(In reply to Vlad Lucaci, QA (:vlucaci) from comment #0)
- This issue does not happen if the user removes the Firefox View button from the tab strip (via Customize or by disabling the FF View pref)
Does this issue also happen if you remove the fxview button and replace it with a different toolbar button?
I am only able to reproduce this behaviour when the Firefox View button is placed in its default location.
I have tried with several different toolbar buttons (Forget, Print, Screenshot, History, Synced tabs) and was unable to reproduce it.
Updated•2 years ago
|
Some initial observations while looking into this bug and playing around with dragging a new tab to the "end" (very left for RTL, or very right for LTR):
When we drag and drop a brand new tab, we determine the index position for the drop indicator to ensure it appears in the correct position and then move the indicator accordingly. _getDragTargetTab I think returns null if we are adding a tab to the very end. When reading all tabs though (this.addTabs
), the hidden Firefox View tab is included despite not being visible. This affects how we calculate the index position of the indicator.
-
When using a LTR build, the if condition is never satisfied and we return the number of tabs instead.
-
When using a RTL build however, the condition is satisfied and we return the index position of a tab (the hidden Firefox View tab), causing us to go to the else statement here and reading an invalid
tabRect
(all dimensions will be 0).
As a result, we end up positioning the drop indicator at the end of the tab strip before negating it; the indicator is then moved too far left.
Comment 4•2 years ago
|
||
(In reply to kpatenio from comment #3)
- When using a RTL build however, the condition is satisfied and we return the index position of a tab (the hidden Firefox View tab), causing us to go to the else statement here and reading an invalid
tabRect
(all dimensions will be 0).
Good find! We should use this._getVisibleTabs()
instead of this.allTabs
throughout that code.
Updated•2 years ago
|
Comment 7•2 years ago
|
||
Comment on attachment 9297661 [details]
WIP: Bug 1789978: add test for drop and drag fix for RTL builds after opening FxView tab
Revision D158888 was moved to bug 1794624. Setting attachment 9297661 [details] to obsolete.
Updated•2 years ago
|
Comment 9•2 years ago
|
||
bugherder |
Comment 10•2 years ago
|
||
The patch landed in nightly and beta is affected.
:kpatenio, is this bug important enough to require an uplift?
- If yes, please nominate the patch for beta approval.
- If no, please set
status-firefox106
towontfix
.
For more information, please visit auto_nag documentation.
Updated•2 years ago
|
Updated•2 years ago
|
Comment 11•2 years ago
|
||
I managed to reproduce this issue on a 2022-10-10 Nightly ar-locale build on macOS 12 using the STR from the Description. Verified as fixed on Firefox 107.0b2 ar-locale(build ID: 20221020202724) and Nightly 108.0a1 ar-locale(build ID: 20221020215126) on macOS 12, Windows 10, Windows 11.
Description
•