|View Issue Details|
|ID||Project||Category||View Status||Date Submitted||Last Update|
|0002728||NetSurf||RISC OS-specific||public||2019-12-20 22:48||2019-12-24 00:22|
|Assigned To||John-Mark Bell|
|Platform||OS||RISC OS||OS Version||5.27 (2019-12-19)|
|Target Version||Fixed in Version||3.10|
|Summary||0002728: Error on closing windows in Choices/Configuration|
|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
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;
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
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?
|Tags||No tags attached.|
|Fixed in CI build #||4960|
|Reported in CI build #||4956|
|URL of problem page|
Dave Higton (developer)
|This has been reported by two people in the ROOL fora as fixed in version 4960.|
|2019-12-20 22:48||Dave Higton||New Issue|
|2019-12-20 22:50||Dave Higton||Description Updated||View Revisions|
|2019-12-23 21:31||Dave Higton||Status||new => resolved|
|2019-12-23 21:31||Dave Higton||Note Added: 0002155|
|2019-12-24 00:22||Vincent Sanders||Assigned To||=> John-Mark Bell|
|2019-12-24 00:22||Vincent Sanders||Fixed in Version||=> 3.10|
|2019-12-24 00:22||Vincent Sanders||Description Updated||View Revisions|
|2019-12-24 00:22||Vincent Sanders||Fixed in CI build #||=> 4960|