This means that the number input by default shows some white space to
the right of the spinners. I think it's probably not the end of the
world, and depending on the different trade-offs we might want to do
this instead of fixing the test.
Depends on D103270
Differential Revision: https://phabricator.services.mozilla.com/D103271
This is slightly unfortunate on one hand because we're technically lying
(but so is chromium and our GTK theme, on the other hand).
It is nice because it means that themed and unthemed controls have the
same size by default though, which seems desirable.
So I'm a bit on the edge here, but I think this is probably the less bad
option to grow our form controls if we want to do it.
Differential Revision: https://phabricator.services.mozilla.com/D103477
Just drive-by cleanup, no behavior change.
There's an using namespace mozilla, so also remove some useless
namespace qualifications while at it.
Depends on D103562
Differential Revision: https://phabricator.services.mozilla.com/D103563
This revision introduces helpers for determining whether or not dialogs opened with TabDialogBox show the checkbox for allowing focus (tab switching). The approach for showing the checkbox follows the pattern similar to how its handled for TabModalPromptBox:
First, when a prompt is opened, the "DOMWillOpenModalDialog" event is fired from `PromptParent.jsm` on the browser tab. The browser then determines if the tab the event is dispatched on is the current selected tab. If the dialog was opened from another tab, then we check if the content prompt principal permission "focus-tab-by-prompt" is allowed for the URI the dialog was opened for and store its prompt principal on the tab prompt's `_onNextPromptShowAllowFocusCheckboxFor` property. This presence for this value is ultimately what determines whether or not the checkbox is shown. Everything after that, the prompt's UI component is responsible for handling the checkbox's state and setting a handler for setting the permission when it's checked.
Implementing this for TabDialogBox makes it so we also store the prompt principal on the dialog box. We then process this value and send some information (such as explicitly setting a `checkLabel` value) via the `args` object for common dialog to process. And finally, we set the "focus-tab-by-prompt" permission for that URI via a closing callback for the dialog.
Differential Revision: https://phabricator.services.mozilla.com/D102076
The patch for the chromium changes doesn't include the updates to
windows_version, because these are already in the release version of chromium
and so will be picked up when we next update.
Differential Revision: https://phabricator.services.mozilla.com/D103473
The dom::TypedArray type currently represents its length as uint32_t. Changing
that to size_t/uint64_t would cause problems (truncation) for many 'Length()' callers.
Instead of requiring a length check for each of those call sites, for now check for
and reject large array buffers and views in the generated bindings.
Code and tests are based on the implementation of the [AllowShared] attribute.
Additional tests for the new JSAPIs will be added as part of bug 1674777.
Differential Revision: https://phabricator.services.mozilla.com/D102912
The pref is only checked on startup and sets a process-wide flag, so that we
don't have to worry about the value changing from under us.
Differential Revision: https://phabricator.services.mozilla.com/D102911
We disabled Backspace as a keyboard shortcut to go back one page (bug 1041377). We can use the Back and Forward buttons' tooltips to advertise the other shortcuts users can use instead of Backspace (like we do on the Reload button's tooltip).
Differential Revision: https://phabricator.services.mozilla.com/D102053
Once all the remaining patches for test tweaks / fixes have landed, this
patch should be green on try. Couple test annotation changes:
* clip-003.html fails the same way it fails on mac (odd, but couldn't
repro...). I'll try to dig a bit more before calling it a day.
* radiobutton-min-size starts behaving like every other platform.
* Event-dispatch-redispatch and baseline-alignment-and-overflow start
passing.
* Couple minor fuzzy annotations (one was backwards, the other was
missing).
Differential Revision: https://phabricator.services.mozilla.com/D103327
The JS CompileOptions used to load cache entries must be consistent with
eachother to avoid subtle and serious bugs. This adds additional checks and
makes more consistent use of `FillCompileOptionsForCachedScript`.
This patch is a refactoring and should not change any behaviour.
Depends on D103515
Differential Revision: https://phabricator.services.mozilla.com/D103516
For consistency with other uses of the ScriptPreloader, we ensure we use lazy
script source when compiling for the cache. This generates full bytecode for
the cache but also avoids saving a copy of the source. If the frame script
were to call Function.prototype.toString, the existing source-hook would load
it in the same way as the JSM loader. In practice, we avoid relying on this
in our chrome code. If we will not be writing to the cache, we can instead
compile with the JS syntax parser, similar to what we do for JSM loader.
Differential Revision: https://phabricator.services.mozilla.com/D103515
Not related to the rest of this bug, I just happened to find it while looking at the generated code. It seems clang inlines a bunch of error paths which should only very rarely be taken. The patch adds hints to stop this from happening.
Depends on D103502
Differential Revision: https://phabricator.services.mozilla.com/D103503
Currently we arrange for the low thre bits of the TraceKind value be set for all trace kinds greater than seven (see definition of JS::TraceKind). This is to save a branch creating a GCCellPtr in GCCellPtr::checkedCast.
This has the side effect of generating an 80 entry lookup table when we switch on TraceKind when there are only 12 distinct trace kinds. And clang doesn't use a branch in checkCast anyway.
The patch changes TraceKind so that the values increment by one each time. This affects performance by increasing inlining opportunities in the marking code.
Depends on D103501
Differential Revision: https://phabricator.services.mozilla.com/D103502
Previously this called a separate function in another file to do the virtual dispatch. This moves the DoCallback functions to Marking.cpp and marks them inline.
Depends on D103500
Differential Revision: https://phabricator.services.mozilla.com/D103501
One thing we have to do when tracaing is udpate context information (e.g. edge name) if the tracer is a kind that requires it. It's simpler and more efficient to give all tracers this context and perform an unconditional write to the stack.
Mostly we can get away without saving/restoring context information too. This adds AutoClearTracingContext for the one place we need to do this because of nested use of the same tracer while tracing something else.
Differential Revision: https://phabricator.services.mozilla.com/D103500
Jonathan Kew
Emilio Cobos Álvarez
Glenn Watson
Barret Rennie
Micah Tigley
Tim Nguyen
Bob Owen
Mihai Alexandru Michis
Jan de Mooij
longsonr
Csoregi Natalia
Chris Peterson
Emma Malysz
stransky
Butkovits Atila
Andreea Pavel
Mats Palmgren
Narcis Beleuzu
Ted Campbell
Erica Wright
Jon Coppeard