searching for reviewer(Nika)
f9ab4049b714471f4979545c338789a2d84cb186: Bug 1565927 - Default FrameCrashedEvent's isTopFrame to true if never set. r=nika a=RyanVM
Mike Conley <mconley@mozilla.com> - Wed, 17 Jul 2019 01:50:04 +0000 - rev 541465
Push 11618 by dvarga@mozilla.com at Mon, 22 Jul 2019 16:58:11 +0000
Bug 1565927 - Default FrameCrashedEvent's isTopFrame to true if never set. r=nika a=RyanVM This is the safer assumption, since we normally skip setting isTopFrame explicitly if no BrowsingContext exists (which is the case if, for example, the crash is due to the fact that creating the top-level browser failed). Differential Revision: https://phabricator.services.mozilla.com/D38119
195538371838a1bc539eeb5e0eecc4d534fcdd64: Bug 1550637 - hide tooltip when the docshell navigate, don't show tooltips if the docshell is no longer active, r=nika,dao a=RyanVM
Gijs Kruitbosch <gijskruitbosch@gmail.com> - Tue, 16 Jul 2019 07:48:23 +0000 - rev 541434
Push 11607 by nerli@mozilla.com at Thu, 18 Jul 2019 14:12:34 +0000
Bug 1550637 - hide tooltip when the docshell navigate, don't show tooltips if the docshell is no longer active, r=nika,dao a=RyanVM Differential Revision: https://phabricator.services.mozilla.com/D35503
e0a81e0687285f20853b5a5494d0c34ae5acdf1b: Bug 1563997: Handle webcompat Components stub in MozillaFileLogger.js. r=nika a=test-only
Kris Maglione <maglione.k@gmail.com> - Fri, 12 Jul 2019 14:32:57 -0700 - rev 541358
Push 11583 by maglione.k@gmail.com at Mon, 15 Jul 2019 17:28:13 +0000
Bug 1563997: Handle webcompat Components stub in MozillaFileLogger.js. r=nika a=test-only Differential Revision: https://phabricator.services.mozilla.com/D37938
266160ca8e9d27918623f096cde1a6f998e8900c: Bug 1561999: Initiate window.open() loads for cross-process URLs in the calling process under Fission. r=nika
Kris Maglione <maglione.k@gmail.com> - Thu, 27 Jun 2019 12:22:12 -0700 - rev 540936
Push 11533 by archaeopteryx@coole-files.de at Mon, 08 Jul 2019 18:18:03 +0000
Bug 1561999: Initiate window.open() loads for cross-process URLs in the calling process under Fission. r=nika When Fission is enabled, the load will be retargeted to the correct process automatically, and will in the mean time give callers access to an about:blank document as required by the spec. Differential Revision: https://phabricator.services.mozilla.com/D36242
00e935828f418b46a391c3b47bb53163ce91247a: Bug 1561724: Correctly support exposing remote frames by name. r=nika
Kris Maglione <maglione.k@gmail.com> - Wed, 26 Jun 2019 13:35:55 -0700 - rev 540935
Push 11533 by archaeopteryx@coole-files.de at Mon, 08 Jul 2019 18:18:03 +0000
Bug 1561724: Correctly support exposing remote frames by name. r=nika Differential Revision: https://phabricator.services.mozilla.com/D36083
6644e38a669212b4e933cdb0a5f3badf6cba0b5f: Bug 1561150: Support test assertions in SpecialPowers.spawn sandboxes. r=nika
Kris Maglione <maglione.k@gmail.com> - Mon, 24 Jun 2019 19:25:33 -0700 - rev 540933
Push 11533 by archaeopteryx@coole-files.de at Mon, 08 Jul 2019 18:18:03 +0000
Bug 1561150: Support test assertions in SpecialPowers.spawn sandboxes. r=nika Differential Revision: https://phabricator.services.mozilla.com/D35747
f0bac27bad8a6541611fb0cf59f666b45c574cc2: Bug 1560400: Part 3 - Update DocShell frame navigation tests to support remote frames. r=nika
Kris Maglione <maglione.k@gmail.com> - Thu, 20 Jun 2019 14:30:47 -0700 - rev 540931
Push 11533 by archaeopteryx@coole-files.de at Mon, 08 Jul 2019 18:18:03 +0000
Bug 1560400: Part 3 - Update DocShell frame navigation tests to support remote frames. r=nika The tests still fail under Fission, because the mechanisms they use to navigate the frames don't work, but at least the checks for whether the navigation succeeded now do. That means the tests should start passing when the necessary APIs become Fission-compatible. Differential Revision: https://phabricator.services.mozilla.com/D35473
95da39224eab4e9aa1352c2d1d9288f458a89ab5: Bug 1560400: Part 1 - Support remote frames in Window indexed getters. r=nika
Kris Maglione <maglione.k@gmail.com> - Thu, 20 Jun 2019 13:52:55 -0700 - rev 540930
Push 11533 by archaeopteryx@coole-files.de at Mon, 08 Jul 2019 18:18:03 +0000
Bug 1560400: Part 1 - Support remote frames in Window indexed getters. r=nika Differential Revision: https://phabricator.services.mozilla.com/D35471
3fe4d4942fd20b0e81425e90a57c33238f814844: Bug 1532795: Part 5 - Support SpecialPowers.spawn on WindowProxy objects. r=nika
Kris Maglione <maglione.k@gmail.com> - Wed, 19 Jun 2019 13:07:14 -0700 - rev 540929
Push 11533 by archaeopteryx@coole-files.de at Mon, 08 Jul 2019 18:18:03 +0000
Bug 1532795: Part 5 - Support SpecialPowers.spawn on WindowProxy objects. r=nika Differential Revision: https://phabricator.services.mozilla.com/D35378
23e90c6fec2be482ed33cddcd09f5dfe11de2df1: Bug 1532795: Part 4 - Add helper to get BrowsingContext from WindowProxy. r=nika
Kris Maglione <maglione.k@gmail.com> - Wed, 19 Jun 2019 13:06:32 -0700 - rev 540928
Push 11533 by archaeopteryx@coole-files.de at Mon, 08 Jul 2019 18:18:03 +0000
Bug 1532795: Part 4 - Add helper to get BrowsingContext from WindowProxy. r=nika Differential Revision: https://phabricator.services.mozilla.com/D35377
a7f093fbef061b89cd1b9b3c166d76e59256340c: Bug 1532795: Part 3 - Update random test to use SpecialPowers.spawn for cross-process iframe access. r=nika
Kris Maglione <maglione.k@gmail.com> - Tue, 18 Jun 2019 20:49:35 -0700 - rev 540927
Push 11533 by archaeopteryx@coole-files.de at Mon, 08 Jul 2019 18:18:03 +0000
Bug 1532795: Part 3 - Update random test to use SpecialPowers.spawn for cross-process iframe access. r=nika Differential Revision: https://phabricator.services.mozilla.com/D35297
c873f0eb94be3ec8f6592020f76f2d7a1a20c3a6: Bug 1532795: Part 2 - Implement basic SpecialPowers.spawn as a replacement for ContentTask. r=nika
Kris Maglione <maglione.k@gmail.com> - Tue, 18 Jun 2019 16:21:49 -0700 - rev 540926
Push 11533 by archaeopteryx@coole-files.de at Mon, 08 Jul 2019 18:18:03 +0000
Bug 1532795: Part 2 - Implement basic SpecialPowers.spawn as a replacement for ContentTask. r=nika With out-of-process iframes, we'll need similar functionality to the ContentTask helpers that can be used in any process, with any type of frame. Using ContentTask directly in unprivileged contexts will, I think, be a bit too combersome given how often it's needed, so this patch adds an API directly to SpecialPowers instead. The environment provided to the task is currently pretty basic, and doesn't provide the assertion helpers currently available to ContentTask tasks, but it can grow as we find it necessary. Differential Revision: https://phabricator.services.mozilla.com/D35058
cf359a8ec753d0eaeeb6f5d20eafaa4436cad2c3: Bug 1532795: Part 1 - Support sending BrowsingContexts via structured clone. r=nika
Kris Maglione <maglione.k@gmail.com> - Mon, 01 Jul 2019 15:24:09 -0700 - rev 540925
Push 11533 by archaeopteryx@coole-files.de at Mon, 08 Jul 2019 18:18:03 +0000
Bug 1532795: Part 1 - Support sending BrowsingContexts via structured clone. r=nika Differential Revision: https://phabricator.services.mozilla.com/D35698
f2c260cae4b51280b18ff67936c5a9ac79aed5eb: Bug 1541557: Part 7 - Convert SpecialPowers to use JSWindowActors rather than framescripts. r=nika
Kris Maglione <maglione.k@gmail.com> - Wed, 12 Jun 2019 10:48:29 -0700 - rev 540924
Push 11533 by archaeopteryx@coole-files.de at Mon, 08 Jul 2019 18:18:03 +0000
Bug 1541557: Part 7 - Convert SpecialPowers to use JSWindowActors rather than framescripts. r=nika Differential Revision: https://phabricator.services.mozilla.com/D35057
054a0b7aa81d2d29d9c46522f2512767bb123909: Bug 1541557: Part 6 - Read scripts for loadChromeScript in child process rather than parent. r=nika
Kris Maglione <maglione.k@gmail.com> - Thu, 13 Jun 2019 17:01:10 -0700 - rev 540923
Push 11533 by archaeopteryx@coole-files.de at Mon, 08 Jul 2019 18:18:03 +0000
Bug 1541557: Part 6 - Read scripts for loadChromeScript in child process rather than parent. r=nika `loadChromeScript` is often called with http: URLs pointing to mochitest resources, which need to be read synchronously before they can be executed. Unfortunately, while the API for this pretends to be synchronous, it really spins the event loop underneath. When we attempt to use it in the parent, that means that we spin the event loop and process messages from the child before the script has been executed. And since those messages often contain messages intended for the chrome script, that causes problems. When the chrome script APIs use sync messaging, this doesn't matter much, since the `loadChromeScript` call blocks the caller until the message handler in the parent returns. When it uses async messaging, though, we have no such luck, and the messages intended for the script get sent to the parent immediately. Loading the script contents in the child solves this problem, since it reliably blocks the child callers until the script contents are ready, and doesn't give them a chance to try to send messages to the script while it's still being read. Differential Revision: https://phabricator.services.mozilla.com/D35056
f808ec45ff9cf6a00847257e44f910a6c4c2b2ef: Bug 1541557: Part 5 - Update callers of ChromeScript.sendSyncMessage to use sendQuery instead. r=nika
Kris Maglione <maglione.k@gmail.com> - Wed, 12 Jun 2019 12:40:51 -0700 - rev 540922
Push 11533 by archaeopteryx@coole-files.de at Mon, 08 Jul 2019 18:18:03 +0000
Bug 1541557: Part 5 - Update callers of ChromeScript.sendSyncMessage to use sendQuery instead. r=nika Since JSWindowActors don't have direct access to synchronous messaging, ChromeScript callers are going to need to migrate to asynchronous messaging and queries instead. Since there's no comparable API to sendQuery for frame message managers, this patch adds a stub that uses synchronous messaging, but makes the API appear asynchronous, and migrates callers to use it instead of direct synchronous messaging. This will be replaced with a true synchronous API in the actor migration. Fortunately, most of the time, this actually leads to simpler code. The `sendQuery` API doesn't have the odd return value semantics of `sendSyncMessage`, and can usually just be used as a drop-in replacement. Many of the `sendSyncMessage` callers don't actually use the result, and can just be changed to `sendAsyncMessage`. And many of the existing async messaging users can be changed to just use `sendQuery` rather than sending messages and adding response listeners. However, the APZ code is an exception. It relies on intricate properties of the event loop, and doesn't have an easy way to slot in promise handlers, so I migrated it to using sync messaging via process message managers instead. Differential Revision: https://phabricator.services.mozilla.com/D35055
1025eeef095472d05bfb93499b501b1aff5cc758: Bug 1541557: Part 4 - Stop relying on synchronous preference getters/setters. r=nika
Kris Maglione <maglione.k@gmail.com> - Thu, 13 Jun 2019 09:34:39 -0700 - rev 540921
Push 11533 by archaeopteryx@coole-files.de at Mon, 08 Jul 2019 18:18:03 +0000
Bug 1541557: Part 4 - Stop relying on synchronous preference getters/setters. r=nika The SpecialPowers set*Pref/get*Pref APIs currently use synchronous messaging to set and get preference values from the parent process. Aside from directly affecting callers of those APIs, it also affects callers of `pushPrefEnv`, which is meant to be asynchronous, but is in practice usually synchronous due to the synchronous messaging it uses. This patch updates the getPref APIs to use the in-process preference service (which most callers are expecting anyway), and also updates the callers of the setPref and pushPrefEnv APIs to await the result if they're relying on it taking effect immediately. Unfortunately, there are some corner cases in tests that appear to only work because of the quirks of the current sync messaging approach. The synchronous setPref APIs, for instance, trigger preference changes in the parent instantly, but don't update the values in the child until we've returned to the event loop and had a chance to process the notifications from the parent. The differnce in timing leads some tests to fail in strange ways, which this patch works around by just adding timeouts. There should be follow-ups for test owners to fix the flakiness. Differential Revision: https://phabricator.services.mozilla.com/D35054
fe88b250e4180b8a1898b42b6f3339cd8e6a3ec8: Bug 1541557: Part 3 - Update callers of sync SpecialPowers functions to await the return value. r=nika
Kris Maglione <maglione.k@gmail.com> - Wed, 12 Jun 2019 11:41:32 -0700 - rev 540920
Push 11533 by archaeopteryx@coole-files.de at Mon, 08 Jul 2019 18:18:03 +0000
Bug 1541557: Part 3 - Update callers of sync SpecialPowers functions to await the return value. r=nika When we migrate SpecialPowers to a JSWindowActor, it will no longer be able to use synchronous IPC messaging, which means that its current synchronous APIs will have to become asynchronous. This patch doesn't change the behavior of those functions, but it does change their callers to `await` their return values rather than using them directly. This pattern will work the same whether the functions return a promise or a plain value, which simplifies the migration. Differential Revision: https://phabricator.services.mozilla.com/D35053
6680278c231bcbbbde62bf9ea974eac5a378c6fc: Bug 1541557: Part 2 - Stop sending uninitialized StructuredCloneData objects. r=nika
Kris Maglione <maglione.k@gmail.com> - Thu, 13 Jun 2019 15:01:05 -0700 - rev 540919
Push 11533 by archaeopteryx@coole-files.de at Mon, 08 Jul 2019 18:18:03 +0000
Bug 1541557: Part 2 - Stop sending uninitialized StructuredCloneData objects. r=nika There are a couple of places where JSWindowActor currently sends uninitialized StructuredCloneData objects in places where it wants the message data to be undefined. The problem with this is that it causes an error when trying to read the data, which leads to odd behavior like `sendQuery` promises never being settled if the message handler throws, or `sendAsyncMessage` and `sendQuery` failing to decode the message if the caller doesn't pass a second argument. The errors reported for these problems also have no context, which means it's very hard for a developer to figure out the source of the problem. And, to make matters worse, the errors look the same as structured clone encoding errors, so there isn't even the clue that the error is happening on decode. This patch updates the offending code to always explicitly initialize the structured clone data with `undefined` when that's what it wants, and adds assertions to make it more obvious where the decode errors are actually happening. Differential Revision: https://phabricator.services.mozilla.com/D35052
255735c1ff63336c5ccead020d798436697f8d15: Bug 1541557: Part 1 - Use correct globals for JSWindowActors not in the shared JSM global. r=nika
Kris Maglione <maglione.k@gmail.com> - Wed, 12 Jun 2019 16:06:40 -0700 - rev 540918
Push 11533 by archaeopteryx@coole-files.de at Mon, 08 Jul 2019 18:18:03 +0000
Bug 1541557: Part 1 - Use correct globals for JSWindowActors not in the shared JSM global. r=nika The current JSWindowActor code assumes that all actors will be created in the shared JSM global. This has a few problems: 1) For actors in other scopes, it enters the wrong compartment before decoding messages, which leads to a compartment checker error when trying to call message handlers. That could be fixed by just wrapping the result for the caller, but that would lead to other problems. Aside from the efficiency concerns of having to deal with cross-compartment wrappers, SpecialPowers in particular would not be able to pass the resulting objects to unprivileged scopes, since only SpecialPowers compartments have permissive CCWs enabled. 2) It also leads to the prototype objects for the actor instances being created in the shared JSM scope, even when the actors themselves are defined in other compartments. Again, aside from CCW efficiency issues, this prevents the SpecialPowers instances from being accessed by the unprivileged scopes that they're exposed to, since the prototype objects live in privileged scopes which don't have permissive CCWs enabled. This patch changes child actors to always create their objects in the global of their constructors. The parent objects are still created in the shared JSM global, but they now wrap values for the appropriate compartment before trying to call message handlers. Differential Revision: https://phabricator.services.mozilla.com/D35051
ef4ec8f0f886254c5ef20aa0865ff837badda664: Bug 1558298: Part 10 - Stop loading MozillaLogger.js from SpecialPowers. r=nika
Kris Maglione <maglione.k@gmail.com> - Tue, 11 Jun 2019 11:37:52 -0700 - rev 540915
Push 11533 by archaeopteryx@coole-files.de at Mon, 08 Jul 2019 18:18:03 +0000
Bug 1558298: Part 10 - Stop loading MozillaLogger.js from SpecialPowers. r=nika Differential Revision: https://phabricator.services.mozilla.com/D34599
45a9599d96417beb8b032e9a95c8b119929dd54b: Bug 1558298: Part 9 - Make MozillaLogger.js less insane. r=nika
Kris Maglione <maglione.k@gmail.com> - Tue, 11 Jun 2019 11:28:47 -0700 - rev 540914
Push 11533 by archaeopteryx@coole-files.de at Mon, 08 Jul 2019 18:18:03 +0000
Bug 1558298: Part 9 - Make MozillaLogger.js less insane. r=nika Differential Revision: https://phabricator.services.mozilla.com/D34598
4ccecdba1c3430a7e605329425020e43b2e9bc39: Bug 1558298: Part 8 - Convert SpecialPowersObserverAPI and sub-classes to ES6 classes. r=nika
Kris Maglione <maglione.k@gmail.com> - Mon, 10 Jun 2019 15:42:36 -0700 - rev 540913
Push 11533 by archaeopteryx@coole-files.de at Mon, 08 Jul 2019 18:18:03 +0000
Bug 1558298: Part 8 - Convert SpecialPowersObserverAPI and sub-classes to ES6 classes. r=nika Differential Revision: https://phabricator.services.mozilla.com/D34597
0e91fc9541c294b8c3133aae81f45d0bcab8155c: Bug 1558298: Part 7 - Convert SpecialPowersAPI and sub-classes to ES6 classes. r=nika
Kris Maglione <maglione.k@gmail.com> - Mon, 10 Jun 2019 15:15:37 -0700 - rev 540912
Push 11533 by archaeopteryx@coole-files.de at Mon, 08 Jul 2019 18:18:03 +0000
Bug 1558298: Part 7 - Convert SpecialPowersAPI and sub-classes to ES6 classes. r=nika Differential Revision: https://phabricator.services.mozilla.com/D34596
edd1cc6badf788f950ee68168aed0a14aa191411: Bug 1558298: Part 6 - Remove some arrant nonsense from ChromePowers.js. r=nika
Kris Maglione <maglione.k@gmail.com> - Mon, 10 Jun 2019 14:57:58 -0700 - rev 540911
Push 11533 by archaeopteryx@coole-files.de at Mon, 08 Jul 2019 18:18:03 +0000
Bug 1558298: Part 6 - Remove some arrant nonsense from ChromePowers.js. r=nika Differential Revision: https://phabricator.services.mozilla.com/D34595
ba24251835fbbd7348e96b7f2956f32811d3577e: Bug 1558298: Part 5 - Let ChromePowers.js handle its own SpecialPowers imports. r=nika
Kris Maglione <maglione.k@gmail.com> - Mon, 10 Jun 2019 14:15:47 -0700 - rev 540910
Push 11533 by archaeopteryx@coole-files.de at Mon, 08 Jul 2019 18:18:03 +0000
Bug 1558298: Part 5 - Let ChromePowers.js handle its own SpecialPowers imports. r=nika Differential Revision: https://phabricator.services.mozilla.com/D34594
ca88016511bb3f7aa335ee6531b17e75c08477a6: Bug 1558298: Part 4 - Cleanup some cruft in SpecialPowersObserver.jsm. r=nika
Kris Maglione <maglione.k@gmail.com> - Mon, 10 Jun 2019 14:04:27 -0700 - rev 540909
Push 11533 by archaeopteryx@coole-files.de at Mon, 08 Jul 2019 18:18:03 +0000
Bug 1558298: Part 4 - Cleanup some cruft in SpecialPowersObserver.jsm. r=nika Differential Revision: https://phabricator.services.mozilla.com/D34593
c95e6e5998364d70a97651dea785d0ad5c31eff5: Bug 1558298: Part 3 - Always load specialpowers.js as a JSM. r=nika
Kris Maglione <maglione.k@gmail.com> - Mon, 10 Jun 2019 13:31:19 -0700 - rev 540908
Push 11533 by archaeopteryx@coole-files.de at Mon, 08 Jul 2019 18:18:03 +0000
Bug 1558298: Part 3 - Always load specialpowers.js as a JSM. r=nika Differential Revision: https://phabricator.services.mozilla.com/D34592
9b1a9d80243437eb87d63a10b62d7b25eb2a6664: Bug 1558298: Part 2 - Always load specialpowersAPI.js as a JSM. r=nika
Kris Maglione <maglione.k@gmail.com> - Mon, 10 Jun 2019 13:12:00 -0700 - rev 540907
Push 11533 by archaeopteryx@coole-files.de at Mon, 08 Jul 2019 18:18:03 +0000
Bug 1558298: Part 2 - Always load specialpowersAPI.js as a JSM. r=nika Differential Revision: https://phabricator.services.mozilla.com/D34591
f859e4de00079fca494cbee9ee339e3c006215bb: Bug 1558298: Part 1 - Move SpecialPowers wrapping code to separate module. r=nika
Kris Maglione <maglione.k@gmail.com> - Mon, 10 Jun 2019 12:46:43 -0700 - rev 540906
Push 11533 by archaeopteryx@coole-files.de at Mon, 08 Jul 2019 18:18:03 +0000
Bug 1558298: Part 1 - Move SpecialPowers wrapping code to separate module. r=nika Differential Revision: https://phabricator.services.mozilla.com/D34590
65f14a25f9126f66554cf9827bc5ac12266a1c4e: Bug 1562769 - Clean up ContentParent destruction. r=nika
Jed Davis <jld@mozilla.com> - Wed, 03 Jul 2019 03:34:37 +0000 - rev 540713
Push 11529 by archaeopteryx@coole-files.de at Thu, 04 Jul 2019 15:22:33 +0000
Bug 1562769 - Clean up ContentParent destruction. r=nika Differential Revision: https://phabricator.services.mozilla.com/D36555
531e69180f15e79c2449e747c0204b83e3a1aee7: Bug 1561899 - Add mIsDiscarded and use that when detaching. r=nika
Andreas Farre <farre@mozilla.com> - Tue, 02 Jul 2019 20:48:13 +0000 - rev 540670
Push 11529 by archaeopteryx@coole-files.de at Thu, 04 Jul 2019 15:22:33 +0000
Bug 1561899 - Add mIsDiscarded and use that when detaching. r=nika Differential Revision: https://phabricator.services.mozilla.com/D36195
cc9b37d2e9541e9607bdf69833d3c656a859a71e: Bug 1560977 - Annotate crash reports if Fission is enabled. r=nika
Andrew McCreight <continuation@gmail.com> - Tue, 02 Jul 2019 21:08:55 +0000 - rev 540667
Push 11529 by archaeopteryx@coole-files.de at Thu, 04 Jul 2019 15:22:33 +0000
Bug 1560977 - Annotate crash reports if Fission is enabled. r=nika Differential Revision: https://phabricator.services.mozilla.com/D36530
72630a7c6e6742388107a77afc26c9c191722705: Bug 1561999: Initiate window.open() loads for cross-process URLs in the calling process under Fission. r=nika
Kris Maglione <maglione.k@gmail.com> - Thu, 27 Jun 2019 12:22:12 -0700 - rev 540554
Push 11529 by archaeopteryx@coole-files.de at Thu, 04 Jul 2019 15:22:33 +0000
Bug 1561999: Initiate window.open() loads for cross-process URLs in the calling process under Fission. r=nika When Fission is enabled, the load will be retargeted to the correct process automatically, and will in the mean time give callers access to an about:blank document as required by the spec. Differential Revision: https://phabricator.services.mozilla.com/D36242
c35aff2a933694722bc4ef64a3b53e787c662d6a: Bug 1561724: Correctly support exposing remote frames by name. r=nika
Kris Maglione <maglione.k@gmail.com> - Wed, 26 Jun 2019 13:35:55 -0700 - rev 540553
Push 11529 by archaeopteryx@coole-files.de at Thu, 04 Jul 2019 15:22:33 +0000
Bug 1561724: Correctly support exposing remote frames by name. r=nika Differential Revision: https://phabricator.services.mozilla.com/D36083
0b3e2164f1283b639782b41b7fd640986d3feca5: Bug 1561150: Support test assertions in SpecialPowers.spawn sandboxes. r=nika
Kris Maglione <maglione.k@gmail.com> - Mon, 24 Jun 2019 19:25:33 -0700 - rev 540551
Push 11529 by archaeopteryx@coole-files.de at Thu, 04 Jul 2019 15:22:33 +0000
Bug 1561150: Support test assertions in SpecialPowers.spawn sandboxes. r=nika Differential Revision: https://phabricator.services.mozilla.com/D35747
bf0f0e95c61c2a57d176699f05e71e967a13d3e8: Bug 1560400: Part 3 - Update DocShell frame navigation tests to support remote frames. r=nika
Kris Maglione <maglione.k@gmail.com> - Thu, 20 Jun 2019 14:30:47 -0700 - rev 540548
Push 11529 by archaeopteryx@coole-files.de at Thu, 04 Jul 2019 15:22:33 +0000
Bug 1560400: Part 3 - Update DocShell frame navigation tests to support remote frames. r=nika The tests still fail under Fission, because the mechanisms they use to navigate the frames don't work, but at least the checks for whether the navigation succeeded now do. That means the tests should start passing when the necessary APIs become Fission-compatible. Differential Revision: https://phabricator.services.mozilla.com/D35473
84633034590f2d1a4c336f9653e6c542f3a09039: Bug 1560400: Part 1 - Support remote frames in Window indexed getters. r=nika
Kris Maglione <maglione.k@gmail.com> - Thu, 20 Jun 2019 13:52:55 -0700 - rev 540547
Push 11529 by archaeopteryx@coole-files.de at Thu, 04 Jul 2019 15:22:33 +0000
Bug 1560400: Part 1 - Support remote frames in Window indexed getters. r=nika Differential Revision: https://phabricator.services.mozilla.com/D35471
d5415970da5fd83eb870b397b8db7fdf6c57ad23: Bug 1532795: Part 5 - Support SpecialPowers.spawn on WindowProxy objects. r=nika
Kris Maglione <maglione.k@gmail.com> - Wed, 19 Jun 2019 13:07:14 -0700 - rev 540546
Push 11529 by archaeopteryx@coole-files.de at Thu, 04 Jul 2019 15:22:33 +0000
Bug 1532795: Part 5 - Support SpecialPowers.spawn on WindowProxy objects. r=nika Differential Revision: https://phabricator.services.mozilla.com/D35378
119caddcb0660754f9bce5e7153bfc92dc211d57: Bug 1532795: Part 4 - Add helper to get BrowsingContext from WindowProxy. r=nika
Kris Maglione <maglione.k@gmail.com> - Wed, 19 Jun 2019 13:06:32 -0700 - rev 540545
Push 11529 by archaeopteryx@coole-files.de at Thu, 04 Jul 2019 15:22:33 +0000
Bug 1532795: Part 4 - Add helper to get BrowsingContext from WindowProxy. r=nika Differential Revision: https://phabricator.services.mozilla.com/D35377
fbbe113aeef2f44741248ef15be66562e66adf6c: Bug 1532795: Part 3 - Update random test to use SpecialPowers.spawn for cross-process iframe access. r=nika
Kris Maglione <maglione.k@gmail.com> - Tue, 18 Jun 2019 20:49:35 -0700 - rev 540544
Push 11529 by archaeopteryx@coole-files.de at Thu, 04 Jul 2019 15:22:33 +0000
Bug 1532795: Part 3 - Update random test to use SpecialPowers.spawn for cross-process iframe access. r=nika Differential Revision: https://phabricator.services.mozilla.com/D35297
8a3d311c7fac75b5902f2fa9dc651137a499fc18: Bug 1532795: Part 2 - Implement basic SpecialPowers.spawn as a replacement for ContentTask. r=nika
Kris Maglione <maglione.k@gmail.com> - Tue, 18 Jun 2019 16:21:49 -0700 - rev 540543
Push 11529 by archaeopteryx@coole-files.de at Thu, 04 Jul 2019 15:22:33 +0000
Bug 1532795: Part 2 - Implement basic SpecialPowers.spawn as a replacement for ContentTask. r=nika With out-of-process iframes, we'll need similar functionality to the ContentTask helpers that can be used in any process, with any type of frame. Using ContentTask directly in unprivileged contexts will, I think, be a bit too combersome given how often it's needed, so this patch adds an API directly to SpecialPowers instead. The environment provided to the task is currently pretty basic, and doesn't provide the assertion helpers currently available to ContentTask tasks, but it can grow as we find it necessary. Differential Revision: https://phabricator.services.mozilla.com/D35058
1471732eca80f6fa44ae50b39c0317965cd29671: Bug 1532795: Part 1 - Support sending BrowsingContexts via structured clone. r=nika
Kris Maglione <maglione.k@gmail.com> - Mon, 01 Jul 2019 15:24:09 -0700 - rev 540542
Push 11529 by archaeopteryx@coole-files.de at Thu, 04 Jul 2019 15:22:33 +0000
Bug 1532795: Part 1 - Support sending BrowsingContexts via structured clone. r=nika Differential Revision: https://phabricator.services.mozilla.com/D35698
46ff845a7b0cdabf640bb2e3c783735ab68b7cd1: Bug 1541557: Part 7 - Convert SpecialPowers to use JSWindowActors rather than framescripts. r=nika
Kris Maglione <maglione.k@gmail.com> - Wed, 12 Jun 2019 10:48:29 -0700 - rev 540541
Push 11529 by archaeopteryx@coole-files.de at Thu, 04 Jul 2019 15:22:33 +0000
Bug 1541557: Part 7 - Convert SpecialPowers to use JSWindowActors rather than framescripts. r=nika Differential Revision: https://phabricator.services.mozilla.com/D35057
c2697f04d38cf0b01b1f3e227910ab5890926a33: Bug 1541557: Part 6 - Read scripts for loadChromeScript in child process rather than parent. r=nika
Kris Maglione <maglione.k@gmail.com> - Thu, 13 Jun 2019 17:01:10 -0700 - rev 540540
Push 11529 by archaeopteryx@coole-files.de at Thu, 04 Jul 2019 15:22:33 +0000
Bug 1541557: Part 6 - Read scripts for loadChromeScript in child process rather than parent. r=nika `loadChromeScript` is often called with http: URLs pointing to mochitest resources, which need to be read synchronously before they can be executed. Unfortunately, while the API for this pretends to be synchronous, it really spins the event loop underneath. When we attempt to use it in the parent, that means that we spin the event loop and process messages from the child before the script has been executed. And since those messages often contain messages intended for the chrome script, that causes problems. When the chrome script APIs use sync messaging, this doesn't matter much, since the `loadChromeScript` call blocks the caller until the message handler in the parent returns. When it uses async messaging, though, we have no such luck, and the messages intended for the script get sent to the parent immediately. Loading the script contents in the child solves this problem, since it reliably blocks the child callers until the script contents are ready, and doesn't give them a chance to try to send messages to the script while it's still being read. Differential Revision: https://phabricator.services.mozilla.com/D35056
75ebd6fce136ab3bd0e591c2b8b2d06d3b5bf923: Bug 1541557: Part 5 - Update callers of ChromeScript.sendSyncMessage to use sendQuery instead. r=nika
Kris Maglione <maglione.k@gmail.com> - Wed, 12 Jun 2019 12:40:51 -0700 - rev 540539
Push 11529 by archaeopteryx@coole-files.de at Thu, 04 Jul 2019 15:22:33 +0000
Bug 1541557: Part 5 - Update callers of ChromeScript.sendSyncMessage to use sendQuery instead. r=nika Since JSWindowActors don't have direct access to synchronous messaging, ChromeScript callers are going to need to migrate to asynchronous messaging and queries instead. Since there's no comparable API to sendQuery for frame message managers, this patch adds a stub that uses synchronous messaging, but makes the API appear asynchronous, and migrates callers to use it instead of direct synchronous messaging. This will be replaced with a true synchronous API in the actor migration. Fortunately, most of the time, this actually leads to simpler code. The `sendQuery` API doesn't have the odd return value semantics of `sendSyncMessage`, and can usually just be used as a drop-in replacement. Many of the `sendSyncMessage` callers don't actually use the result, and can just be changed to `sendAsyncMessage`. And many of the existing async messaging users can be changed to just use `sendQuery` rather than sending messages and adding response listeners. However, the APZ code is an exception. It relies on intricate properties of the event loop, and doesn't have an easy way to slot in promise handlers, so I migrated it to using sync messaging via process message managers instead. Differential Revision: https://phabricator.services.mozilla.com/D35055
189dc8a359815e059a4a217f788d183260bb2bfe: Bug 1541557: Part 4 - Stop relying on synchronous preference getters/setters. r=nika
Kris Maglione <maglione.k@gmail.com> - Thu, 13 Jun 2019 09:34:39 -0700 - rev 540538
Push 11529 by archaeopteryx@coole-files.de at Thu, 04 Jul 2019 15:22:33 +0000
Bug 1541557: Part 4 - Stop relying on synchronous preference getters/setters. r=nika The SpecialPowers set*Pref/get*Pref APIs currently use synchronous messaging to set and get preference values from the parent process. Aside from directly affecting callers of those APIs, it also affects callers of `pushPrefEnv`, which is meant to be asynchronous, but is in practice usually synchronous due to the synchronous messaging it uses. This patch updates the getPref APIs to use the in-process preference service (which most callers are expecting anyway), and also updates the callers of the setPref and pushPrefEnv APIs to await the result if they're relying on it taking effect immediately. Unfortunately, there are some corner cases in tests that appear to only work because of the quirks of the current sync messaging approach. The synchronous setPref APIs, for instance, trigger preference changes in the parent instantly, but don't update the values in the child until we've returned to the event loop and had a chance to process the notifications from the parent. The differnce in timing leads some tests to fail in strange ways, which this patch works around by just adding timeouts. There should be follow-ups for test owners to fix the flakiness. Differential Revision: https://phabricator.services.mozilla.com/D35054
b4ed40bea2698802ef562a0931c0b560737fb89d: Bug 1541557: Part 3 - Update callers of sync SpecialPowers functions to await the return value. r=nika
Kris Maglione <maglione.k@gmail.com> - Wed, 12 Jun 2019 11:41:32 -0700 - rev 540537
Push 11529 by archaeopteryx@coole-files.de at Thu, 04 Jul 2019 15:22:33 +0000
Bug 1541557: Part 3 - Update callers of sync SpecialPowers functions to await the return value. r=nika When we migrate SpecialPowers to a JSWindowActor, it will no longer be able to use synchronous IPC messaging, which means that its current synchronous APIs will have to become asynchronous. This patch doesn't change the behavior of those functions, but it does change their callers to `await` their return values rather than using them directly. This pattern will work the same whether the functions return a promise or a plain value, which simplifies the migration. Differential Revision: https://phabricator.services.mozilla.com/D35053
158a4000c44b9b17a7935340db79431d544fb556: Bug 1541557: Part 2 - Stop sending uninitialized StructuredCloneData objects. r=nika
Kris Maglione <maglione.k@gmail.com> - Thu, 13 Jun 2019 15:01:05 -0700 - rev 540536
Push 11529 by archaeopteryx@coole-files.de at Thu, 04 Jul 2019 15:22:33 +0000
Bug 1541557: Part 2 - Stop sending uninitialized StructuredCloneData objects. r=nika There are a couple of places where JSWindowActor currently sends uninitialized StructuredCloneData objects in places where it wants the message data to be undefined. The problem with this is that it causes an error when trying to read the data, which leads to odd behavior like `sendQuery` promises never being settled if the message handler throws, or `sendAsyncMessage` and `sendQuery` failing to decode the message if the caller doesn't pass a second argument. The errors reported for these problems also have no context, which means it's very hard for a developer to figure out the source of the problem. And, to make matters worse, the errors look the same as structured clone encoding errors, so there isn't even the clue that the error is happening on decode. This patch updates the offending code to always explicitly initialize the structured clone data with `undefined` when that's what it wants, and adds assertions to make it more obvious where the decode errors are actually happening. Differential Revision: https://phabricator.services.mozilla.com/D35052
61fa2745733f3631488a3ecccc144823683b7b6d: Bug 1541557: Part 1 - Use correct globals for JSWindowActors not in the shared JSM global. r=nika
Kris Maglione <maglione.k@gmail.com> - Wed, 12 Jun 2019 16:06:40 -0700 - rev 540535
Push 11529 by archaeopteryx@coole-files.de at Thu, 04 Jul 2019 15:22:33 +0000
Bug 1541557: Part 1 - Use correct globals for JSWindowActors not in the shared JSM global. r=nika The current JSWindowActor code assumes that all actors will be created in the shared JSM global. This has a few problems: 1) For actors in other scopes, it enters the wrong compartment before decoding messages, which leads to a compartment checker error when trying to call message handlers. That could be fixed by just wrapping the result for the caller, but that would lead to other problems. Aside from the efficiency concerns of having to deal with cross-compartment wrappers, SpecialPowers in particular would not be able to pass the resulting objects to unprivileged scopes, since only SpecialPowers compartments have permissive CCWs enabled. 2) It also leads to the prototype objects for the actor instances being created in the shared JSM scope, even when the actors themselves are defined in other compartments. Again, aside from CCW efficiency issues, this prevents the SpecialPowers instances from being accessed by the unprivileged scopes that they're exposed to, since the prototype objects live in privileged scopes which don't have permissive CCWs enabled. This patch changes child actors to always create their objects in the global of their constructors. The parent objects are still created in the shared JSM global, but they now wrap values for the appropriate compartment before trying to call message handlers. Differential Revision: https://phabricator.services.mozilla.com/D35051