2019-01-22 02:54 UTC

View Issue Details Jump to Notes ]
IDProjectCategoryView StatusLast Update
0002182NetSurfRISC OS-specificpublic2016-02-16 15:30
ReporterSprow 
Assigned ToDavid Gee 
SeverityminorReproducibilityalways 
StatusclosedResolutionfixed 
Product Version3.1 
Target VersionFixed in Version3.4 
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.
Fixed in CI build #2655
Reported in CI build #
URL of problem page
Attached Files

-Relationships
+Relationships

-Notes
Vincent Sanders

~0001325

Vincent Sanders (administrator)

Confirmed resolved in 3.4 release
+Notes

-Issue History
Date Modified Username Field Change
2014-08-12 09:00 Sprow New Issue
2014-08-12 16:49 Vincent Sanders Assigned To => Steve Fryatt
2014-08-12 16:49 Vincent Sanders Status new => acknowledged
2015-03-02 16:18 Michael Drake Severity major => minor
2015-03-18 00:04 Vincent Sanders Fixed in CI build # => 2655
2015-03-18 00:04 Vincent Sanders Assigned To Steve Fryatt => David Gee
2015-03-18 00:04 Vincent Sanders Status acknowledged => resolved
2015-03-18 00:04 Vincent Sanders Resolution open => fixed
2015-03-18 00:04 Vincent Sanders Fixed in Version => 3.4
2016-02-16 15:30 Vincent Sanders Note Added: 0001325
2016-02-16 15:30 Vincent Sanders Status resolved => closed
+Issue History