The target url was previously being passed as a string derived from
nsurl_access which was asserting if the target_url was NULL. The nsurl
is now passed and a null check performed before attempting to access
it.
Closes#2298
Currently, when asked for clipboard data, Netsurf unconditionally closes the
menu tree of the requesting application. This occurs in the routine
ro_gui_send_datasave. There is no reason to close the menu tree: this function
is called in only one place, amd the code path is through Wimp user messages--
the highest priority type of message, so other interactions cannot interfere.
The fix removes the line which closes the menu tree in this particular function.
RISC OS apps take their creation date from the !RunImage apparently
and loose the data if the application directory gets copied without
one. Fixes#1970
The content thumbnailers for each frontend were being provided the
contents url. This was only ever used to call the urldb thumbnail
setting API.
This changes it so the single callsite that passed a valid url adds
the bitmap to that url itself in desktop_history.c instead of forcing
every frontend to require the urldb API.
Additionally the old API could pass the url as NULL which was causing
asserts where this was not an expected parameter value. Because of
this this fixes bug #2286 which was also present in the monkey
frontend as both called nsurl_access() on the url without the NULL
check and caused an assertion.
This splits up a great deal of the win32 window code out from other
gui code. It also remove large quantities of unused and junk
variables and functions.
The html content script handling needs to invalidate its JavaScript
context when the browsing context (browser_window) containing it is
either closed or the content fetch is aborted (stopped)
Previously the invalidation was only done on browser_window close
which resulted in use after free crashes because of the now invalid
JavaScript context.
When the browser window is about to be destroyed html_close gets
called indicating the browser_window previously associated with the
html content is about to become invalid.
This makes the javascript context invalid within the html content (it
is held by the browser window) when that context is about to be
destroyed. Previously the javascript children would continue to
attempt to use the context after it had been destroyed causing all
sorts of strange errors and failures.
The size hints given were insufficient for gtk to open the window at a
sensible size or position. This fixes it to open with a default
640x480 size which is a reasonable compromise.
The gtk3 ui builder file was completely reconstructed from fresh as it
was broken and was not working.
