MantisBT - NetSurf
View Issue Details
IDProjectCategoryView StatusDate SubmittedLast Update
0002728NetSurfRISC OS-specificpublic2019-12-20 22:482020-05-27 09:00
ReporterDave Higton 
Assigned ToJohn-Mark Bell 
PrioritynormalSeveritymajorReproducibilityalways
StatusclosedResolutionopen 
PlatformOSRISC OSOS Version5.27 (2019-12-19)
Product Version 
Target Version3.10Fixed in Version3.10 
Fixed in CI build #4960
Reported in CI build #4956
URL of problem page
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.
Relationships
Attached Files

Notes
(0002155)
Dave Higton   
2019-12-23 21:31   
This has been reported by two people in the ROOL fora as fixed in version 4960.
(0002212)
Vincent Sanders   
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.

Issue History
Date ModifiedUsernameFieldChange
2019-12-20 22:48Dave HigtonNew Issue
2019-12-20 22:50Dave HigtonDescription Updatedbug_revision_view_page.php?rev_id=2162#r2162
2019-12-23 21:31Dave HigtonStatusnew => resolved
2019-12-23 21:31Dave HigtonNote Added: 0002155
2019-12-24 00:22Vincent SandersAssigned To => John-Mark Bell
2019-12-24 00:22Vincent SandersFixed in Version => 3.10
2019-12-24 00:22Vincent SandersDescription Updatedbug_revision_view_page.php?rev_id=2163#r2163
2019-12-24 00:22Vincent SandersFixed in CI build # => 4960
2020-05-23 09:49Vincent SandersTarget Version => 3.10
2020-05-27 09:00Vincent SandersStatusresolved => closed
2020-05-27 09:00Vincent SandersNote Added: 0002212