Project

General

Profile

Actions

Bug #14473

open

WDialog positioned aside widget incompletely handles focus

Added by Michael Seibt 4 months ago. Updated 2 days ago.

Status:
New
Priority:
High
Assignee:
-
Target version:
-
Start date:
04/15/2026
Due date:
% Done:

0%

Estimated time:

Description

Affected: WDialog::positionAt(WWidget*, Orientation) of Wt 4.13.0 (and former versions, checked down to 4.11.4)
Keyboard events still go to the main application (to both the global handlers and to the previously focused widget)
As long as the dialog is popped up using WDialog::positionAt(const WMouseEvent&), it works well - but only until WDialog::positionAt(WWidget*, Orientation).
A WFormWidget like WLineEdit can always be focused and used. But keyboard input does not invoke the connected handlers.


Files

main.cpp (10.9 KB) main.cpp Michael Seibt, 04/16/2026 09:12 AM

Related issues 1 (0 open1 closed)

Related to Feature #14494: Use css anchor for WWidget::positionAt()ClosedRomain Mardulyn04/27/2026

Actions
Actions #1

Updated by Michael Seibt 4 months ago

"But keyboard input does not invoke the connected handlers."

Correction: This last statement was incorrect. Actually, two widgets receive the keyboard events.

STR:

  • run attached main.cpp
  • hold Ctrl and right click into a table cell of the first WTableView --> A WDialog pops up at the mouse position as intended.
  • press Escape --> "ed.keyWentDown 27 focused" is traced and popup is closed as intended.
  • press Space --> A WDialog pops up below the cell as intended.
  • press Escape --> "ed.keyWentDown 27 focused" is traced and popup is closed as intended. But also "tv.keyWentDown 27" is traced. Wrong.
  • hold Ctrl and right click into a table cell --> A WDialog pops up at the mouse position as intended.
  • press keys --> Each time both "ed.keyWentDown focused" and "tv.keyWentDown " is traced. Broken. Does not recover.
Actions #2

Updated by Romain Mardulyn 4 months ago

  • Related to Feature #14494: Use css anchor for WWidget::positionAt() added
Actions #3

Updated by Michael Seibt 2 days ago

The initial STR do not reproduce the bug with Wt 4.14.0/1 in an up-to-date Firefox.

new STR (a):

  • right click into a table cell
  • right click again into any table cell (without closing the popup before)

new STR (b):

  • left click a table cell
  • hit Space
  • left click again into any table cell (without closing the popup before)
  • hit Space

workaround: call setFirstFocus after both WDialog::positionAt overloads
(works despite Bug #14730: WDialog::setFirstFocus ignores footer and does not focus the WDialog as fallback for this main.cpp, but not completely in a more complex application)

Actions

Also available in: Atom PDF