Performance observers have shown to be stable in daily use, so we should
enable this by default. Any applications building on UXP can decide for
themselves whether to explicitly enable or disable this API.
* Add javascript.options.weakrefs and plumb it through context options, XPConnect, and workers
* Keep referents alive via strong tracing when the pref is off so deref() still returns the target
* Retain weak-edge semantics when the pref is enabled
Flip the pref. We want this on by default for web compat.
Users can disable it if they really want to, but it doesn't expose
anything of note to web content anyway that can't already be determined.
This DOM/Web API is entirely irrelevant for desktop use.
We give back the width/height of the root scrollframe of content and
for scale we pass forward our dpp resolution (usually 1.0).
Since we have no "no touch" zones in our content on desktop,. the rest
(origin and offset) is hard-coded to (0,0).
See: https://github.com/whatwg/fetch/issues/274#issuecomment-2841053461
Considering the ubiquitous nature of gif, jpg, png, mp4, avi, etc. those
are left out, leaving just jxl, webp, x-matroska (mkv) and webm as
explicitly mentioned supported formats for conneg.
Note: it's not clear where network.http.accept.image is used in practice
because our normal place to use the image override (imgloader) uses
a different pref (image.http.accept).
In the modern era of user-customizable Quick Access sidebars on every file
dialog, navigating via `.lnk` files is considerably less useful than it
was twenty years ago.
Disable link-following in file-open dialogs by default, to prevent any of
the usual security issues involving symlink smuggling.
Allow overriding this behavior via a pref, for users who want to trade off
this security issue for convenience of being able to follow links inside
file dialogs (older OSes and established user workflows).
Note: File Save dialogs have a set of more nuanced guards against link
smuggling and protected file access; this change doesn't affect that.
This is a temporary measure to work around CF OOM situations.
Reporting is desirable normally so webmasters get alerted to CSP issues,
and this should be flipped back on once we can.
This removes a lot of the plumbing for having the platform embed itself
through IPC which was required for B2G running the browser as both
shell and browser application.
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.
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.
The timings here are still slightly more lenient than the hard-coded
fallback timings in code (10/20 for content/chrome respectively) but
we definitely should not need very long time-outs by default on Chrome
scripts anymore.
Also exposes dom.always_stop_slow_scripts to about:config since we're
making it also UI-configurable in Pale Moon and it just makes sense not
to hide this option.
This was already in the codebase, but not exposed by default. Mozilla exposed
the pref to fulfill user requests in Firefox 59. Forum users requested the same feaure of pseudo-fullscreen windows. Seems minor enough not to be worth
creating an issue for, since users can already access this by creating a bool
pref.
Ref: BZ 1422535
This removes some hackery surrounding preventing content clicks, and in
general handles auxclick as it should, firing that event on secondary
buttons (wheel/right on default setup for right-handed mouse).
The original state was inverted due to confusion due to a double
negative (not:no_error).
This validation should only be enabled on Windows (for now).
Future tracking and discussion in BZ 1862039