This reveals an inconsistency when dragging links, where dragging the
link itself produces less mime types than dragging from the text of the
link.
I think this is just a bug, so use the parentLink code path all the
time, which allows us to simplify the code.
Differential Revision: https://phabricator.services.mozilla.com/D145604
Minor fix. This didn't check for errors when defining functions. The patch gives
it a return value and returns null if this fails.
Differential Revision: https://phabricator.services.mozilla.com/D145469
This patch adds a new menuitem to the toolbar context menu that
functions analogously to the downloads button auto-hide menuitem.
It's visible when the context menu is opened on the downloads button,
and hidden otherwise. It toggles browser.download.alwaysOpenPanel.
Also add some tests to make sure it's showing in the correct conditions
and having the correct effect in practice. While we're at it, make some
slight simplifications of related tests.
Differential Revision: https://phabricator.services.mozilla.com/D145284
For function frames, the "initial environment" includes the Call and NamedLambda
environments but never VarEnvironmentObject.
For eval frames, the initial environment is a VarEnvironmentObject, but we don't
support optimizing eval scripts yet.
This means the bailout code doesn't need to do anything special to support this,
similar to lexical environments.
Differential Revision: https://phabricator.services.mozilla.com/D145430
Some refactoring to have a function we can call for Warp. This is similar to
other environment objects.
Also remove the unused |heap| argument from create/createInternal.
Differential Revision: https://phabricator.services.mozilla.com/D145429
This is a medium sized patch to legacy download construction. It takes
advantage of the new property added in Bug 1762033 to prevent the
downloads panel from being automatically shown when a download is added
after an interaction with the unknown content type dialog or the file
picker dialog. I chose to not do the same for failed transfers since I
thought it might serve some use, but that might be wrong. I don't know
if there's a way to test the dialog that appears when you download an
executable without going through the same path I adjusted with the
patch. It seems like it's covered but I could be wrong. Also add a test
to cover these changes from the bottom up. Thanks and apologies for my
sloppy C++, though I'm sure I'll learn a lot more from the review 😅
Differential Revision: https://phabricator.services.mozilla.com/D145312
In my investigation for bug 1766439, I am digging into why selector
matching regressed.
It doesn't help that the selector-matching code is instantiated a
gazillion times (so there's a ton of copies of the relevant functions).
This was needed in the past because we had different ways of setting the
selector flags on elements, but I unified that recently and now we only
need to either set them or not. That is the kind of thing that
MatchingContext is really good for, so pass that instead on
MatchingContext creation.
Differential Revision: https://phabricator.services.mozilla.com/D145428
An almost direct translation of the JS implementation to C++. In contrast to
the JS implementation, we're using a smaller fallback to `std::sort`, because
the C++ implementation is faster, but we're also calling into `std::sort` for
large arrays to avoid allocating a large heap buffer.
As a further improvement, the radix sort implementation calls the counting sort
function for 16-bit types when the number of elements reaches `2^16`. That way
we can further reduce the number of allocated heap memory.
The pre- and post-process steps from the JS implementation can be omitted,
because we can directly interpret the TypedArray memory contents as unsigned
integers in C++.
The concurrent write access handling in `SortByColumn` is necessary to avoid
an out-of-bounds access when a different thread writes to the same shared
memory location. This was also an issue in the JS implementation, except the
only visible outcome in that implementation was that the internal `aux` array
could leak to the user.
Depends on D143286
Differential Revision: https://phabricator.services.mozilla.com/D143287
Direct translation of the JS counting sort implementation to C++. The stack
allocated buffer has inline storage to store the complete uint8_t range. (This
function will also be used in the next part for uint16_t, but in that case the
complete buffer will be heap allocated.)
The C++ implementation is faster than the JS implementation and therefore we
can use a smaller limit when we fallback to `std::sort` for small arrays.
Depends on D143285
Differential Revision: https://phabricator.services.mozilla.com/D143286
Invoke `std::sort` without a comparator function for integral types including
`uint8_clamped`. For floating point types invoke `std::sort` with a comparator
function to ensure negative zero is sorted before positive zero. To further
improve the performance when sorting floating point numbers, compare numbers
using their unsigned sort value using the same approach as currently used in
RadixSort.
When the backing buffer is a SharedArrayBuffer, we need to copy the TypedArray
contents to avoid UB in std::sort when a different thread is modifying the
same SharedArrayBuffer memory.
The next two patches in this queue will provide specialisations for
`TypedArraySort()` to select faster sort algorithms than `std::sort` for
certain TypedArray element types.
Differential Revision: https://phabricator.services.mozilla.com/D143285
This patch does the following:
1. Use `focusUpdateSubmitForm` utility function
2. Use `waitForAutofill` utility function instead of using arbitary
timeout to wait for autofill result
3. Use `openPopupForSubframe` utility function instead of only using
`synthesizeKey`. This ensures the next key event is triggered after
the popup is opened.
4. Add "autofill-clear-button" to `runAndWaitForAutocompletePopupOpen`
so "Clear Autofill Form" popup is recognized by the utility function.
Differential Revision: https://phabricator.services.mozilla.com/D144878
This test isn't entirely interoperable, but in the spots where other engines
disagree with Gecko, I'm pretty sure it's due to bugs on their end, and I've
filed bugs which I've linked in the test. Out of caution, though, I've named
the test filename with ".tentative" due to the lack of full interop and due to
the CSS2 spec's ambiguity around precise float wrapping behavior. The
reference case is based on Gecko's current behavior, in any case.
Differential Revision: https://phabricator.services.mozilla.com/D145531
The margins in this test aren't more-negative than the available space, so they
don't "pump up" the BFC's border-box enough to force it to wrap to a new line.
Firefox and Chromium agree on this testcase, but WebKit does not, per
https://bugs.webkit.org/show_bug.cgi?id=239976
Given that this is a vaguely-specced area, I'm naming the test with
".tentative" at this point.
Depends on D145197
Differential Revision: https://phabricator.services.mozilla.com/D145530
Note: The WPT test included in this test is intended to excercise cases that
are (newly) interoperable between WebKit, Blink, and Gecko (with this patch).
There are other related cases where browsers still disagree; I'll add
additional WPT tests for those cases in a later patch in this series.
Differential Revision: https://phabricator.services.mozilla.com/D145159
Neil Deakin
Iulian Moraru
Emilio Cobos Álvarez
Jon Coppeard
Kagami Sascha Rosylight
Csoregi Natalia
lyavor
Kershaw Chang
Shane Hughes
Jan de Mooij
criss
Amy Churchwell
André Bargull
Mathew Hodson
Mozilla Releng Treescript
Dimi
Daniel Holbert