Closed Bug 1789978 Opened 2 years ago Closed 2 years ago

Tab strip displays the "Open in a new tab" animation outside the browser window in Arabic builds

Categories

(Firefox :: Tabbed Browser, defect, P2)

Firefox 106
Desktop
All
defect
Points:
3

Tracking

()

VERIFIED FIXED
107 Branch
Tracking Status
firefox106 --- wontfix
firefox107 --- verified

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

  1. Launch FF (Arabic build)
  2. Open multiple tabs
  3. Open wikipedia.org
  4. Click the Firefox View button
  5. Go back to wikipedia page
  6. 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)

(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?

Component: Firefox View → Tabbed Browser
Flags: needinfo?(vlad.lucaci)

(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.

Flags: needinfo?(vlad.lucaci)
Priority: -- → P2
Assignee: nobody → kpatenio
Status: NEW → ASSIGNED

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.

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.

(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.

Points: --- → 3
Attachment #9295622 - Attachment description: Bug 1789978: fix drop indicator position for RTL builds after opening Firefox View. r=dao! → WIP: Bug 1789978: fix drop indicator position for RTL builds after opening Firefox View. r=dao!
Depends on: 1794624

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.

Attachment #9297661 - Attachment is obsolete: true
Attachment #9295622 - Attachment description: WIP: Bug 1789978: fix drop indicator position for RTL builds after opening Firefox View. r=dao! → Bug 1789978: fix drop indicator position for RTL builds after opening Firefox View. r=dao!
Pushed by kpatenio@mozilla.com:
https://hg.mozilla.org/integration/autoland/rev/9d5fcce2f05c
fix drop indicator position for RTL builds after opening Firefox View. r=dao
Status: ASSIGNED → RESOLVED
Closed: 2 years ago
Resolution: --- → FIXED
Target Milestone: --- → 107 Branch

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 to wontfix.

For more information, please visit auto_nag documentation.

Flags: needinfo?(kpatenio)
Flags: needinfo?(kpatenio)
Flags: qe-verify+

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.

Status: RESOLVED → VERIFIED
Flags: qe-verify+
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Created:
Updated:
Size: