This repository has been archived by the owner on Dec 11, 2019. It is now read-only.
Dragging a tab to blank tab bar area results in lost tab #14046
Assignees
Labels
bug
duplicate
Issue has already been reported
feature/tabsbar
QA/checked-Linux
QA/checked-macOS
QA/test-plan-specified
Comments
petemill
added a commit
that referenced
this issue
May 7, 2018
Fix #14046 Avoid a tab being moved to a new window with a frame index higher than it should have. This occurred because when dropping on the blank area of a tab strip, there is no tab being dragged over. The last tab being dragged over could have been in another window, or could be the dragged tab itself, causing a frame to be created in the new window with an index that is too high, corrupting the "frame index <-> tabId" cache. Instead, we insert the tab at the beginning, and rely on muon to provide an updated tab index (if provided with an index of -1, muon will add the tab to the end of the strip).
|
Should be fixed with next release |
petemill
added a commit
that referenced
this issue
May 8, 2018
Fix #14046 Avoid a tab being moved to a new window with a frame index higher than it should have. This occurred because when dropping on the blank area of a tab strip, there is no tab being dragged over. The last tab being dragged over could have been in another window, or could be the dragged tab itself, causing a frame to be created in the new window with an index that is too high, corrupting the "frame index <-> tabId" cache. Instead, we insert the tab at the beginning, and rely on muon to provide an updated tab index (if provided with an index of -1, muon will add the tab to the end of the strip).
This was referenced May 8, 2018
petemill
added a commit
that referenced
this issue
May 8, 2018
Fix #14046 Avoid a tab being moved to a new window with a frame index higher than it should have. This occurred because when dropping on the blank area of a tab strip, there is no tab being dragged over. The last tab being dragged over could have been in another window, or could be the dragged tab itself, causing a frame to be created in the new window with an index that is too high, corrupting the "frame index <-> tabId" cache. Instead, we insert the tab at the beginning, and rely on muon to provide an updated tab index (if provided with an index of -1, muon will add the tab to the end of the strip).
petemill
added a commit
that referenced
this issue
May 9, 2018
Fix #14046 Avoid a tab being moved to a new window with a frame index higher than it should have. This occurred because when dropping on the blank area of a tab strip, there is no tab being dragged over. The last tab being dragged over could have been in another window, or could be the dragged tab itself, causing a frame to be created in the new window with an index that is too high, corrupting the "frame index <-> tabId" cache. Instead, we insert the tab at the beginning, and rely on muon to provide an updated tab index (if provided with an index of -1, muon will add the tab to the end of the strip).
petemill
added a commit
that referenced
this issue
May 10, 2018
Fix #14046 Avoid a tab being moved to a new window with a frame index higher than it should have. This occurred because when dropping on the blank area of a tab strip, there is no tab being dragged over. The last tab being dragged over could have been in another window, or could be the dragged tab itself, causing a frame to be created in the new window with an index that is too high, corrupting the "frame index <-> tabId" cache. Instead, we insert the tab at the beginning, and rely on muon to provide an updated tab index (if provided with an index of -1, muon will add the tab to the end of the strip).
petemill
added a commit
that referenced
this issue
May 10, 2018
Fix #14046 Avoid a tab being moved to a new window with a frame index higher than it should have. This occurred because when dropping on the blank area of a tab strip, there is no tab being dragged over. The last tab being dragged over could have been in another window, or could be the dragged tab itself, causing a frame to be created in the new window with an index that is too high, corrupting the "frame index <-> tabId" cache. Instead, we insert the tab at the beginning, and rely on muon to provide an updated tab index (if provided with an index of -1, muon will add the tab to the end of the strip).
petemill
added a commit
that referenced
this issue
May 10, 2018
Fix #14046 Avoid a tab being moved to a new window with a frame index higher than it should have. This occurred because when dropping on the blank area of a tab strip, there is no tab being dragged over. The last tab being dragged over could have been in another window, or could be the dragged tab itself, causing a frame to be created in the new window with an index that is too high, corrupting the "frame index <-> tabId" cache. Instead, we insert the tab at the beginning, and rely on muon to provide an updated tab index (if provided with an index of -1, muon will add the tab to the end of the strip).
This was referenced May 10, 2018
petemill
added a commit
that referenced
this issue
May 11, 2018
Fix #14046 Avoid a tab being moved to a new window with a frame index higher than it should have. This occurred because when dropping on the blank area of a tab strip, there is no tab being dragged over. The last tab being dragged over could have been in another window, or could be the dragged tab itself, causing a frame to be created in the new window with an index that is too high, corrupting the "frame index <-> tabId" cache. Instead, we insert the tab at the beginning, and rely on muon to provide an updated tab index (if provided with an index of -1, muon will add the tab to the end of the strip).
petemill
added a commit
that referenced
this issue
May 11, 2018
Fix #14046 Avoid a tab being moved to a new window with a frame index higher than it should have. This occurred because when dropping on the blank area of a tab strip, there is no tab being dragged over. The last tab being dragged over could have been in another window, or could be the dragged tab itself, causing a frame to be created in the new window with an index that is too high, corrupting the "frame index <-> tabId" cache. Instead, we insert the tab at the beginning, and rely on muon to provide an updated tab index (if provided with an index of -1, muon will add the tab to the end of the strip).
|
@petemill dragging tab into empty space in tabs bar causes it to open up as a new window. Below is the recording
However this is not the same behaviour on macOS. Is the fix only for mac or for all platforms? |
|
On macOS the tab dragged to the empty area of the tabs bar is added to the window: |
|
Verified with macOS 10.12.6 using
|
|
Still an issue on windows. Doesn't drop on the empty space in tabsbar after the new tab sign. |
|
Tab only drops before the new tab button resizing the last existing tab or if its dropped in between two tabs it resizes the right tab and then drops in. |
|
Closing in favour of #14099 which is windows specific issue |
|
Removing milestone since this appears to be a duplicate of #14099 |
Sign up for free
to subscribe to this conversation on GitHub.
Already have an account?
Sign in.
Description
Steps to Reproduce ONE
Actual result:
Tab never shows up
Expected result:
Tab shows up at end of tab set
Reproduces how often:
100%
Brave Version
about:brave info:
Reproducible on current live release:
Probably but possibly different (similarly broken) results.
The text was updated successfully, but these errors were encountered: