Bug #13956
openWPopupMenu not visible if popped up at itemWidget of (a narrow) WTableView with vertical scrollbar
0%
Description
WPopuMenu::popup(WWidget *location, orientation = Orientation::Vertical) seems to reparent the menu to some layout container if the WTableView has a vertical scrollbar.
This just results in the horizontal scrollbar becoming added and the popup menu being invisible until that scrollbar is moved. Unacceptable UX.
(If the WTableView does not have a vertical scrollbar, the menu uses the full height of the screen, i.e. is not restricted to and hidden in a container. Good.)
CSS path without vscrollbar: html.Wt-layout body.Wt-layout.Wt-ltr div#ojansmv.Wt-domRoot ul#ojaovc7.Wt-popup.DevSwitching.dropdown-menu.wt-reparented
CSS path with vscrollbar: html.Wt-layout body.Wt-layout.Wt-ltr div#ojansmv.Wt-domRoot div#ojansmx div#ojansnz.SystemSummary div#ojanso0.Wt-stack div#ojaothf div#ojaovbc.Wt-itemview.Wt-tableview.DevSwitching.wt-fixedc1.unselectable div#ojaovbw div#ojaovbn.tcontainer ul#ojaovc7.Wt-popup.DevSwitching.dropdown-menu.wt-reparented
Files
MS Updated by Michael Seibt 7 months ago
High: Still reproducible with Wt 4.12.2 (and former versions, checked down to 4.11.4).
STR:
- run attached
main.cppwithreload-is-new-session = false - open http://127.0.0.1:8080
- click "Popup menu"
--> WPopupMenu is not visible without scrolling. Just cell "42,1" is selected and the horizontal scrollbar of the left WTableView gets longer.
Popping up the menu with Orientation::Vertical (tick the checkbox) does not make it better - particularly if row 42 was not visible.
Then the context menu pops up above the - now top-visible - cell.
The layout gets totally messed up by
- reloading the page (worse than before with Wt 4.12.2)
- adding many menu items (button "Add many context menu items")
Most of this issues will be resolved if the context menu is not popped up inside that container - as it is done for the right WTableView (with less rows) if it has no scrollbar.
MS Updated by Michael Seibt 6 months ago
Thank you for fixing many layout issues in 4.12.6!
But this important one is still reproducible.
RM Updated by Romain Mardulyn 6 months ago
- Status changed from New to InProgress
- Assignee set to Romain Mardulyn
RM Updated by Romain Mardulyn 4 months ago
- Related to Feature #14494: Use css anchor for WWidget::positionAt() added
RM Updated by Romain Mardulyn 4 months ago
- Status changed from InProgress to New
RM Updated by Romain Mardulyn 4 months ago
- Assignee deleted (
Romain Mardulyn)
RM Updated by Romain Mardulyn 27 days ago
- Target version set to 4.15.0
This is an annoying one because we cannot simply change the way it behaves as explained as explained in Issue #14494. Wt uses position-anchor to solve that issue since version 4.14.0, but only for newer browser as that is a recent functionality.
I don't think there is a good way to solve it for browsers that do not yet support position-anchor. So instead, I think we should add an option that, when enabled, forces the popup to be reparented to the top container when position-anchor is not supported. This would ensure it is visible, but at the cost of potentially not following the widget it was positioned at.
MS Updated by Michael Seibt 26 days ago
Thank you for the fixes in 4.14.0 and for the hint that it depends on the browser version. Indeed, the company-managed version is too old.
It works well with an up-to-date, portable Firefox (and Edge).
As my company does not need to support older browsers, I consider this positioning issue resolved.