|View Issue Details|
|ID||Project||Category||View Status||Date Submitted||Last Update|
|0002182||NetSurf||RISC OS-specific||public||2014-08-12 09:00||2016-02-16 15:30|
|Assigned To||David Gee|
|Target Version||Fixed in Version||3.4|
|Summary||0002182: Netsurf unilaterally closes the menu tree when asked if it has any clipboard data|
|Description||On 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 Information||The 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:
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.
Likewise, to drag a selection from a browser window the Wimp will have closed the menu tree for you.
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.
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.
|Tags||No tags attached.|
|Fixed in CI build #||2655|
|Reported in CI build #|
|URL of problem page|
Vincent Sanders (administrator)
|Confirmed resolved in 3.4 release|
|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|