In order to not blow up on massive rowspan/colspan values (which
could be an issue according to #2873) we clamp them according to
the HTML spec section 4.9.11
Signed-off-by: Daniel Silverstone <dsilvers@digital-scurf.org>
We now require 1.1.1 or later (and, preferably, 3.x).
Also take the opportunity to add support for LibreSSL 3.5.0 or
later (we still support ancient versions of this because 3.5.0 is
still relatively modern -- give it a few more years and support
for old LibreSSL can go, too)
We now require 1.1.1 or later (and, preferably, 3.x).
Also take the opportunity to add support for LibreSSL 3.5.0 or
later (we still support ancient versions of this because 3.5.0 is
still relatively modern -- give it a few more years and support
for old LibreSSL can go, too)
* Drop support for DHE completely (logjam plus compat woes
caused other browsers to do this some time ago)
* Minimise CBC-mode suites
* Fall back to non-PFS RSA suites if really necessary (we treat
this as a protocol downgrade as anything modern should either
be using TLS 1.3 or have support for the ECDHE suites)
While we have no need to transform the URL in the HTTPS case, the
HSTS policy should still result in a hard failure when something
is untoward (i.e. not providing the user with a way to proceed).
Ensure this is so.
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
