Restore focus on parent tab when closing child tab
Affects | Status | Importance | Assigned to | Milestone | |
---|---|---|---|---|---|
webbrowser-app (Ubuntu) |
In Progress
|
Medium
|
Florian Boucault |
Bug Description
(follow-up to https:/
In chromium on desktop, when opening a link in a new tab (for instance when Ctrl+clicking on a hyperlink), the new tab is open next to the parent tab. When closing that child tab, the parent tab is the one that becomes current.
In webbrowser-app, when closing the child tab, the next one in the list becomes current. It would be nice if webbrowser-app implemented the same behaviour as chromium.
Steps to reproduce:
1) Start webbrowser-app, and open two tabs, e.g. http://
2) Focus the first tab (example.org) and right click on the "More information…" link (this opens a new tab in second position and focuses it
3) Press Ctrl+W to close the current tab
Expected result: the first tab (example.org) is the one that gets focused.
Actual result: the second tab (start.ubuntu.com) is the one that gets focused.
Related branches
- Olivier Tilloy: Needs Fixing
-
Diff: 388 lines (+140/-58)11 files modifiedsrc/app/webbrowser/Browser.qml (+12/-2)
src/app/webbrowser/BrowserTab.qml (+1/-0)
src/app/webbrowser/TabComponent.qml (+10/-5)
src/app/webbrowser/tabs-model.cpp (+16/-0)
src/app/webbrowser/tabs-model.h (+1/-0)
tests/autopilot/webbrowser_app/tests/__init__.py (+10/-0)
tests/autopilot/webbrowser_app/tests/http_server.py (+6/-0)
tests/autopilot/webbrowser_app/tests/test_new_tab_view.py (+5/-34)
tests/autopilot/webbrowser_app/tests/test_site_previews.py (+0/-9)
tests/autopilot/webbrowser_app/tests/test_tabs.py (+65/-8)
tests/unittests/tabs-model/tst_TabsModelTests.cpp (+14/-0)
Changed in webbrowser-app (Ubuntu): | |
assignee: | nobody → Florian Boucault (fboucault) |
importance: | Undecided → Medium |
status: | New → Triaged |
Changed in webbrowser-app (Ubuntu): | |
status: | Triaged → In Progress |
I looked into chromium’s implementation, and it’s a bit more complex than what I described in the description. Details are in TabStripModelOr derController: :DetermineNewSe lectedIndex( …)¹.
I think it would be worth identifying what in chromium’s implementation we want to replicate.
One thing that wasn’t reported as part of this bug is that when opening background tabs from a given page, they should be placed to the right of the opener, in sequence (i.e. if I open B, C and D as background tabs from A, the order of the tabs should be A-B-C-D, not A-D-C-B as it is currently). This should probably be implemented as part of this bug.
¹ https:/ /cs.chromium. org/chromium/ src/chrome/ browser/ ui/tabs/ tab_strip_ model_order_ controller. cc?l=52