This should be the minimal patch to fix the issue (should be safe for branches too).
Reusing an existing mouse/touch test for the crash testing.
Differential Revision: https://phabricator.services.mozilla.com/D34717
--HG--
extra : moz-landing-system : lando
This is a bit gross, but it passes all the tests that were not already failing.
Differential Revision: https://phabricator.services.mozilla.com/D29057
--HG--
extra : moz-landing-system : lando
We are changing the representation of values on 64-bit. Part 5 of this patch stack has more details on the changes.
Differential Revision: https://phabricator.services.mozilla.com/D29056
--HG--
extra : moz-landing-system : lando
This patch is where the actual changes to our value representation happens. A few notes:
1. We did some weird macro tricks to work around a GCC bug with enums in bitfields. Those bitfields were only useful for poking at values in gdb, and the trick no longer worked with object-biased nanboxing, so I removed it. I also got rid of asDouble_, because it's no longer possible to read the double value right out of the enum without unboxing.
2. In the previous boxing scheme, there was a mechanical conversion between a JSValueType and a JSValueTag. That's no longer true, which is why the big conversion switches exist.
3. Waldo, you were included as a reviewer specifically to look at Value.h and make sure that our gross bit twiddling is just gross and not undefined.
Differential Revision: https://phabricator.services.mozilla.com/D29055
--HG--
extra : moz-landing-system : lando
Similarly to Part 3: when we push a double value, we currently don't distinguish between pushing a boxed double and pushing an unboxed double. This has to change for object-biased NaN-boxing.
Differential Revision: https://phabricator.services.mozilla.com/D29054
--HG--
extra : moz-landing-system : lando
In the past, we have been somewhat sloppy when storing / loading double values, because a boxed double and an unboxed double had the same representation. This is no longer true with object-biased NaN-boxing. This patch goes through and cleans up those cases.
Differential Revision: https://phabricator.services.mozilla.com/D29053
--HG--
extra : moz-landing-system : lando
It took me a while to convince myself that this code was still okay for 0-tagged object Values. Adding a comment to make it clearer for future readers (and in the hope that a reviewer will notice my mistake if I am wrong.)
Differential Revision: https://phabricator.services.mozilla.com/D29052
--HG--
extra : moz-landing-system : lando
Using the old NaN-boxing scheme, a zero-initialized value was a double, which was safe to trace. Under the new scheme, it is a null object pointer.
This patch manually initializes Value arrays to Undefined.
Differential Revision: https://phabricator.services.mozilla.com/D29051
--HG--
extra : moz-landing-system : lando
Since the media element is playing directly after play(), not waiting for the
readyState to advance before play()ing could leave the play promise from play()
unhandled until cleanup, when it would be rejected by the load algorithm.
This would happen if a timeupdate event is raised before the first frame comes
in to update the readyState, which resolves the play promise.
Waiting for the readyState to advance before play()ing seems like the cleanest
fix wrt testing currentTime after the first timeupdate event.
Depends on D33655
Differential Revision: https://phabricator.services.mozilla.com/D34686
--HG--
extra : moz-landing-system : lando
This FireTimeUpdate(false) dates back to bug 611994. Perhaps it was spec
compliant back in the day, but it surely isn't now.
Differential Revision: https://phabricator.services.mozilla.com/D33651
--HG--
extra : moz-landing-system : lando
Bug 1279865 introduced this under the premise of
"Run TimeMarchesOn() at the beginning of play.", but it did a bit too much.
This makes us spec compliant for this particular case again.
Differential Revision: https://phabricator.services.mozilla.com/D33650
--HG--
extra : moz-landing-system : lando
This does several things:
- Split the test up, so one assert doesn't fail the entire test suite
- Check preload, playbackRate and defaultPlaybackRate attributes after unsetting srcObject
- Check setting currentTime before loading (default playback start position),
and after loading (official playback position) separately
- Check that duration is changed to a real number on ending
- Check that HAVE_ENOUGH_DATA is reached by only assigning srcObject
- And other minor things and formatting
Differential Revision: https://phabricator.services.mozilla.com/D33647
--HG--
extra : moz-landing-system : lando
Autofill only when the user enters text -- i.e., when event.data in _on_input is non-empty. That allows us to simplify autofill quite a bit. We can get rid of the edit action listener that we previously used to detect selection deletion, and we also don't need the prefix check (lastSearchStartsWithNewSearch).
Therefore this fixes both this bug (bug 1557555) and bug 1545731/719888.
This makes one other change: We can check event.inputType in _on_input to tell whether the user is pasting, rather than keeping a _valueIsPasted property that we set in _on_paste.
Differential Revision: https://phabricator.services.mozilla.com/D34645
--HG--
extra : moz-landing-system : lando
Fixes test 'accessible/tests/mochitest/relations/test_general.xul' when
loaded as XHTML.
Differential Revision: https://phabricator.services.mozilla.com/D34655
--HG--
extra : moz-landing-system : lando
This is a bit gross, but it passes all the tests that were not already failing.
Differential Revision: https://phabricator.services.mozilla.com/D29057
--HG--
extra : moz-landing-system : lando
We are changing the representation of values on 64-bit. Part 5 of this patch stack has more details on the changes.
Differential Revision: https://phabricator.services.mozilla.com/D29056
--HG--
extra : moz-landing-system : lando
This patch is where the actual changes to our value representation happens. A few notes:
1. We did some weird macro tricks to work around a GCC bug with enums in bitfields. Those bitfields were only useful for poking at values in gdb, and the trick no longer worked with object-biased nanboxing, so I removed it. I also got rid of asDouble_, because it's no longer possible to read the double value right out of the enum without unboxing.
2. In the previous boxing scheme, there was a mechanical conversion between a JSValueType and a JSValueTag. That's no longer true, which is why the big conversion switches exist.
3. Waldo, you were included as a reviewer specifically to look at Value.h and make sure that our gross bit twiddling is just gross and not undefined.
Differential Revision: https://phabricator.services.mozilla.com/D29055
--HG--
extra : moz-landing-system : lando
Similarly to Part 3: when we push a double value, we currently don't distinguish between pushing a boxed double and pushing an unboxed double. This has to change for object-biased NaN-boxing.
Differential Revision: https://phabricator.services.mozilla.com/D29054
--HG--
extra : moz-landing-system : lando
In the past, we have been somewhat sloppy when storing / loading double values, because a boxed double and an unboxed double had the same representation. This is no longer true with object-biased NaN-boxing. This patch goes through and cleans up those cases.
Differential Revision: https://phabricator.services.mozilla.com/D29053
--HG--
extra : moz-landing-system : lando
It took me a while to convince myself that this code was still okay for 0-tagged object Values. Adding a comment to make it clearer for future readers (and in the hope that a reviewer will notice my mistake if I am wrong.)
Differential Revision: https://phabricator.services.mozilla.com/D29052
--HG--
extra : moz-landing-system : lando
Using the old NaN-boxing scheme, a zero-initialized value was a double, which was safe to trace. Under the new scheme, it is a null object pointer.
This patch manually initializes Value arrays to Undefined.
Differential Revision: https://phabricator.services.mozilla.com/D29051
--HG--
extra : moz-landing-system : lando
Update the tests for ARM64 to include additional functions that are now
supported via 4 byte patching.
We also convert the TEST macros to accept the DLL names as strings, as this
works better with clang-format.
Differential Revision: https://phabricator.services.mozilla.com/D32209
--HG--
extra : moz-landing-system : lando
This patch modifies arm64 so that detours are peformed via two passes:
1. The first pass uses a null trampoline to count how many bytes are available
for patching the original function.
2. If we have >= 16 bytes to patch, we reuse existing trampoline space. If we
have less than 16 bytes to patch, we reserve trampoline space within 128MB
of the function, allowing for a 4 byte patch.
3. Then we recurse, this time using a real trampoline.
Note that we still do a single-pass on x86(-64).
Differential Revision: https://phabricator.services.mozilla.com/D32193
--HG--
extra : moz-landing-system : lando
A null trampoline is just a trampoline that is not backed by a VM reservation.
These are used for tracking the number of bytes that are needed to make a patch.
This patch also contains the changes needed to work with TrampolinePool.
Differential Revision: https://phabricator.services.mozilla.com/D32192
--HG--
extra : moz-landing-system : lando
VMSharingPolicyShared needs to become much smarter. This patch modifies that
policy to track different VM reservations and reuse them whenever possible.
We add TrampolinePools to abstract away the differences between VM policies
with respect to the caller who is making the reservation.
Differential Revision: https://phabricator.services.mozilla.com/D32191
--HG--
extra : moz-landing-system : lando
In order to support 4-byte patches on ARM64, we need to be able to reserve
trampoline space within +/- 128 MB of the beginning of a function.
These changes allow us to make such reservations using OS APIs when
available.
Differential Revision: https://phabricator.services.mozilla.com/D32190
--HG--
extra : moz-landing-system : lando
This must have been broken while addressing review comments in Bug 1548841,
the first commit has it right and the last commit in the series breaks it.
Since we don't yet generate mDNS addresses in Firefox, the unit tests would not
catch this problem, and interoperability with other browsers would continue to
work due to peer reflex candidates.
We will have test coverage for this once we land generating our own mDNS
candidates. ICE will fail in the mochitests if we don't support resolving
mDNS addresses properly, which is how I discovered this bug.
Differential Revision: https://phabricator.services.mozilla.com/D34579
--HG--
extra : moz-landing-system : lando