Manual checking of the origins in SecFetch fails, so we add this
capability to the base principal interface for sake of ease.
We could use ScriptSecurityManager directly but it's more convenient
this way and can be re-used elsewhere in the future.
Currently following Mozilla putting stuff in /dom for additional porting,
but it's actually the wrong location since it belongs in /netwerk with
the other code that deals with http headers.
For sake of ease of use, converted to boolean functions that just assume "false"
in case of errors.
Note: Mozilla makes special arrangements for .onion addresses as well but
we explicitly do not adopt that. TOR browser can do that all day if it wants.
For the time being, because we don't have `revert` yet, we should force
normally hidden elements to be hidden, so they aren't revealed by sites
using the bad practice of `*{ }` style blanking rules but then using
`revert` to re-hide them.
As pointed out in the ecma-262 spec change discussion, the behavior is
inconsistent for negative numbers because the exponential fallback assumes
all the digits will be displayed. The negative support was motivated just
by consistency, without any particular concrete use cases, and it's not
supported in other browsers, so this patch removes negatives.
Resolves#2543
This patch adds an enumerable, configurable, readonly attribute "webdriver" to
the Navigator object. The attribute is always false because we do not support
WebDriver or scripted automation.
The navigator.webdriver attribute is meant as an indication to web authors that
a document is visited by WebDriver. It is important to stress that it is not
meant as a way to detect that a website is being visited by a browser automation
tool or bot, but as a tool for web documents to take alternate code paths.
On the off-chance exposing navigator.webdriver turns out to be catastrophic,
we put it behind a new preference dom.webdriver.enabled that controls its
exposure.
We always use PreventDefault for <select> element, which is problematic if modal
dialog is on as it prevents cancelling the dialog. We fix it by not blocking the
default action if <select> is not shown.
See Bug 1649278
Altivec code was previously uncompilable, and the altivec accelerations
also could not be disabled with a build flag or env variable, leading
to pale moon not being buildable on any altivec supported CPU ( all
PPC CPUs ever almost ). Why? I don't know, 'inline' in C is cursed
and making it static makes it significantly less so.
Closes: https://forum.palemoon.org/viewtopic.php?f=5&t=31108&p=252462#p252462
Signed-off-by: Richard Rogalski <rrogalski@firemail.cc>
We null-initialize all of the other pointer members in NewPerSpanData; we should
do the same for these ones, for consistency & robustness.
(In practice, the callers end up initializing these members before reading them
anyway, so it's been benign that we weren't initializing them. But better for
safety & futureproofing to have them reliably initialized.)
