f7c04ba4c7a635693702ebf286c26b4d9e0dca84: Bug 1657830 part 3 - Remove dead JumpRelocation struct on ARM64. r=tcampbell
Jan de Mooij <jdemooij@mozilla.com> - Fri, 07 Aug 2020 19:35:08 +0000 - rev 544384
Push 124001 by jdemooij@mozilla.com at Wed, 12 Aug 2020 08:50:03 +0000
Bug 1657830 part 3 - Remove dead JumpRelocation struct on ARM64. r=tcampbell Depends on D86370 Differential Revision: https://phabricator.services.mozilla.com/D86372
b05b003aadab616dfcc586f2d3a1559ef971e0e8: Bug 1657830 part 2 - Remove dead addPatchableJump on ARM64 and x64. r=tcampbell
Jan de Mooij <jdemooij@mozilla.com> - Fri, 07 Aug 2020 19:18:19 +0000 - rev 544383
Push 124001 by jdemooij@mozilla.com at Wed, 12 Aug 2020 08:50:03 +0000
Bug 1657830 part 2 - Remove dead addPatchableJump on ARM64 and x64. r=tcampbell All pending jumps then have a known (non-null) target, so replace an if-statement with an assertion. Other platforms don't define addPatchableJump. Depends on D86368 Differential Revision: https://phabricator.services.mozilla.com/D86370
40177251aedfccc2a0e0d776d1b8cb2c45102707: Bug 1657830 part 1 - Remove some never-used data from jump relocation table on ARM64 and x64. r=tcampbell
Jan de Mooij <jdemooij@mozilla.com> - Fri, 07 Aug 2020 17:50:24 +0000 - rev 544382
Push 124001 by jdemooij@mozilla.com at Wed, 12 Aug 2020 08:50:03 +0000
Bug 1657830 part 1 - Remove some never-used data from jump relocation table on ARM64 and x64. r=tcampbell The jump instruction itself is sufficient to get the address from the extended jump table. This has been 'dead' code on x64 since the code landed in 2011. ARM64 copied it. Differential Revision: https://phabricator.services.mozilla.com/D86368
13c2bda8cb38a6e5d8004483427c582859ceaf0d: Bug 561154 - Implement :-moz-any() as an alias of :is(). r=heycam
Emilio Cobos Álvarez <emilio@crisal.io> - Wed, 12 Aug 2020 04:26:07 +0000 - rev 544381
Push 124000 by ealvarez@mozilla.com at Wed, 12 Aug 2020 08:22:52 +0000
Bug 561154 - Implement :-moz-any() as an alias of :is(). r=heycam This is strictly better and more flexible, but can change specificity so have a pref in case it causes trouble. I doubt it will though, the specificity rules of :is() make more sense, and my gut feeling is that :-moz-any is not very used on the wild. Make it early-beta-or-earlier for now to minimize risk, once this is on nightly for a bit we can enable it everywhere. Differential Revision: https://phabricator.services.mozilla.com/D86696
67723f68d22c21654ccacfabd15b29ceaa578aff: Bug 1658386 - add support for arm64 macOS WASM signal handling. r=lth
Mike Hommey <mh+mozilla@glandium.org> - Wed, 12 Aug 2020 08:07:10 +0000 - rev 544380
Push 123999 by mh@glandium.org at Wed, 12 Aug 2020 08:22:25 +0000
Bug 1658386 - add support for arm64 macOS WASM signal handling. r=lth Differential Revision: https://phabricator.services.mozilla.com/D86802
c19dcb11b94077f23bf41515a0c2584406823815: Bug 1647288 - Handle NaN in SIMD min, max: Code. r=jseward
Lars T Hansen <lhansen@mozilla.com> - Wed, 12 Aug 2020 07:50:45 +0000 - rev 544379
Push 123998 by lhansen@mozilla.com at Wed, 12 Aug 2020 08:21:24 +0000
Bug 1647288 - Handle NaN in SIMD min, max: Code. r=jseward This adds correct NaN handling to the SIMD f32x4/f64x2.min/max code. This is a bit of a horror show actually. There is a reasonable fast path if neither operand contains a NaN, but the slow path to handle NaN is long and there's a lot of code. (This is an Intel-only problem, on other architectures there's a direct mapping.) It is possible the slow-path code could be somewhat improved (both speed and size) by using at least three BLEND instructions, but I consider that a possible optimization that needs investigation and empirical backing. Meanwhile, we can land this plausible code. Differential Revision: https://phabricator.services.mozilla.com/D86318
bfd5e17cb4d0919f4002a490347d70d7cf65f365: Bug 1647288 - Handle signalling NaN generally: Test cases. r=jseward
Lars T Hansen <lhansen@mozilla.com> - Wed, 12 Aug 2020 07:50:23 +0000 - rev 544378
Push 123998 by lhansen@mozilla.com at Wed, 12 Aug 2020 08:21:24 +0000
Bug 1647288 - Handle signalling NaN generally: Test cases. r=jseward Wasm treats signalling and quiet NaN the same - as quiet NaN. Where convenient, test also signalling NaN. This is complicated by JS not being able to represent signalling NaN directly. Differential Revision: https://phabricator.services.mozilla.com/D86317
64e82366834a3c20d571e082be358c042f2c8b2e: Bug 1647288 - Handle NaN in SIMD min, max: Generated test cases. r=jseward
Lars T Hansen <lhansen@mozilla.com> - Wed, 12 Aug 2020 07:50:15 +0000 - rev 544377
Push 123998 by lhansen@mozilla.com at Wed, 12 Aug 2020 08:21:24 +0000
Bug 1647288 - Handle NaN in SIMD min, max: Generated test cases. r=jseward These test cases were generated by a script from some of the preliminary test cases in the SIMD spec repository, taking into account the specific NaN types asked for. These tests are temporary: once we have proper generated test cases from the spec repository, these will no longer be needed. Differential Revision: https://phabricator.services.mozilla.com/D86316
a6d240ef908b37bf509c46676bd70831174d2102: Bug 1657628 - Fix bugs in some ad-hack simd tests. r=jseward
Lars T Hansen <lhansen@mozilla.com> - Wed, 12 Aug 2020 07:50:07 +0000 - rev 544376
Push 123998 by lhansen@mozilla.com at Wed, 12 Aug 2020 08:21:24 +0000
Bug 1657628 - Fix bugs in some ad-hack simd tests. r=jseward Two bugs: - an accidental redefinition of the 'eq' predicate resulted in the 'permute' function not working and thus in us not testing floating point operations for NaN, Infinity, and some other interesting values. - the previous bug masked the fact that the max and min operations for floating point were not implemented properly; they have to handle NaN specially. Differential Revision: https://phabricator.services.mozilla.com/D86315
2e7ddb00c8f9240e148cf5843b50a7ba7b913351: Bug 1656226 - Implement the experimental opcodes. r=jseward
Lars T Hansen <lhansen@mozilla.com> - Wed, 12 Aug 2020 07:50:00 +0000 - rev 544375
Push 123998 by lhansen@mozilla.com at Wed, 12 Aug 2020 08:21:24 +0000
Bug 1656226 - Implement the experimental opcodes. r=jseward Implement some of the experimental SIMD opcodes that are supported by all of V8, LLVM, and Binaryen, for maximum compatibility with test content we might be exposed to. Most/all of these will probably make it into the spec, as they lead to substantial speedups in some programs, and they are deterministic. For spec and cpu mapping details, see: https://github.com/WebAssembly/simd/pull/122 (pmax/pmin) https://github.com/WebAssembly/simd/pull/232 (rounding) https://github.com/WebAssembly/simd/pull/127 (dot product) https://github.com/WebAssembly/simd/pull/237 (load zero) The wasm bytecode values used here come from the binaryen changes that are linked from those tickets, that's the best documentation right now. Current binaryen opcode mappings are here: https://github.com/WebAssembly/binaryen/blob/master/src/wasm-binary.h Also: Drive-by fix for signatures of vroundss and vroundsd, these are unary operations and should follow the conventions for these with src/dest arguments, not src0/src1/dest. Also: Drive-by fix to add variants of vmovss and vmovsd on x64 that take Operand source and FloatRegister destination. Differential Revision: https://phabricator.services.mozilla.com/D85982
656340534354efba26af4ffde4e17a4a33eea2b8: Bug 1656216 - Improve SIMD test cases. r=jseward
Lars T Hansen <lhansen@mozilla.com> - Wed, 12 Aug 2020 07:49:12 +0000 - rev 544374
Push 123998 by lhansen@mozilla.com at Wed, 12 Aug 2020 08:21:24 +0000
Bug 1656216 - Improve SIMD test cases. r=jseward This fleshes out the test cases to cover some corner cases that were left uncovered before. No errors were found. Differential Revision: https://phabricator.services.mozilla.com/D85981
6a2b9be4ce0097d0d137e2184ec4576328ee292c: Backed out 2 changesets (bug 1657582) for test_DNSLookup.js failures CLOSED TREE
Bogdan Tara <btara@mozilla.com> - Wed, 12 Aug 2020 11:18:06 +0300 - rev 544373
Push 123997 by btara@mozilla.com at Wed, 12 Aug 2020 08:19:49 +0000
Backed out 2 changesets (bug 1657582) for test_DNSLookup.js failures CLOSED TREE Backed out changeset 784122a5f5ab (bug 1657582) Backed out changeset 0f17312b01ad (bug 1657582)
6e2551ab206bb2f30f65e12d6c619e48bb277ebd: Backed out 5 changesets (bug 1657521) for assertion failure at Refs.h CLOSED TREE
Bogdan Tara <btara@mozilla.com> - Wed, 12 Aug 2020 11:14:44 +0300 - rev 544372
Push 123997 by btara@mozilla.com at Wed, 12 Aug 2020 08:19:49 +0000
Backed out 5 changesets (bug 1657521) for assertion failure at Refs.h CLOSED TREE Backed out changeset a0f450666c5b (bug 1657521) Backed out changeset e97937bf5e3a (bug 1657521) Backed out changeset 8d70f3cb5e3b (bug 1657521) Backed out changeset 5c3c1ec039d2 (bug 1657521) Backed out changeset 132eb437fdda (bug 1657521)
547bd3a15586f6a2cec66e3a45023265b55e1619: Bug 1590019 - Make the styling of placeholder text in the Debugger consistent r=nchevobbe
Kyle Knaggs <kyleknaggs@gmail.com> - Wed, 12 Aug 2020 07:25:16 +0000 - rev 544371
Push 123996 by nchevobbe@mozilla.com at Wed, 12 Aug 2020 07:27:57 +0000
Bug 1590019 - Make the styling of placeholder text in the Debugger consistent r=nchevobbe Before this change the styling of the inputs in the Debugger was inconsistent. This patch addresses this issue by: 1. Modifying the appearance of the placeholder text by setting its `color` to `--theme-text-color-alt` and its `opacity` to `1`. This ensures that the placeholder text has a contrast ratio of 4.74 when paired with a white background and passes the 4.5:1 contrast requirement of WCAG. 2. Modifying the height of the inputs in the Primary and Secondary Panes so that they are all `24px`. {F2406940} Differential Revision: https://phabricator.services.mozilla.com/D85630
784122a5f5ab31e638dbb030399aa7eadcecbba3: Bug 1657582 - Add nsIDNSAddrRecord interface r=necko-reviewers,geckoview-reviewers,snorp,mixedpuppy,dragana
Valentin Gosu <valentin.gosu@gmail.com> - Wed, 12 Aug 2020 01:35:10 +0000 - rev 544370
Push 123995 by valentin.gosu@gmail.com at Wed, 12 Aug 2020 07:19:49 +0000
Bug 1657582 - Add nsIDNSAddrRecord interface r=necko-reviewers,geckoview-reviewers,snorp,mixedpuppy,dragana This interface extends nsIDNSRecord and makes the DNS code more extensible by allowing us to support more record types. This change does require the consumer to be aware of the type they requested and to QueryInterface to either nsIDNSAddrRecord for regular IP lookups, or to nsIDNSByTypeRecord for other kinds of lookups. Differential Revision: https://phabricator.services.mozilla.com/D86177
0f17312b01adca7d9d7032cce5f1d1170d424302: Bug 1657582 - Add nsIDNSResolverInfo interface r=necko-reviewers,geckoview-reviewers,snorp,mixedpuppy,extension-reviewers,dragana
Valentin Gosu <valentin.gosu@gmail.com> - Wed, 12 Aug 2020 01:00:39 +0000 - rev 544369
Push 123995 by valentin.gosu@gmail.com at Wed, 12 Aug 2020 07:19:49 +0000
Bug 1657582 - Add nsIDNSResolverInfo interface r=necko-reviewers,geckoview-reviewers,snorp,mixedpuppy,extension-reviewers,dragana This patch adds the nsIDNSResolverInfo interface which is used to hold information about the resolver to be used in a DNS resolution. We use this to merge all of the *WithTRRServer resolve functions into one. Passing a resolver info will use that object when appropriate. No resolver info means that we default to using the system resolver, or the default TRR resolver. This patch also converts the RESOLVE_TYPE_* flags into a cenum and adds the resolveType as a parameter to asyncResolve thus removing the need to have asyncResolveByType methods. Differential Revision: https://phabricator.services.mozilla.com/D86176
203dd164f9cace9472671d4f63350c31f856ecb0: Bug 1631722 - Add wrapper for structured-headers crate,r=valentin
undef1nd <yalyna.ts@gmail.com> - Wed, 12 Aug 2020 07:07:33 +0000 - rev 544368
Push 123994 by valentin.gosu@gmail.com at Wed, 12 Aug 2020 07:12:30 +0000
Bug 1631722 - Add wrapper for structured-headers crate,r=valentin Differential Revision: https://phabricator.services.mozilla.com/D81127
cfa1f8e3a900ae38338c1041159cd6d36afde32c: Bug 1631722 - Vendor sfv crate,r=valentin
undef1nd <yalyna.ts@gmail.com> - Wed, 12 Aug 2020 07:07:00 +0000 - rev 544367
Push 123994 by valentin.gosu@gmail.com at Wed, 12 Aug 2020 07:12:30 +0000
Bug 1631722 - Vendor sfv crate,r=valentin *** Vendor Differential Revision: https://phabricator.services.mozilla.com/D83502
5e401631f3ef750246698f5a3ebb1e608fd9a160: Bug 1655026 [Linux] Enable WebGL DMABuf backend for X11/EGL, r=jgilbert
Martin Stransky <stransky@redhat.com> - Wed, 12 Aug 2020 07:01:54 +0000 - rev 544366
Push 123993 by btara@mozilla.com at Wed, 12 Aug 2020 07:07:05 +0000
Bug 1655026 [Linux] Enable WebGL DMABuf backend for X11/EGL, r=jgilbert Differential Revision: https://phabricator.services.mozilla.com/D84901
bd9655461cbce5a309ba79ec6ab5cb71855356b2: Bug 1658001. Populate wheelEvent.mLineOrPageDeltaY in PinchGestureInput::ToWidgetWheel for pinch gestures produced from direct manipulation. r=kats
Timothy Nikkel <tnikkel@gmail.com> - Tue, 11 Aug 2020 09:08:06 +0000 - rev 544365
Push 123992 by tnikkel@mozilla.com at Wed, 12 Aug 2020 07:00:48 +0000
Bug 1658001. Populate wheelEvent.mLineOrPageDeltaY in PinchGestureInput::ToWidgetWheel for pinch gestures produced from direct manipulation. r=kats We do this analogously to how PanGestureInput does it except that the delta's that we compute mLineOrPageDeltaY from are computed by us instead of provided to us. mLineOrPageDeltaY being non-zero is what EventStateManager::DispatchLegacyMouseScrollEvents uses to decide to send legacy mouse events, so we need to populate it to get those legacy events to send. This fix is Windows only on purpose as pinches on macOS don't seem to send wheel events (Windows sends ctrl+wheel). When Linux gets implemented it will need to be determined what to do. Differential Revision: https://phabricator.services.mozilla.com/D86495
(0) -300000 -100000 -30000 -10000 -3000 -1000 -300 -100 -50 -20 +20 +50 +100 +300 +1000 +3000 +10000 +30000 tip