Bug #8809
Incorrect next enabled widget calculation
100%
Related issues
History
#1 Updated by Vladimir Tsichevski about 1 month ago
- File 8809.p
added
- File functions.i added
- File printEntryLeave.i added
Run the 8809.p
example.
In OE, the focusable7
button receives focus.
In FWD no focus is set.
The issue origin is in the FWD Frame.getNextEnabledWidget(Widget<O> widget, boolean wrap)
method, which is supposed to find a TAB-STOP
field, which follow the given TAB-STOP
field in the window tab ring.
This method first searches the frame own widgets, then if no matching widget found, continues with the next frame sibling and so on.
But this search in the next frame sibling does not happen in these cases:
- the frame has no widgets:
if (widgets == null) { return null; }
- the method argument widget is the last frame widget:
if (nref == size) { return null; }
which is incorrect for both cases.
#2 Updated by Vladimir Tsichevski about 1 month ago
- Related to Bug #8673: Deduce the logic behind OE focus management and implement in FWD added
#3 Updated by Vladimir Tsichevski about 1 month ago
- % Done changed from 0 to 100
- Status changed from New to WIP
Fixed in 8809a rev. 15240. Please, review.
#4 Updated by Vladimir Tsichevski about 1 month ago
- Status changed from WIP to Review
#5 Updated by Vladimir Tsichevski about 1 month ago
The (incomplete) fix for #8770 reverted in 8809a in rev. 15241.
#6 Updated by Greg Shah about 1 month ago
Hynek: Please review.
#7 Updated by Hynek Cihlar about 1 month ago
- Status changed from Review to Internal Test
Code review 8809a. The changes look good, but it will require good amount of regression testing, including ChUI regression tests.
#8 Updated by Vladimir Tsichevski 6 days ago
Hynek Cihlar wrote:
Code review 8809a. The changes look good, but it will require good amount of regression testing, including ChUI regression tests.
I have trouble deciding which FWD branch to use for ChUI testing, since the 6667i is currently far behind trunk.
#10 Updated by Vladimir Tsichevski 5 days ago
Greg Shah wrote:
6667g is based on a recent trunk.
6667g is based on trunk rev. 15270 of 2024-06-05, while the current trunk is 15310.
#11 Updated by Vladimir Tsichevski 4 days ago
Hynek Cihlar wrote:
Code review 8809a. The changes look good, but it will require good amount of regression testing, including ChUI regression tests.
Testing with ChUI suite succeeded (the 6667g was used as the base).
#13 Updated by Vladimir Tsichevski 4 days ago
Greg Shah wrote:
Have you tested this with a customer's large GUI application?
I will do smoke test only. I do not know about any issues in a customer's large GUI application related to this issue problem.
#15 Updated by Vladimir Tsichevski 1 day ago
Greg Shah wrote:
I'm more concerned with trying various scenarios to see if there is any breakage.
I spend a few minutes opening various screens in the big application, and I saw no problems.
#16 Updated by Hynek Cihlar 1 day ago
- Status changed from Internal Test to Merge Pending
Vladimir Tsichevski wrote:
Greg Shah wrote:
I'm more concerned with trying various scenarios to see if there is any breakage.
I spend a few minutes opening various screens in the big application, and I saw no problems.
Since the ChUI tests also passed (they contain a lot of tabbing sensitive code) I would consider the regression testing passed.
#18 Updated by Vladimir Tsichevski 1 day ago
Greg Shah wrote:
You can merge to trunk now.
Done. Trunk rev. 15314.