MantisBT - NetSurf
View Issue Details
0002182NetSurfRISC OS-specificpublic2014-08-12 10:002016-02-16 15:30
ReporterSprow 
Assigned ToDavid Gee 
PrioritynormalSeverityminorReproducibilityalways
StatusclosedResolutionfixed 
PlatformOSOS Version
Product Version3.1 
Target VersionFixed in Version3.4 
Fixed in CI build #2655
Reported in CI build #
URL of problem page
Summary0002182: Netsurf unilaterally closes the menu tree when asked if it has any clipboard data
DescriptionOn receipt of Message_DataRequest NetSurf closes any open menus, even if it did not itself have any menus open, meaning other applications can't send that message and have menus open at the same time!
Additional InformationThe drag & drop functional spec (1309,419/FS) states that to discover if there is something on the clipboard worth pasting you should send round a Message_DataRequest and see whether what comes back (if anything does) in Message_DataSave is of interest to you. However, when NetSurf owns the global clipboard attempting to make this query results in any open menu trees being collapsed - this is a problem for the situation where you're building a submenus (including an indication of whether the clipboard has anything on it) over several Wimp polls by using submenu warnings.

Looking in the sources it seems like ro_gui_send_datasave is the problem, it unconditionally collapses the menu tree. This construct looks to occur 5 times in "save.c", so it's worth reviewing them all quickly:

1. ro_gui_drag_save_object
As you'd have to click away from any open menu in order to start a drag save, any menus would be closed for you by the Wimp, so the menus don't need closing manually a second time.

2. ro_gui_drag_save_selection
Likewise, to drag a selection from a browser window the Wimp will have closed the menu tree for you.

3. ro_gui_drag_save_link
Ditto.

4. ro_gui_send_datasave
This is the problematic one. NetSurf has no reason to close the menu tree as this function is only called in one place, and the code path to that place is through the Wimp user messages. User messages are the highest priority type of message, so there's no danger of other interactions (mouse clicks etc etc) getting in the way.

5. ro_gui_save_done
That one makes sense to terminate the transaction.

In each case the ro_gui_dialog_close(dialog_saveas) can stay, since I note the save dialogue that pops up when F3 is pressed isn't a transitory window hanging off a menu, so that would need manually closing if you're wanting to avoid tracking two save-as contexts.
TagsNo tags attached.
Attached Files

Notes
(0001325)
Vincent Sanders   
2016-02-16 15:30   
Confirmed resolved in 3.4 release

Issue History
2014-08-12 10:00SprowNew Issue
2014-08-12 17:49Vincent SandersAssigned To => Steve Fryatt
2014-08-12 17:49Vincent SandersStatusnew => acknowledged
2015-03-02 16:18Michael DrakeSeveritymajor => minor
2015-03-18 00:04Vincent SandersFixed in CI build # => 2655
2015-03-18 00:04Vincent SandersAssigned ToSteve Fryatt => David Gee
2015-03-18 00:04Vincent SandersStatusacknowledged => resolved
2015-03-18 00:04Vincent SandersResolutionopen => fixed
2015-03-18 00:04Vincent SandersFixed in Version => 3.4
2016-02-16 15:30Vincent SandersNote Added: 0001325
2016-02-16 15:30Vincent SandersStatusresolved => closed