Instead, subclass nsTextControlFrame. This simplifies the code and avoids
correctness issues.
I kept the localization functionality though it is not spec compliant. But I
filed a bug to remove it in a followup.
Differential Revision: https://phabricator.services.mozilla.com/D57193
--HG--
extra : moz-landing-system : lando
Instead, subclass nsTextControlFrame. This simplifies the code and avoids
correctness issues.
I kept the localization functionality though it is not spec compliant. But I
filed a bug to remove it in a followup.
Differential Revision: https://phabricator.services.mozilla.com/D57193
--HG--
extra : moz-landing-system : lando
This patch makes `nsContentUtils::DispatchInputEvent()` dispatch `beforeinput`
event too. And also adds `onbeforeinput` event handler which is really
important for feature detection (although Chrome has not implemented this
attribute yet: https://bugs.chromium.org/p/chromium/issues/detail?id=947408).
However, we don't implement `InputEvent.getTargetRanges()` in this bug and
implementing `beforeinput` event may hit bugs of some web apps. Therefore,
this patch disables `beforeinput` event by default even in Nightly channel.
Differential Revision: https://phabricator.services.mozilla.com/D58125
--HG--
extra : moz-landing-system : lando
This patch makes `nsContentUtils::DispatchInputEvent()` dispatch `beforeinput`
event too. And also adds `onbeforeinput` event handler which is really
important for feature detection (although Chrome has not implemented this
attribute yet: https://bugs.chromium.org/p/chromium/issues/detail?id=947408).
However, we don't implement `InputEvent.getTargetRanges()` in this bug and
implementing `beforeinput` event may hit bugs of some web apps. Therefore,
this patch disables `beforeinput` event by default even in Nightly channel.
Differential Revision: https://phabricator.services.mozilla.com/D58125
--HG--
extra : moz-landing-system : lando
In particular, we don't want to assume that when we sleep for N ms that will
actually take about Nms of time. Instead, record how much time it took, and
make sure that our thread metric accounting accounts for all that time, but not
any of the extra time it shouldn't account for.
Differential Revision: https://phabricator.services.mozilla.com/D59656
--HG--
extra : moz-landing-system : lando
The idea is to use the slice-accounting setup from the performance counters for
idle tasks as well, and fix the various bugs we have when nested event loops
are involved.
The bit in nsThread::SizeOfEventQueues that counted memory for
mCurrentPerformanceCounter was wrong all along, I think: the docgroup that owns
the performance counter should account for it.
Differential Revision: https://phabricator.services.mozilla.com/D59596
--HG--
extra : moz-landing-system : lando
Behind a pref of course. Toggle that pref on on the loading/lazyload test
subdirectory, though there are no tests for the IDL (I guess once the spec PR
lands the existing IDL tests will be updated from the spec).
Differential Revision: https://phabricator.services.mozilla.com/D59764
--HG--
extra : moz-landing-system : lando
The increments are incrementing the pointers, not the values.
This was caught by a GCC warning.
Depends on D59646
Differential Revision: https://phabricator.services.mozilla.com/D59647
--HG--
extra : moz-landing-system : lando
Add browser support for FinalizationGroup by setting the HostCleanupFinalizationGroupCallback in CycleCollectedJSContext. The callback adds groups pending cleanup to a vector stored in a PersistentRooted. A runnable is dispatched to call back into the JS engine and perform cleanup at a later time as a separate task. Using AutoEntryScript reports errors to the console.
Differential Revision: https://phabricator.services.mozilla.com/D53248
--HG--
extra : moz-landing-system : lando
We are getting this exception because we return false here and do not perform
the microtask checkpoint when CycleCollectedJSContext::runJobs executes, but
the contract of runJobs() _requires_ that the microtask queue be empty after
is has completed execution.
CycleCollectedJSContext::RecursionDepth() returns the depth taking the debugger
recursion depth and the thread recursion depth into account, however when
used here, mTargetedMicroTaskRecursionDepth is expects to only be compared
against the thread recursion depth
Differential Revision: https://phabricator.services.mozilla.com/D58901
--HG--
extra : moz-landing-system : lando
Splits WebGLContext into ClientWebGLContext and HostWebGLContext. The Client enables the JS-control of a WebGL context in a content procecss while the Host executes the WebGL graphics operations (via a WebGLContext that maintains much of the existing code) in the compositor process. At this point, the cross-process behavior is disabled -- this series of patches is an incremental step toward that final goal.
Differential Revision: https://phabricator.services.mozilla.com/D54018
--HG--
extra : moz-landing-system : lando
It turned out that `ShellExecuteByExplorer` does not work on VDI such as Citrix
or Microsoft RemoteApp. This patch adds a fallback to the original launching
code if `ShellExecuteByExplorer` fails. This will be a temporary solution until
we find out a way to solve both interop issues `PreferSystem32Images` and VDI.
Differential Revision: https://phabricator.services.mozilla.com/D58054
--HG--
extra : moz-landing-system : lando
This patch changes the xpidl parser to generate the rust trait code for
methods that take or return a cenum value.
Previously this would return an error, which means that adding a method
that uses cenums to an existing interface could cause rust code that
implements that interface to fail to build.
The generated methods take or return u8/u16/u32 depending on the width of the
enum. While this is not optimal (the parameter could contain values that are
not actually part of the enum), this is similar to what we do for nsLoadFlags.
In the future it would be nice to generate code that actually checks the
values are present in the enum, and to use a typedef instead of a plain
unsigned int.
Differential Revision: https://phabricator.services.mozilla.com/D51838
--HG--
extra : moz-landing-system : lando
nsIMutable is used only by DOM Blob/File. But Blobs are immutable by spec.
FileBlobImpl has a couple of lazy member values, but those are called when
the object is cloned in order to be sent to a different thread/process.
Differential Revision: https://phabricator.services.mozilla.com/D58946
--HG--
extra : moz-landing-system : lando
nsIMutable is used only by DOM Blob/File. But Blobs are immutable by spec.
FileBlobImpl has a couple of lazy member values, but those are called when
the object is cloned in order to be sent to a different thread/process.
Differential Revision: https://phabricator.services.mozilla.com/D58716
--HG--
extra : moz-landing-system : lando
This switches over one usage of `nsAutoPtr` that was just used to scope an allocation, a stack variable is used instead. The shutdown contexts array is switched over to hold `UniquePtr`s which required adding a helper to find elements in the array as `UniquePtr` does not auto-convert to its pointer type.
Differential Revision: https://phabricator.services.mozilla.com/D58317
--HG--
extra : moz-landing-system : lando
This converts straightforward `nsAutoPtr` usage over to `UniquePtr`.
`nsClassHashtable` is left alone for now as that will have a larger impact.
`nsThread` is left alone for now as it has non-trivial ownership concepts.
Differential Revision: https://phabricator.services.mozilla.com/D58284
--HG--
extra : moz-landing-system : lando
This removes various unused `#include "nsAutoPtr.h"` in `xpcom/`. Additionally
adds a few includes to the media stack.
Differential Revision: https://phabricator.services.mozilla.com/D58282
--HG--
extra : moz-landing-system : lando
This allows us to consistently use mCachedIdleDeadline to represent whether idle runnables should run.
Differential Revision: https://phabricator.services.mozilla.com/D58419
--HG--
extra : moz-landing-system : lando
This changeset is a simple find and replace of `MOZ_FALLTHROUGH` and `[[fallthrough]]`.
Unfortunately, the MOZ_FALLTHROUGH_ASSERT macro (to assert on case fallthrough in debug builds) is still necessary after switching from [[clang::fallthrough]] to [[fallthrough]] because:
* MOZ_ASSERT(false) followed by [[fallthrough]] triggers a -Wunreachable-code warning in DEBUG builds
* but MOZ_ASSERT(false) without [[fallthrough]] triggers a -Wimplicit-fallthrough warning in NDEBUG builds.
Differential Revision: https://phabricator.services.mozilla.com/D56440
--HG--
extra : moz-landing-system : lando
Randell Jesup
Emilio Cobos Álvarez
Mihai Alexandru Michis
Masayuki Nakano
Razvan Maries
Boris Zbarsky
Eric Rahm
Gijs Kruitbosch
Daniel Varga
Jon Coppeard
Logan Smyth
Sylvestre Ledru
Olli Pettay
Andi-Bogdan Postelnicu
Alex Henrie
David Parks
Karl Tomlinson
Toshihito Kikuchi
Valentin Gosu
Christoph Walcher
Andrea Marchesini
Brindusan Cristian
Noemi Erli
ffxbld
Nathan Froyd
Simon Giesecke
emalysz
Chris Peterson