d65ec56af99764c4370edc565668ce1ec638ee01: Bug 1539133 - Explicitly say not being able to mmap is likely OOM. r=decoder,glandium
Gian-Carlo Pascutto <gcp@mozilla.com> - Tue, 12 Nov 2019 00:04:46 +0000 - rev 501770
Push 100417 by gpascutto@mozilla.com at Wed, 13 Nov 2019 15:48:02 +0000
Bug 1539133 - Explicitly say not being able to mmap is likely OOM. r=decoder,glandium Differential Revision: https://phabricator.services.mozilla.com/D43929
b582b54b01d487a85940142585615937b7c5fbda: Bug 1595279 - disable windows10-aarch64 on mozilla-central and restrict try to --full, r=jmaher.
Bob Clary <bclary@bclary.com> - Wed, 13 Nov 2019 14:55:45 +0000 - rev 501769
Push 100416 by bclary@mozilla.com at Wed, 13 Nov 2019 15:47:06 +0000
Bug 1595279 - disable windows10-aarch64 on mozilla-central and restrict try to --full, r=jmaher. Differential Revision: https://phabricator.services.mozilla.com/D52838
72df434c8422366872d4050e9d9ba3e3121a4fbe: Bug 1596102 - Disable vismet on browsertime. r=perftest-reviewers,rwood
Gregory Mierzwinski <gmierz2@outlook.com> - Wed, 13 Nov 2019 15:36:20 +0000 - rev 501768
Push 100415 by gmierz2@outlook.com at Wed, 13 Nov 2019 15:44:51 +0000
Bug 1596102 - Disable vismet on browsertime. r=perftest-reviewers,rwood This bug disables vismet for browsertime until the png/artifact issues are resolved. Differential Revision: https://phabricator.services.mozilla.com/D52837
b10b622e1917719d0437e739bbfc3982ef0701b2: Bug 1594196 - Fix badge positioning in about:addons r=Gijs
Mark Striemer <mstriemer@mozilla.com> - Wed, 13 Nov 2019 15:31:28 +0000 - rev 501767
Push 100414 by mstriemer@mozilla.com at Wed, 13 Nov 2019 15:44:23 +0000
Bug 1594196 - Fix badge positioning in about:addons r=Gijs Differential Revision: https://phabricator.services.mozilla.com/D51924
5b224b8fe0140093a967e223c2539b3e7669ecff: Backed out changeset 09a0252278f8 (bug 1594004) for bc failures at browser_about_cache.js. CLOSED TREE
Brindusan Cristian <cbrindusan@mozilla.com> - Wed, 13 Nov 2019 17:02:20 +0200 - rev 501766
Push 100413 by cbrindusan@mozilla.com at Wed, 13 Nov 2019 15:03:30 +0000
Backed out changeset 09a0252278f8 (bug 1594004) for bc failures at browser_about_cache.js. CLOSED TREE
2475e9e1ea77d8ddeeaf8e9918d360c8f03ec8bb: Bug 1593736 - Rename ArgType_Double to ArgType_Float64. r=lth
Ryan Hunt <rhunt@eqrion.net> - Wed, 13 Nov 2019 14:43:56 +0000 - rev 501765
Push 100412 by rhunt@eqrion.net at Wed, 13 Nov 2019 14:48:31 +0000
Bug 1593736 - Rename ArgType_Double to ArgType_Float64. r=lth Also shuffle constants and add a comment for clarity. Differential Revision: https://phabricator.services.mozilla.com/D52178
23218bed721cdac05991d943fc4443a03cfc4cbd: Bug 1593736 - Give ArgType_General pointer semantics in Wasm builtin code. r=lth
Ryan Hunt <rhunt@eqrion.net> - Wed, 13 Nov 2019 14:43:43 +0000 - rev 501764
Push 100412 by rhunt@eqrion.net at Wed, 13 Nov 2019 14:48:31 +0000
Bug 1593736 - Give ArgType_General pointer semantics in Wasm builtin code. r=lth After examining bug 1591047, I believe we should have added an Int32 type instead of changing the semantics of ArgType_General to be Int32. The reason is that the existing code assumes ArgType_General is pointer sized, and changing this is scary for all the existing uses. (e.g. simulator, MacroAssembler::appendSignatureType) * Adds ArgType_Int32 * Changes ArgType_General -> ArgType_Int32, ArgType_Pointer -> ArgType_General for ABIFunctionTypes introduced in bug 1591047 (which are only used for Wasm instance calls). * ToMirType(ArgType_General) -> MIRType::Pointer (should only affect wasm) * ToMirType(ArgType_Int32) -> MIRType::Int32 (should only affect wasm) Differential Revision: https://phabricator.services.mozilla.com/D52177
b73d74bcafda125ebc57dcd59fb3dd00cacfed8c: Bug 1595285 - Do not track TRANSITION_EMBED visits for link-coloring purposes. r=mak
Emilio Cobos Álvarez <emilio@crisal.io> - Tue, 12 Nov 2019 05:06:36 +0000 - rev 501763
Push 100411 by ealvarez@mozilla.com at Wed, 13 Nov 2019 14:41:52 +0000
Bug 1595285 - Do not track TRANSITION_EMBED visits for link-coloring purposes. r=mak Other browsers don't, plus it blocks work I want to do to query multiple links at the same time. Differential Revision: https://phabricator.services.mozilla.com/D52443
ffc59a6dfbd58dcc28114acc38a7ef29f55d0aab: Bug 1595285 - Fix TestUtils.waitForCondition to not use setInterval. r=mak
Emilio Cobos Álvarez <emilio@crisal.io> - Wed, 13 Nov 2019 14:39:51 +0000 - rev 501762
Push 100410 by ealvarez@mozilla.com at Wed, 13 Nov 2019 14:40:43 +0000
Bug 1595285 - Fix TestUtils.waitForCondition to not use setInterval. r=mak The test that is timing out with these patches does something relatively simple: await TestUtils.waitForCondition(async function() { let color = await ContentTask.spawn(browserWindow, async function() { /* Do stuff... */ }); return color == something; }); await closeWindow(browserWindow); Turns out that this can intermittently leak the window due to waitForCondition using setInterval. setInterval can schedule multiple tasks while awaiting for the inner ContentTask. What this means, is that we may still have a ContentTask awaiting us when we get to close the window. Closing the window makes the ContentTask not finish, and thus we leak a promise keeping alive the window in gPromises: https://searchfox.org/mozilla-central/rev/6566d92dd46417a2f57e75c515135ebe84c9cef5/testing/mochitest/BrowserTestUtils/ContentTask.jsm#24 Which means that we keep alive the window all the way until shutdown. Fix it by ensuring that we only run one task at a time. Differential Revision: https://phabricator.services.mozilla.com/D52833
149d044837d69f645972cc10319baee944cd121b: Bug 1595657 - Add MediaQueue::Push that takes an already_AddRefed. r=jya
Michael Froman <mfroman@mozilla.com> - Tue, 12 Nov 2019 10:58:39 +0000 - rev 501761
Push 100409 by mfroman@mozilla.com at Wed, 13 Nov 2019 14:38:14 +0000
Bug 1595657 - Add MediaQueue::Push that takes an already_AddRefed. r=jya Differential Revision: https://phabricator.services.mozilla.com/D52622
70738ac7ba9b76a586cedc22ca11e02ebf659f16: Bug 1595482: change "responsiveness" field to "eventDelay" in profiler r=canaltinova
Randell Jesup <rjesup@wgate.com> - Wed, 13 Nov 2019 14:21:52 +0000 - rev 501760
Push 100408 by rjesup@wgate.com at Wed, 13 Nov 2019 14:26:17 +0000
Bug 1595482: change "responsiveness" field to "eventDelay" in profiler r=canaltinova We want the profiler UI to be able to know if the data can be used for reconstructing the event delays, since it measures something different from the old 16ms event injection. Differential Revision: https://phabricator.services.mozilla.com/D52534
be6ff7053ebe1e620a8a57af13bb6b6c11aab4a0: Bug 1593820 - [try] Create a ./mach try --pernosco flag to opt-in to the Pernosco debugging service, r=jmaher
Andrew Halberstadt <ahalberstadt@mozilla.com> - Wed, 13 Nov 2019 14:23:55 +0000 - rev 501759
Push 100407 by ahalberstadt@mozilla.com at Wed, 13 Nov 2019 14:25:29 +0000
Bug 1593820 - [try] Create a ./mach try --pernosco flag to opt-in to the Pernosco debugging service, r=jmaher This gives developers the ability to request analysis from the Pernosco service. When this flag is set, Pernosco will examine the push for relevant failures, analyze them and then send a link to the generated report. Previously developers needed to request access to a whitelist whereupon all their try pushes were analyzed. Developers currently on this whitelist who would like to opt-out can run |mach try --no-persnosco| to do so. Differential Revision: https://phabricator.services.mozilla.com/D52419
e333a13aa5f6f658c334e4553664b8df4adb5b7a: Bug 1577505 - Don't assume media element's canplay task runs immediately. r=jib
Andreas Pehrson <apehrson@mozilla.com> - Wed, 13 Nov 2019 14:02:58 +0000 - rev 501758
Push 100406 by pehrsons@gmail.com at Wed, 13 Nov 2019 14:18:52 +0000
Bug 1577505 - Don't assume media element's canplay task runs immediately. r=jib Differential Revision: https://phabricator.services.mozilla.com/D52808
7db3af2ab4045e73695595aafb07857ed05b26fc: Bug 1543156 - Wait for the addon manager to start in DevTools addons xpcshell tests r=ochameau
Julian Descottes <jdescottes@mozilla.com> - Wed, 13 Nov 2019 12:29:08 +0000 - rev 501757
Push 100405 by jdescottes@mozilla.com at Wed, 13 Nov 2019 14:18:13 +0000
Bug 1543156 - Wait for the addon manager to start in DevTools addons xpcshell tests r=ochameau Differential Revision: https://phabricator.services.mozilla.com/D52535
f11a1221a1adf18caae99adcfc4bd24a0fb44c72: Bug 1595819 - Limit the audio output channel count maximum reported value if RFP is enabled. r=tjr
Paul Adenot <paul@paul.cx> - Wed, 13 Nov 2019 12:24:11 +0000 - rev 501756
Push 100404 by padenot@mozilla.com at Wed, 13 Nov 2019 14:17:17 +0000
Bug 1595819 - Limit the audio output channel count maximum reported value if RFP is enabled. r=tjr Stereo output is what the immense majority of mobile and desktop users have. Differential Revision: https://phabricator.services.mozilla.com/D52693
b8a3793ecceb864e30b0c7d060dc9397770b1d9e: Bug 1593944 - Test to ensure inactive CSS state does not linger when dependencies change. r=miker,pbro
Razvan Caliman <rcaliman@mozilla.com> - Wed, 13 Nov 2019 13:56:50 +0000 - rev 501755
Push 100403 by rcaliman@mozilla.com at Wed, 13 Nov 2019 14:16:10 +0000
Bug 1593944 - Test to ensure inactive CSS state does not linger when dependencies change. r=miker,pbro Depends on D52560 - Adds a test to check that the steps for [Bug 1593944](https://bugzilla.mozilla.org/show_bug.cgi?id=1593944) no longer cause an issue. - Introduces a new `updateDeclaration()` helper in `devtools/client/inspector/rules/test/shared.js` to simplify updating property names and values in one step. - Updates `toggleDeclaration()` to remove unused `inspector` parameter; updates existing tests. Differential Revision: https://phabricator.services.mozilla.com/D52561
47a58584b81390485c7530b1eef7d59b2d6c32b2: Bug 1593944 - Emit event with StyleRuleActor as argument when its underlying CSS rule is updated. r=pbro
Razvan Caliman <rcaliman@mozilla.com> - Wed, 13 Nov 2019 14:04:37 +0000 - rev 501754
Push 100403 by rcaliman@mozilla.com at Wed, 13 Nov 2019 14:16:10 +0000
Bug 1593944 - Emit event with StyleRuleActor as argument when its underlying CSS rule is updated. r=pbro The fix for [Bug 1557689](https://bugzilla.mozilla.org/show_bug.cgi?id=1557689) created a situation in the [`Rule.onDeclarationsChanged()`](https://searchfox.org/mozilla-central/rev/6566d92dd46417a2f57e75c515135ebe84c9cef5/devtools/client/inspector/rules/models/rule.js#869-887) whereby the `isUsed` state of client-side declarations was made to point to a fixed `isUsed` state received from the server, thus losing sync with the latest state of the `StyleRuleActor`. Until another "declarations-update" event was fired from the `StyleRuleActor`, the rule's declarations' `isUsed` flag would point to the state with which they were overwritten on the last event handler call. As a reminder, the root cause of [Bug 1557689](https://bugzilla.mozilla.org/show_bug.cgi?id=1557689) was the inability force a "refresh" of the `StyleRuleFront` so it picked-up the latest `isUsed` state for its declarations when they depend on other declarations from other rules (ex: `justify-content: center` depends on `display:flex`). Therefore, the "declarations-updated" event was introduced with a payload of changed declarations to overwrite the client-side ones. It was convoluted, but it worked. However, while investigating the cause of this newer bug [Bug 1593944](https://bugzilla.mozilla.org/show_bug.cgi?id=1593944), I discovered an unusual but perhaps expected side-effect: when dispatching an event over the protocol with a payload of the `StyleRuleActor`, its corresponding `StyleRuleFront` on the client would "refresh" automatically (meaning that, looking up state on the previous front reference would point to the latest state from the actor) . The client doesn't even need to use this payload to replace its previous front reference. Surprisingly, the client doesn't even need to explicitly listen to the event which carries the `StyleRuleActor`/`StyleRuleFront` reference. So long as a previous reference of the front exists on the client, it will point to the updated state of the actor. I haven't been able to identify whether this is a known and expected behavior, so I'm pinging @jdescottes and @ochameau to weigh in on the validity of these findings. Relying on this behavior, the fix for both [Bug 1557689](https://bugzilla.mozilla.org/show_bug.cgi?id=1557689) and [Bug 1557689](https://bugzilla.mozilla.org/show_bug.cgi?id=1557689) involves simply emitting an event, "rule-updated", with the `StyleRuleActor` instance as payload whenever its internal state changes meaningfully so the corresponding front updates. The client will pick-up the latest `isUsed` state of declarations from its reference to the `StyleRuleFront`. --- Another way to check this behavior and hypothesis is to do the following: - In [`StyleRuleActor.setRuleText()`](https://searchfox.org/mozilla-central/rev/6566d92dd46417a2f57e75c515135ebe84c9cef5/devtools/server/actors/styles.js#1704) replace `return this` with `return null`; (this will no longer return the `StyleRuleActor` over the protocol; it's not explicitly used on the client anyway). - In the spec, replace the [`setRuleText()`](https://searchfox.org/mozilla-central/rev/6566d92dd46417a2f57e75c515135ebe84c9cef5/devtools/shared/specs/styles.js#222) return value with `RetVal("nullable:domstylerule")` so the protocol doesn't throw an error when getting the `null` from the actor. - Make a build. - Then, open the Inspector -> Rules View and change the value of a valid declaration, say: `display: block`, to something invalid, like `display: booo`. Notice that the declaration is no longer marked invalid with a warning sign. That's because the declaration's [`isValid`](https://searchfox.org/mozilla-central/rev/6566d92dd46417a2f57e75c515135ebe84c9cef5/devtools/server/actors/styles.js#1447) flag is set on the actor but it no longer syncs with the client which uses the corresponding front to render the declaration after the change. Not returning the `StyleRuleActor` over the protocol breaks this sync actor-front sync. Differential Revision: https://phabricator.services.mozilla.com/D52560
4d16c3d62cfc0503075206bccfbd3b32ad396e64: Bug 1575008 - WebGPU implementation basis r=baku,bzbarsky
Dzmitry Malyshau <dmalyshau@mozilla.com> - Wed, 13 Nov 2019 12:48:33 +0000 - rev 501753
Push 100402 by dmalyshau@mozilla.com at Wed, 13 Nov 2019 14:14:56 +0000
Bug 1575008 - WebGPU implementation basis r=baku,bzbarsky This change vendors `wgpu` library in-tree and hooks up the initialization bits. It implements adapter and device initialization and adds a simple test. Complementary ecosystem tracker - https://github.com/gfx-rs/wgpu/issues/374 Current status: - [x] Architecture - [x] figure out the IPC story - [ ] move wgpu crates into a dedicated folder (postponed as https://bugzilla.mozilla.org/show_bug.cgi?id=1594182) - [x] Linux - [x] avoid depending on spirv_cross - [x] macOS - [x] due to cross-compiling shaders - [x] need the dependency update - [x] stop using gcc - [x] unexpected SSL header collision - https://phabricator.services.mozilla.com/D51148 - [x] undefined Metal symbols - [x] missing webrtc headers for IPDL magic - https://phabricator.services.mozilla.com/D51558 - [x] spirv-cross linking failure in ASAN - https://phabricator.services.mozilla.com/D52688 - [x] Windows - [x] due to "ipc-channel" not supporting Windows yet - [x] due to some exceptional stuff - [x] undefined symbol: `D3D12CreateDevice` - [x] d3d12.dll is not found, dxgi1_4 doesn't present - [x] d3d11.dll and dxgi.dll need to be explicitly loaded on win32 mingw - [x] libbacktrace fails to link on win32 mingw - [x] cc mislinking C++ standard library - [x] Android - [x] spirv-cross fails to build due to exceptions Update-1: We decided to go with IPDL mechanism instead of Rust based ipc-channel (or any alternatives), which unblocks Windows build. Update-2: It appears that WebGPUThreading isn't needed any more as the child thread (and its event loop) is now managed by IPDL infrastructure. This PR removes it 🎉 . Update-3: InstanceProvider is also removed. Update-4: All set, the try is green, waiting for dependent changes to go in. Differential Revision: https://phabricator.services.mozilla.com/D49458
09a0252278f8bcd493345f2e05179f78f16e5a10: Bug 1594004 - Enable CacheSplit on nightly r=ckerschb,annevk
Sebastian Streich <sstreich@mozilla.com> - Wed, 13 Nov 2019 12:11:30 +0000 - rev 501752
Push 100401 by nbeleuzu@mozilla.com at Wed, 13 Nov 2019 13:49:35 +0000
Bug 1594004 - Enable CacheSplit on nightly r=ckerschb,annevk Differential Revision: https://phabricator.services.mozilla.com/D51815
35436d4e7917bf9d9b96a6173201ca001a8ff7bc: Bug 1591932 - Enable Sniffing on No Mime+ XCTO nosniff r=ckerschb
Sebastian Streich <sstreich@mozilla.com> - Wed, 13 Nov 2019 12:12:34 +0000 - rev 501751
Push 100400 by nbeleuzu@mozilla.com at Wed, 13 Nov 2019 13:48:40 +0000
Bug 1591932 - Enable Sniffing on No Mime+ XCTO nosniff r=ckerschb Differential Revision: https://phabricator.services.mozilla.com/D50816
(0) -300000 -100000 -30000 -10000 -3000 -1000 -300 -100 -50 -20 +20 +50 +100 +300 +1000 +3000 +10000 +30000 tip