Skip to content
This repository has been archived by the owner on Dec 11, 2019. It is now read-only.

Creating new tab moves to first tab page and back again #14101

Closed
petemill opened this issue May 11, 2018 · 1 comment · Fixed by #14102
Closed

Creating new tab moves to first tab page and back again #14101

petemill opened this issue May 11, 2018 · 1 comment · Fixed by #14102

Comments

@petemill
Copy link
Member

petemill commented May 11, 2018

Reported by @alexwykoff

Description

When a new tab is added, the tab page briefly switches to the first one, and then back again the last one. This is because the tab is first created without an index, and put at the beginning, and then moved by muon to the last tab index.

Test plan / Steps to Reproduce

  1. Have multiple tab pages open and the last tab page active, with an active tab in that page
  2. Open a new tab (keyboard shortcut or new tab button

Actual result:
Tab is opened in the correct tab page but tab page switches to the first tab page and then quickly back again.

Expected result:
Tab page does not change

Reproduces how often:
100%

Brave Version

about:brave info:
0.22.709

Reproducible on current live release:
No

Additional Information

@petemill petemill added regression feature/tab-page 0.22.x-single-webview Issue first seen on single-webview build against v0.22.x branch labels May 11, 2018
@petemill petemill added this to the 0.22.x Release 3 (Beta channel) milestone May 11, 2018
@petemill petemill self-assigned this May 11, 2018
petemill added a commit that referenced this issue May 11, 2018
…he frame list

Fix #14101
Whilst we do not display a tab until it has received tab-inserted-at and therefore has an index, we do switch the active Tab Page to the index of the new tab (if it is active), which would be the index of the tab page at tab index 0.

A better fix would be to not add the frame to the window state until tab-inserted-at has been received. This could also help performance, especially if batched.
petemill added a commit that referenced this issue May 11, 2018
…he frame list

Fix #14101
Whilst we do not display a tab until it has received tab-inserted-at and therefore has an index, we do switch the active Tab Page to the index of the new tab (if it is active), which would be the index of the tab page at tab index 0.

A better fix would be to not add the frame to the window state until tab-inserted-at has been received. This could also help performance, especially if batched.
petemill added a commit that referenced this issue May 12, 2018
…he frame list

Fix #14101
Whilst we do not display a tab until it has received tab-inserted-at and therefore has an index, we do switch the active Tab Page to the index of the new tab (if it is active), which would be the index of the tab page at tab index 0.

A better fix would be to not add the frame to the window state until tab-inserted-at has been received. This could also help performance, especially if batched.
@LaurenWags
Copy link
Member

LaurenWags commented May 15, 2018

Verified with macOS 10.12.6 using

  • 0.22.712 e48c5ff
  • muon 6.0.9
  • libchromiumcontent 66.0.3359.139

Verified on Ubuntu 17.10 x64

  • 0.22.713 fd036ae
  • libchromiumcontent 66.0.3359.139
  • muon: 6.0.9

Verified on Windows x64

  • 0.22.713 fd036ae
  • libchromiumcontent 66.0.3359.139
  • muon: 6.0.9

Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.