2025-05-13 00:12 BST
  

View Issue Details [ Jump to Notes ] [ Issue History ] [ Print ]
IDProjectCategoryView StatusDate SubmittedLast Update
0002728NetSurfRISC OS-specificpublic2019-12-20 22:482020-05-27 09:00
ReporterDave Higton 
Assigned ToJohn-Mark Bell 
SeveritymajorReproducibilityalways 
StatusclosedResolutionopen 
PlatformOSRISC OSOS Version5.27 (2019-12-19)
Product Version 
Target Version3.10Fixed in Version3.10 
Summary0002728: Error on closing windows in Choices/Configuration
DescriptionThis 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?
TagsNo tags attached.
Fixed in CI build #4960
Reported in CI build #4956
URL of problem page
Attached Files

-Relationships
+Relationships

-Notes
Dave Higton

~0002155

Dave Higton (developer)

2019-12-23 21:31

 This has been reported by two people in the ROOL fora as fixed in version 4960.
Vincent Sanders

~0002212

Vincent Sanders (administrator)

2020-05-27 09:00

 Thankyou for reporting this issue.
We believe this is fixed in the 3.10 release.
If this is not the case please feel free to reopen the issue with additional details.
+Notes

-Issue History
Date Modified Username Field Change
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
2020-05-23 09:49 Vincent Sanders Target Version => 3.10
2020-05-27 09:00 Vincent Sanders Status resolved => closed
2020-05-27 09:00 Vincent Sanders Note Added: 0002212
+Issue History