2024-03-28 19:10 UTC

View Revisions: Issue #2728

Summary 0002728: Error on closing windows in Choices/Configuration
Revision 2019-12-24 00:22 by Vincent Sanders
Description This error has been publicised in the ROOL fora (General, NetSurf Illegal Window Handle) and in the NS-users ML. It was first reported by Fred Bambrough, who unfortunately feels inadequately competent to report it here, so I'm quoting him.

"I started a thread on the RISC OS open Forum at

https://www.riscosopen.org/forum/forums/5/topics/14945?page=1#posts-97826

for more details. To sum;

On closing windows in NetSurf choices/configuration Iâ€−m seeing the error,
'An unexpected error occurred: Illegal window handle'. It only happens on
alternate config categories and on first look doesnâ€−t appear to do harm.

It's on RISC OS 5.27 (19-12-19) ROM, NetSurf 3.10(DEV CI #4956).

To summarise the thread, it's due to the latest version of RISC OS
improved reporting of errors, showing this one up. It's been confirmed by
others and is said to be related to changes in that ROM relating to
clipboard caret/task fixes.


NetSurf log extract;

(9.520000) frontends/riscos/wimp_event.c:1654
ro_gui_wimp_event_get_window: Creating structure for window 0x20481e39

(10.850000) frontends/riscos/dialog.c:378 ro_gui_dialog_close:
xwimp_set_caret_position: 0x288: Illegal window handle

(10.850000) frontends/riscos/gui.c:2112 ro_warn_user: WimpError Illegal
window handle

(10.850000) frontends/riscos/wimp_event.c:1112
ro_gui_wimp_event_close_window: Close event received for window 0x20481e39"

Indeed, looking at dialog.c, function ro_gui_dialog_close(), we appear to do:

persistent_dialog[i].parent = NULL; (in a loop for all persistent windows)

then later we do:

error = xwimp_set_caret_position(persistent_dialog[i].parent, ...)

so we're calling the function with the first parameter NULL. Now it just happens that RO has very recently had a change to SWI Wimp_SetCaretPosition which causes it to fault this call. The docs say it always should have done, but previously it didn't.

I do think it's odd that we call something that will cause an error, and then hope to clean up afterwards, rather than not causing an error in the first place.

I don't have enough of an overview to understand why the code is like it is; but would it make sense to invalidate the records after giving the caret back rather than before?
Revision 2019-12-20 22:50 by Dave Higton
Description This error has been publicised in the ROOL fora (General, NetSurf Illegal Window Handle) and in the NS-users ML. It was first reported by Fred Bambrough, who unfortunately feels inadequately competent to report it here, so I'm quoting him.

"I started a thread on the RISC OS open Forum at

https://www.riscosopen.org/forum/forums/5/topics/14945?page=1#posts-97826

for more details. To sum;

On closing windows in NetSurf choices/configuration Iâ€−m seeing the error,
'An unexpected error occurred: Illegal window handle'. It only happens on
alternate config categories and on first look doesnâ€−t appear to do harm.

It's on RISC OS 5.27 (19-12-19) ROM, NetSurf 3.10(DEV CI #4956).

To summarise the thread, it's due to the latest version of RISC OS
improved reporting of errors, showing this one up. It's been confirmed by
others and is said to be related to changes in that ROM relating to
clipboard caret/task fixes.


NetSurf log extract;

(9.520000) frontends/riscos/wimp_event.c:1654
ro_gui_wimp_event_get_window: Creating structure for window 0x20481e39

(10.850000) frontends/riscos/dialog.c:378 ro_gui_dialog_close:
xwimp_set_caret_position: 0x288: Illegal window handle

(10.850000) frontends/riscos/gui.c:2112 ro_warn_user: WimpError Illegal
window handle

(10.850000) frontends/riscos/wimp_event.c:1112
ro_gui_wimp_event_close_window: Close event received for window 0x20481e39"

Indeed, looking at dialog.c, function ro_gui_dialog_close(), we appear to do:

persistent_dialog[i].parent = NULL; (in a loop for all persistent windows)

then later we do:

error = xwimp_set_caret_position(persistent_dialog[i].parent, ...)

so we're calling the function with the first parameter NULL. Now it just happens that RO has very recently had a change to SWI Wimp_SetCaretPosition which causes it to fault this call. The docs say it always should have done, but previously it didn't.

I do think it's odd that we call something that will cause an error, and then hope to clean up afterwards, rather than not causing an error in the first place.

I don't have enough of an overview to understand why the code is like it is; but would it make sense to invalidate the records after giving the caret back rather than before?
Revision 2019-12-20 22:48 by Dave Higton
Description This error has been publicised in the ROOL fora (General, NetSurf Illegal Window Handle) and in the NS-users ML. It was first reported by Fred Bambrough, who unfortunately feels inadequately competent to report it here, so I'm quoting him.

"I started a thread on the RISC OS open Forum at

https://www.riscosopen.org/forum/forums/5/topics/14945?page=1#posts-97826

for more details. To sum;

On closing windows in NetSurf choices/configuration Iâ€−m seeing the error,
'An unexpected error occurred: Illegal window handle'. It only happens on
alternate config categories and on first look doesnâ€−t appear to do harm.

It's on RISC OS 5.27 (19-12-19) ROM, NetSurf 3.10(DEV CI #4956).

To summarise the thread, it's due to the latest version of RISC OS
improved reporting of errors, showing this one up. It's been confirmed by
others and is said to be related to changes in that ROM relating to
clipboard caret/task fixes.


NetSurf log extract;

(9.520000) frontends/riscos/wimp_event.c:1654
ro_gui_wimp_event_get_window: Creating structure for window 0x20481e39

(10.850000) frontends/riscos/dialog.c:378 ro_gui_dialog_close:
xwimp_set_caret_position: 0x288: Illegal window handle

(10.850000) frontends/riscos/gui.c:2112 ro_warn_user: WimpError Illegal
window handle

(10.850000) frontends/riscos/wimp_event.c:1112
ro_gui_wimp_event_close_window: Close event received for window 0x20481e39"

Indeed, looking at dialog.c, function ro_gui_dialog_close(), we appear to do:

persistent_dialog[i].parent = NULL; (in a loop for all persistent windows)

then later we do:

error = xwimp_set_caret_position(persistent_dialog[i].parent, ...)

so we're calling the function with the first parameter NULL. Now it just happens that RO has had a change to SWI Wimp_SetCaretPosition which causes it to fault this call. The docs say it always should have done, but previousl it didn't.

I do think it's odd that we call something that will cause an error, and then hope to clean up afterwards, rather than not causing an error in the first place.

I don't have enough of an overview to understand why the code is like it is; but would it make sense to invalidate the records after giving the caret back rather than before?