This simplifies things all around, and gets rid of one more unnecessary
component registration.
--HG--
rename : toolkit/components/extensions/extension-process-script.js => toolkit/components/extensions/ExtensionProcessScript.jsm
extra : rebase_source : 7ceb6ada0730f8241bbd5ddbd889a320da22b1b1
The SQLite in Debian 7 (3.7.13) lacks support for common table
expressions (the WITH keyword), which was introduced in SQLite
3.8.3. The Mercurial SQLite storage backend currently relies on
CTEs. Even if a future Mercurial doesn't require CTE, it is likely
that it will still use CTE if available for performance reasons.
So, it is in our best interest to give Mercurial access to a
modern SQLite. Plus, using a modern SQLite and avoiding potential
bugs in old versions seems prudent.
This commit introduces a SQLite package backport for Debian 7
so we can use the new SQLite feature. We had to minimally patch
the build to work with an older version of TCL that isn't using
multiarch.
I observed libsqlite3 being installed as part of building various
other packages (such as Python). I initially added the package as
a dependency so packages would be built against a more modern
SQLite. But glandium doesn't believe it matters, since nothing
should be doing build-time feature detection. Python is the most
important downstream package (since Mercurial uses its SQLite).
I audited the CPython build system and did not see any build-time
SQLite feature detection or version sniffing. So I think we'll be
fine building against an older SQLite.
Differential Revision: https://phabricator.services.mozilla.com/D14194
--HG--
extra : moz-landing-system : lando
This appears to "just work."
While I would like to convert this image to Debian and make it
deterministic, that is more effect than I'm willing to invest at the
moment.
The impetus for this change is unblocking partial clones. Mercurial's
SQLite storage backend apparently hits a SQLite bug in version 3.11
of SQLite (what Ubuntu 16.04 runs) where SQLite complains about
database corruption when there are readers from multiple processes.
Ubuntu 18.04 is running SQLite 3.22 and doesn't exhibit the buggy
behavior.
Differential Revision: https://phabricator.services.mozilla.com/D14228
--HG--
extra : moz-landing-system : lando
Until rust 1.28, there was no stable way to change the allocator used by
rust code. In bug 1280578, we hooked HeadAlloc/HeapFree/HeapRealloc,
that the default rust system allocator uses. On other platforms, rust
code just ended up using malloc/free/realloc like everything else.
As of rust 1.28, though, it is now possible to use the GlobalAlloc trait
and the #[global_allocator] attribute to set an allocator. On Windows,
this can allow us to hook mozjemalloc directly, rather than using an
indirection through HeapAlloc/etc. (which require an extra call to
GetProcessHeap), so let's do this. On other platforms, this just ends up
doing the same thing as the default rust system allocator (except for
the memalign limit on 32-bits platforms).
We still need the HeapAlloc/etc. hooks for some C++ code using it, though.
Another benefit is that the HeapAlloc GlobalAlloc implementation needs
to do its own memalign, which it does by overallocating and aligning
manually. We obviously don't need to do this when we using
memalign/_aligned_malloc directly.
Differential Revision: https://phabricator.services.mozilla.com/D14820
--HG--
extra : moz-landing-system : lando
It was crashing in DumpLeakedURLs::~DumpLeakedURLs(). If we have never used DumpLeakedURLs we were initializing gAllURLsMutex in a destructor of another static variable.
Differential Revision: https://phabricator.services.mozilla.com/D14263
--HG--
extra : moz-landing-system : lando
In libavcodec 58 and later, the old avcodec_decode_video2 is broken and only return the first visible frame found after a VP9 super-frame.
This resulted in some YouTube videos for about 10% of the frames to never be returned.
Only the new API properly behaves so we upgrade our code to use it.
Differential Revision: https://phabricator.services.mozilla.com/D14682
--HG--
extra : moz-landing-system : lando
Hid the checkbox-label-box from the Shockwave plugin to correct the tab focus.
Differential Revision: https://phabricator.services.mozilla.com/D14033
--HG--
extra : moz-landing-system : lando
These are undocumented and were only used for the about:webrtc page. They can
be removed without first deprecating them.
Differential Revision: https://phabricator.services.mozilla.com/D14464
--HG--
extra : moz-landing-system : lando
The value for mozAvSyncDelay has been broken since the branch 57 update
(Bug 1341285). We added SetCurrentSyncOffset() but never called it from
anywhere.
In the future we should be getting stats from AudioReceiveStream rather than
modifying the channel code, the delay_estimate_ms field provides almost the
same information.
Since we're attempting to get rid of moz prefixed stats, it makes sense to just
remove this code rather than fix it. The associated telemetry code has been
broken since Bug 1341285 as well so I think it is safe to remove.
Differential Revision: https://phabricator.services.mozilla.com/D14462
--HG--
extra : moz-landing-system : lando
Debugger invisibility is only practical to enforce on compartment boundaries,
and for its proper uses, that's good enough. Unfortunately, at present, debugger
invisibility is a flag on realms. This misfit is the reason for the sole
remaining code that assumes that every object is associated with a particular
realm: Debugger.Object.prototype.unwrap consults the unwrapped object's global
to see whether it is about to reveal an object that it must not. We would like
to remove this code.
This patch:
- adds an `invisibleToDebugger` flag to JS::Compartment, and sets it from the
Realm options (since there is no API for creating compartments directly; only
the act of creating a Realm can create a compartment to hold it);
- changes Debugger.Object.prototype.unwrap to check the compartment's flag, thus
removing the final use of JSObject::deprecatedRealm;
- asserts that new realms added to a compartment have a compatible visibility; and
- changes the shell primitive for creating realms to throw an error in case of
incompatible requested visibilities, rather than crashing.
Differential Revision: https://phabricator.services.mozilla.com/D14625
--HG--
extra : moz-landing-system : lando
We currently don't use 'navigator:browser' for GeckoView windows because
we need an easy way to disambiguate from Fennec windows. Instead, we use
'navigator:geckoview' for those windows. This adds a method that falls
back to that automatically, useful in cases where you want it to work on
both Desktop/Fennec and GeckoView.
Differential Revision: https://phabricator.services.mozilla.com/D14613
--HG--
extra : moz-landing-system : lando
Child processes cannot access textures allocated in the parent process,
which is needed by the compositor to render video elements efficiently.
Unfortunately, Android doesn't expose Sufrace buffers (sharable across
processes) in the SDK/NDK as other platforms, so we need to generate
extra texture/surface in the child process and update texture images
through the surface, which is passed to the parent process for the remote
texture to copy its contents into.
Differential Revision: https://phabricator.services.mozilla.com/D11939
--HG--
rename : mobile/android/geckoview/src/main/aidl/org/mozilla/gecko/gfx/ISurfaceAllocator.aidl => mobile/android/geckoview/src/main/aidl/org/mozilla/gecko/gfx/SyncConfig.aidl
extra : moz-landing-system : lando
Both libjpeg and windows.h typedef `boolean` to different types (`int` and
`unsiched char` respectively) and nsJPEGEncoder's public definition includes a
function that returns a `boolean`. Exposing this header results in type
conflicts.
We now isolate the internals of nsJPEGEncoder into a friend class whose
internals are hidden from the publica, allowing the header to exported.
Differential Revision: https://phabricator.services.mozilla.com/D14638
--HG--
extra : moz-landing-system : lando
[Bug 1512634](https://bugzilla.mozilla.org/show_bug.cgi?id=1512634) occurred because the Rule view marks CSS properties as overriden when they are not lowercase. This happens because `ElementStyle.markOverridden()` relies on computed properties. They get built using `CSSProperties.getSubproperties()`. If the input to that method is not lowercase, it doesn't match properties from the CSS database and returns an empty array. This has a side-effect of marking the property as overriden.
In this patch we allow users to type property names in any case, but we validate the lowercase version of them.
Differential Revision: https://phabricator.services.mozilla.com/D14568
--HG--
extra : moz-landing-system : lando
