In the preSummary function TmpVal was being checked before it could be set
causing the test to always fail.
Differential Revision: https://phabricator.services.mozilla.com/D18601
--HG--
extra : moz-landing-system : lando
Created an exception in the key event suppression mechanism for the back button KEYCODE.
Differential Revision: https://phabricator.services.mozilla.com/D33950
--HG--
extra : moz-landing-system : lando
IsCanonical was only used in StructuredCloneReader::CheckDouble. Two of CheckDouble's three uses already canonicalized the double before checking it, and the third *should* have already done so.
Differential Revision: https://phabricator.services.mozilla.com/D29870
--HG--
extra : moz-landing-system : lando
Back when we first freed the lizard in 1998, it made sense to have copies of NaN/+Inf/-Inf living on the runtime, because Values didn't store doubles inline. That hasn't been true for a long time. This patch gets rid of those.
Differential Revision: https://phabricator.services.mozilla.com/D29868
--HG--
extra : moz-landing-system : lando
We can't generate a constexpr uint64_t containing the bits for positive/negative infinity, because of a (very sensible) static_assert in SpecificNaNBits. This patch adds support to FloatingPoint.h for infinity. The next patch will use it to make JS::InfinityValue constexpr (to match JS::NaNValue).
Differential Revision: https://phabricator.services.mozilla.com/D29869
--HG--
extra : moz-landing-system : lando
1. CanonicalizedDoubleValue should reuse the logic in CanonicalizeNaN.
2. Places that call DoubleValue(CanonicalizeNaN(d)) should just use CanonicalizedDoubleValue(d).
Differential Revision: https://phabricator.services.mozilla.com/D29867
--HG--
extra : moz-landing-system : lando
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
