The SVGTiny content handler uses the reflow method to set the
content width/height. The when the content first broadcasts "done",
the HTML handler checks if there had already been a layout. If there
has, it calls the SVG's content reflow method with the box dimensions.
If not, it calls the reflow method with width/height zero.
Since the layout code was only reflowing objects if they were HTML,
these SVG contents were never getting their actual dimensions.
The result of this was that when we came to plot these SVGs we were
dividing by zero in the building of the transformation matrix:
transform[0] = (float) width / (float) c->width;
...
transform[3] = (float) height / (float) c->height;
These divided the plot size by the content size.
The result of this on the GTK front end was infinities in the
transformation matrix passed to Cairo, and the turning of the
whole nsgtk window into a glitchy ruin while the SVG was on
screen.
It may have affected other front ends too; these divide by zeros
were happening in the core, and passed to the front ends' plotters.
This issue only affected SVGs on HTML pages, and not when viewed
directly. Also the SVGs had to be completely fetched and converted
before the document had undergone layout.
This was the case with SVGs at the top of both Wikipedia and The
Register. In both cases the glitching window would be fixed by
scrolling down the page past the SVG.
This adds a new config option, `author_level_css`.
When it is disabled, NetSurf will ignore all CSS from the web
page. In this case only the default CSS rules from the browser
and user CSS rules will be applied. It is enabled by default.
Tested by running:
./nsgtk3 --author_level_css=0
When a scaffold was being destroyed the currently selected scaffold could become a reference to a destroyed object. This would result in crashes subsequently when the current scaffold was referenced.
The change is simply to ensure the selected scaffold is changed to something valid during destruction.
If we are building against a modern version of libcurl, but it was
built against a version of OpenSSL that does not support TLS1.3,
then attempting to configure TLS1.3 ciphersuites will fail with
CURLE_NOT_BUILT_IN. Tolerate this scenario by treating such a
return code as non-fatal in this case.