This changes the off-thread promise helper code from using its own mutex to
using the helper thread lock for synchronisation.
For promise tasks executed on helper threads there's little benefit from using
a separate mutex as we already have to wait on the helper thread lock to start
the task. The changes ensure we don't delete the OffThreadPromiseTask while the
helper thread system thinks it's still running.
Differential Revision: https://phabricator.services.mozilla.com/D89472
Currently wasm uses its own mutex for off-thread compilation. This leads to the
sitation where the CompileTask structure can be freed while the helper thread
is still running (the ModuleGenerator destructor synchronises on its mutex, but
the helper thread run method releases this mutex before it returns).
Using the helper thread lock here makes sense. The helper thread lock is
already required to start the compiation task so I don't think there's much
gain from using a separate mutex.
Differential Revision: https://phabricator.services.mozilla.com/D89471
This utilises the fact that we can now specify the manifest
independently of the metadata path, which wasn't possible before. We
need to edit the default (i.e. Firefox) configuration to update the
metadata path (only) to point at something product-specific so we
don't end up using fx metadata for everything.
Differential Revision: https://phabricator.services.mozilla.com/D89461
TimedPromise logs a warning if the timeout exceeded and not error
should be raised. Given that Sleep always runs into that condition
a lot of inappropriate log entries are made that also causes
confusion for our users when commands (especially actions) don't
work as expected.
Differential Revision: https://phabricator.services.mozilla.com/D89354
It looks like we forgot to re-enable this code.
Hopefully this doesn't break any test. Without that, DAMP is throwing
because of late onResourceAvailable calls.
This might tells us that the throttling should check if it is still
relevant to emit the throttled event? I'm not having such check yet.
Differential Revision: https://phabricator.services.mozilla.com/D89476
Let's see following code and let's assume that wasm-compiler is ion:
call foo
call bar
Ion can clobber tls inside foo and then it can go with clobbered tls into bar.
There will be a crash if bar uses tls. At compile-time we don't know whether bar will use tls or not.
It works when we restore tls each time when we are returning from a function because of the current frame structure.
But now, when we want to get rid of Frame::tls we should guarantee that Ion doesn't clobber tls inside a function.
In fact we forces Ion to restore tls iff it clobbers it and it is a rare case.
Baseline doesn't need such logic because of its private stack slot for tls.
Differential Revision: https://phabricator.services.mozilla.com/D83061
Currently used mostly by Twitter and Facebook to allow them to specify which virtual quick navigation keys assistive technologies should not use when in those web applications, but instead pass them through to the browser. JAWS is currently the only known assistive technology making use of this feature.
This works in Chrome and the new Edge, but not in Firefox, because JAWS stopped using ISimpleDOM in Firefox, which no longer gave them access to this attribute.
This bug is to allow exposure of the non-standardized data-at-shortcutkeys attribute value via a same-named IAccessible2 and ATK Object Attribute.
Differential Revision: https://phabricator.services.mozilla.com/D86181
When restoring state into a new session, the actor gets recreated after
navigating away from `about:blank` so we have to query for it again to get the
right instance.
Differential Revision: https://phabricator.services.mozilla.com/D89475
The MOZ_MUST_USE macro is defined as clang's and gcc's nonstandard __attribute__((warn_unused_result)). Now that we compile as C++17 by default (bug 1560664), we can replace MOZ_MUST_USE with C++17's standard [[nodiscard]] attribute.
Differential Revision: https://phabricator.services.mozilla.com/D89316
The MOZ_MUST_USE macro is defined as clang's and gcc's nonstandard __attribute__((warn_unused_result)). Now that we compile as C++17 by default (bug 1560664), we can replace MOZ_MUST_USE with C++17's standard [[nodiscard]] attribute.
We can also stop #including mozilla/Attributes.h because it was only needed for its MOZ_MUST_USE declaration.
Differential Revision: https://phabricator.services.mozilla.com/D89310
The MOZ_MUST_USE macro is defined as clang's and gcc's nonstandard __attribute__((warn_unused_result)). Now that we compile as C++17 by default (bug 1560664), we can replace MOZ_MUST_USE with C++17's standard [[nodiscard]] attribute.
Differential Revision: https://phabricator.services.mozilla.com/D89237
For a local build on my Linux64 box, this reduces greprefs.js from 174,906
bytes to 103,221 bytes, and firefox.js from 112,100 bytes to 68,656 bytes.
Depends on D88242
Differential Revision: https://phabricator.services.mozilla.com/D88243
This commit does the following.
- Renames `slashslash` as `dumbComments`. As a result, it now comes before
`emptyLines` in alphabetical ordering, which means that if you apply both
`dumbComments` and `emptyLines`, lines that contain only comments will be
fully removed.
(I contemplated changing the filter ordering to match the order specified,
rather than using alphabetical ordering, but that was more invasive and not
obviously better.)
- Changes `dumbComments` so it only applies if the comment is at the start of
the line (with optional leading whitespace). This is so it can be used with
prefs files, which contain lines like `pref("foo", "https://mozilla.org");`
where the `//` must not be treated as a comment.
Note that `slashslash` wasn't being used anywhere.
Depends on D88240
Differential Revision: https://phabricator.services.mozilla.com/D88242
It's not used, probably because it's pretty strange and hard to imagine using
safely. (Stripping leading and trailing space could be useful, but collapsing
sequences of spaces? Hmm.)
Differential Revision: https://phabricator.services.mozilla.com/D88240
Use ID3D11VideoProcessor for video frame rendering.
WebRenderError::VIDEO_OVERLAY does not cause disabling WebRender. It just change gfxVars::UseWebRenderDCompVideoOverlayWin() to false.
Differential Revision: https://phabricator.services.mozilla.com/D88763
All of these reftests end up using a minimum scale with layout/classic scrollbars. (They hit the assert from the patch in bug 1663534.)
Some of them are only written with overlay scrollbars in mind (for example overflow-hidden-region-with-negative-left-positioned-element.html which I looked at in detail).
The change that causes them to fail is the code in nsHTMLScrollFrame::TryLayout that decides if we need scrollbars. Before desktop zooming scrollbars we compared the visual viewport size and the scrolled rect size. With desktop zooming scrollbars we compare the (layout) scrollport and the scrolled rect to determine if we need regular scrollbars and then compare the visual viewport size to the (layout) scrollport to determine if we need scrollbars to scroll the visual viewport inside the scrollport. Then can get different results.
Differential Revision: https://phabricator.services.mozilla.com/D89407
Our data indicates when the browser process populates a newly-created child process,
`VirtualProtectEx` may fail with `ERROR_INVALID_ADDRESS` for some unknown reason.
One possible cause is the parameter `aRemoteExeImage` of `RestoreImportDirectory`
was wrong i.e. pointing to an invalid address. We simply pass the local process's
imagebase as `aRemoteExeImage` based on the assumption that the same executable is
mapped onto the same address in a different process, but it may not be guaranteed.
To deal with that potential case, we could retrieve a correct imagebase from the handle
of a remote process as we do for the plugin process. Since we're not so sure about
the root cause or the effectiveness of this fix, we run it only when the first
attempt to `VirtualProtectEx` failed in Nightly. Once it's confirmed, we promote this
to a permanent fix.
Differential Revision: https://phabricator.services.mozilla.com/D89502
The llvm-strip from clang-11 complains about this file. This file doesn't really interest us anyway -- it's imported from elsewhere -- so just avoid it.
Differential Revision: https://phabricator.services.mozilla.com/D89491
This was left as a debug option when the original change was made,
to allow seeing the differences. It's no longer required.
Differential Revision: https://phabricator.services.mozilla.com/D89328
This moves a bunch of tests over to a topical directory, and removes the
linux/windows running restrictions around browser_bug1015721.js
(now browser_mousewheel_zoom.js), given that it appears to run fine on try
and there are no recent logs with which we can diagnose failures.
It switches away from using FullZoom.reset repeatedly in the background_zoom
test because that trips https://bugzilla.mozilla.org/show_bug.cgi?id=1604236
which breaks subsequent tests.
Differential Revision: https://phabricator.services.mozilla.com/D89484
This fixes a bug that was introduced in recent optimizations where
upload-symbols may not run for shipped release builds. We can add it as
a dependency for this, or some other per-platform task that runs for
releases. As long as it runs before we ship this should be fine.
Differential Revision: https://phabricator.services.mozilla.com/D89494
