Version 1.5.1 includes some of our own fixes, reducing our delta
to upstream.
These should not be needed now:
- 2cbb337756
Squash harmless Clang warning introduced in Duktape 1.5.0.
- 8f8cda2b48
Fix Duktape on AmigaOS3 (thanks to Tygre and Sami)
This will happen when attempting to open old 68k libraries with no separate interface file, but may also occur when the interface name or version doesn't exist (although the library version number _should_ prevent that)
Libjpeg used in NetSurf for decoding of JPEG images handles exceptions using a
pair of non-local jump functions: setjmp() and longjmp(). When a decompression
context is created via a call to the function jpeg_create_decompress() the
caller passes a structure jpeg_decompress_struct as a parameter. This structure
should has a validly initialized jump buffer, so the initialization or other
functions called in future can jump to the exception handling context.
The jpeg backend of NetSurf now initializes libjpeg mistakenly: jump buffer is
filled after the call to jpeg_create_decompress(). It results in jump to random
addresses in the case of exception caught during operation of the function
jpeg_create_decompress().
The patch moves the initialization of jump buffer before the call to
jpeg_create_decompress().
Signed-off-by: Sergei Rogachev <rogachevsergei@gmail.com>
bitmap file decoding is done at first call to redraw but was not
calling the modified callback at the correct time immediately after
decode so frontend image chnages were not being done. This caused
nsgtk to fail to apply its colour space fixups so red was swapped with
blue.
I've never been entirely clear on what the correct approach here is, but OS4 has a feature where it will auto open/close a public screen for you. In this case, in the microseconds between unlocking that screen and attempting to close it, OS4 has already disposed of the screen and NetSurf has crashed, so we assume the owner will handle the closing instead.
Previously the expected behaviour for front ends using the correct
API for hotlist, global history, cookie manager, and ssl cert
viewer was that the front end would initialise the treeview module
on startup and finalise it on application exit.
However, this meant that the front ends had to include the core
treeview header, which they didn't otherwise need.
Since the tree module provided access to the new treeview utilities
through the old tree API, and was used by front ends with no changes
for the new treeview API, the tree layer refcounted initialisations
of treeview-based widgets, and only called the underlying treeview
init/fini functions when needed.
This change moves that refcounting into the treeview module. Now
the hotlist, global history, cookie manager, and ssl cert viewer
widgets call call treeview init/fini as part of their own
initialisation and finalisation. This means that front ends
using the correct APIs for treeview-based widgets don't need to
know anything about the underlying treeview, and the tree module
compatibility layer has had its treeview refcounting removed.
Finally, the treeview_init function took a font size parameter.
Now it does not and lit gets font size from config. We probably
want to add a new `treeview_font_size` option to nsoptions, and
have differnent defaults on different platforms. 12pt on RISC OS,
and 11pt elsewhere, most likely.
Add some more debug:
It appears that some timer events are not being picked up, I can see in the log that something which should have been signalled is not being run.
Enabling the log appears to make the situation worse.
This is a hang-over from the old polling scheduler. I've modified it to use relative times and pass the callback along with the TimeRequest so events get executed in the order they arrive.
The list of events is still in a heap sorted by expected execution time, but this may need to change to something more efficient for random lookups.
TimerRequests are removed from the message queue by WaitIO() which is ultimately called when the event is taken off the heap.
The event on the top of the heap is _not necessarily_ the one which signalled us, though, and we should probably be handling this better.
