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.)
We already suppressed GC for part of this, but we may sweep before the pre-write
barrier is established.
The simplest and safest thing is to suppress GC for the whole method.
Remove early return in nsExternalProtocolHandler::NewChannel when handler doesn't exist.
Fix devtools expectation that newChannel throws for unsupported external handlers
