searching for reviewer(bholley)
1a2ce7a5ce7d36f9310031d9a2dbaa60d62e1819: Bug 1512162 - A better fix for incorrect code generation on ppc64le. r=bholley
Cameron Kaiser <spectre@floodgap.com> - Mon, 01 Jul 2019 18:40:59 +0000 - rev 543705
Push 2131 by ffxbld-merge at Mon, 26 Aug 2019 18:30:20 +0000
Bug 1512162 - A better fix for incorrect code generation on ppc64le. r=bholley Differential Revision: https://phabricator.services.mozilla.com/D36439
79833c5d37bf7a68d693efe1c3d2614c559f68cb: Bug 1552541. Consider document.domain when deciding on inner window reuse. r=bholley
Boris Zbarsky <bzbarsky@mit.edu> - Wed, 22 May 2019 21:18:27 +0000 - rev 539704
Push 2131 by ffxbld-merge at Mon, 26 Aug 2019 18:30:20 +0000
Bug 1552541. Consider document.domain when deciding on inner window reuse. r=bholley Differential Revision: https://phabricator.services.mozilla.com/D31857
4b59d75bb1ff2209a114cdbe6470da200b85d58f: Bug 1553276. Don't enter the content compartment when calling a Web IDL legacycaller over Xrays. r=bholley
Boris Zbarsky <bzbarsky@mit.edu> - Tue, 21 May 2019 19:49:18 +0000 - rev 537661
Push 2131 by ffxbld-merge at Mon, 26 Aug 2019 18:30:20 +0000
Bug 1553276. Don't enter the content compartment when calling a Web IDL legacycaller over Xrays. r=bholley Differential Revision: https://phabricator.services.mozilla.com/D32047
9b3c45bd2e778ae1ab2da8d4a79d3771619d626b: Bug 1552541. Consider document.domain when deciding on inner window reuse. r=bholley a=jcristau
Boris Zbarsky <bzbarsky@mit.edu> - Wed, 22 May 2019 21:18:27 +0000 - rev 536712
Push 2082 by ffxbld-merge at Mon, 01 Jul 2019 08:34:18 +0000
Bug 1552541. Consider document.domain when deciding on inner window reuse. r=bholley a=jcristau Differential Revision: https://phabricator.services.mozilla.com/D31857
d62e8172a66f2b3956997848b127f31b458e9e9d: Bug 1548941 - remove e10s force-enable and force-disable prefs, and on desktop restrict 'normal' e10s pref to automation and unofficial builds, r=bholley,ahal
Gijs Kruitbosch <gijskruitbosch@gmail.com> - Thu, 09 May 2019 21:55:46 +0000 - rev 535208
Push 2082 by ffxbld-merge at Mon, 01 Jul 2019 08:34:18 +0000
Bug 1548941 - remove e10s force-enable and force-disable prefs, and on desktop restrict 'normal' e10s pref to automation and unofficial builds, r=bholley,ahal Differential Revision: https://phabricator.services.mozilla.com/D29892
0ba7b9f6fdafcd2a2ba6a13706a8d419d7d64f5b: Bug 1549969 - Fix an assertion that doesn't account for alignment padding. r=bholley
Emilio Cobos Álvarez <emilio@crisal.io> - Wed, 08 May 2019 18:03:37 +0000 - rev 534986
Push 2082 by ffxbld-merge at Mon, 01 Jul 2019 08:34:18 +0000
Bug 1549969 - Fix an assertion that doesn't account for alignment padding. r=bholley I'm hitting this when trying to add bindings for box shadows, which are 32-bit aligned. Depends on D30352 Differential Revision: https://phabricator.services.mozilla.com/D30353
82ae6ce8f3a8e18ab661b8d85fc96649a28694b5: Bug 1549969 - Don't panic when creating empty ThinArcs. r=bholley
Emilio Cobos Álvarez <emilio@crisal.io> - Wed, 08 May 2019 17:54:25 +0000 - rev 534985
Push 2082 by ffxbld-merge at Mon, 01 Jul 2019 08:34:18 +0000
Bug 1549969 - Don't panic when creating empty ThinArcs. r=bholley The change from [T; 1] to [T; 0] shouldn't change behavior since they have the right alignment and we never poke at that particular array, but feels more correct to avoid creating types that point to uninitialized data or outside of their allocation, now that we allow empty slices. Differential Revision: https://phabricator.services.mozilla.com/D30352
4e2250bbaed37b7b0a9a2c4b66c0c5455a1551a6: Bug 1548941 - remove e10s force-enable and force-disable prefs, and on desktop restrict 'normal' e10s pref to automation and unofficial builds, r=bholley,ahal
Gijs Kruitbosch <gijskruitbosch@gmail.com> - Wed, 08 May 2019 15:56:53 +0000 - rev 534971
Push 2082 by ffxbld-merge at Mon, 01 Jul 2019 08:34:18 +0000
Bug 1548941 - remove e10s force-enable and force-disable prefs, and on desktop restrict 'normal' e10s pref to automation and unofficial builds, r=bholley,ahal Differential Revision: https://phabricator.services.mozilla.com/D29892
63d77dbcfda80e420a7e35c2b4244a7a67a5bef2: Bug 1549596 - Use PhantomData<T> in servo_arc. r=bholley
Emilio Cobos Álvarez <emilio@crisal.io> - Wed, 08 May 2019 08:01:01 +0000 - rev 534901
Push 2082 by ffxbld-merge at Mon, 01 Jul 2019 08:34:18 +0000
Bug 1549596 - Use PhantomData<T> in servo_arc. r=bholley See https://github.com/rust-lang/rust/pull/60594#issuecomment-489966933 Differential Revision: https://phabricator.services.mozilla.com/D30169
48edd877bde3ebbf5efc525eddad22099c0673ad: Bug 1549596 - ThinArc should use NonNull. r=bholley
Emilio Cobos Álvarez <emilio@crisal.io> - Tue, 07 May 2019 03:16:21 +0000 - rev 534900
Push 2082 by ffxbld-merge at Mon, 01 Jul 2019 08:34:18 +0000
Bug 1549596 - ThinArc should use NonNull. r=bholley If only for parallelism with Arc<>. Differential Revision: https://phabricator.services.mozilla.com/D30131
5d97da3c65b5376c9bc6df4add1646fc63937693: Bug 1548941 - remove e10s force-enable and force-disable prefs, and on desktop restrict 'normal' e10s pref to automation and unofficial builds, r=bholley
Gijs Kruitbosch <gijskruitbosch@gmail.com> - Fri, 03 May 2019 23:07:01 +0000 - rev 534662
Push 2082 by ffxbld-merge at Mon, 01 Jul 2019 08:34:18 +0000
Bug 1548941 - remove e10s force-enable and force-disable prefs, and on desktop restrict 'normal' e10s pref to automation and unofficial builds, r=bholley Differential Revision: https://phabricator.services.mozilla.com/D29892
6462a738b3c5cb0ac8327c18c3c0ebed3955ad74: Bug 1538540 - Sanity check frames after TextureCache clears r=bholley
Doug Thayer <dothayer@mozilla.com> - Thu, 02 May 2019 01:37:02 +0000 - rev 534105
Push 2082 by ffxbld-merge at Mon, 01 Jul 2019 08:34:18 +0000
Bug 1538540 - Sanity check frames after TextureCache clears r=bholley In trying to diagnose bug 1538540, I'm hitting my limits as far as simply staring at the code and trying to work out possible ways to hit the crash goes. This assertion will split the search space into clear-related causes and non-clear-related causes to narrow things down. Differential Revision: https://phabricator.services.mozilla.com/D29420
91859883a54dbdd7cc5376f379466ceb5e8b4e9b: Bug 1538540 - Sanity check frames after TextureCache clears r=bholley
Doug Thayer <dothayer@mozilla.com> - Tue, 30 Apr 2019 23:58:23 +0000 - rev 533923
Push 2082 by ffxbld-merge at Mon, 01 Jul 2019 08:34:18 +0000
Bug 1538540 - Sanity check frames after TextureCache clears r=bholley In trying to diagnose bug 1538540, I'm hitting my limits as far as simply staring at the code and trying to work out possible ways to hit the crash goes. This assertion will split the search space into clear-related causes and non-clear-related causes to narrow things down. Differential Revision: https://phabricator.services.mozilla.com/D29420
24161afba7afa66dd487203298e568610bfe1191: Bug 1545979 - Drop unused user-agent cascade datas when not holding the cache lock. r=bholley
Emilio Cobos Álvarez <emilio@crisal.io> - Mon, 22 Apr 2019 19:45:06 +0000 - rev 532291
Push 2082 by ffxbld-merge at Mon, 01 Jul 2019 08:34:18 +0000
Bug 1545979 - Drop unused user-agent cascade datas when not holding the cache lock. r=bholley We want to drop the cascade data memory as soon as possible, so bug 1544546 introduced an UpdateStylistIfNeeded call from ShellDetachedFromDocument. Unfortunately, this call can reenter into the global user-agent cascade data if some of the CSS values kept alive by the cascade data keep alive an SVG document, see the stack on this bug for an example. Make sure to drop the user-agent cascade datas when not holding the cache lock to avoid this situation. Before bug 1535788, we just destroyed the stylist, so we kept holding a reference from the cache, and that reference will be dropped sometime later when other document updated their user-agent stylesheets (if they happened not to match the cache of course). Seems to me this doesn't ended up happening in our automation, but it could happen in the wild, in theory at least. It's nice that Rust made this a safe deadlock caught by our tests rather than a very subtle and infrequent memory corruption. The relevant SVG documents are probably the <input type=number> rules: https://searchfox.org/mozilla-central/rev/d80f0a570736dce76a2eb184fb65517462089e8a/layout/style/res/forms.css#1050 Differential Revision: https://phabricator.services.mozilla.com/D28299
3bd02d619749876d5a6f665ad979321d17e94d42: Bug 1474793 - Document the shared memory UA sheet setup in tree. r=bholley
Cameron McCormack <cam@mcc.id.au> - Tue, 16 Apr 2019 08:11:25 +1000 - rev 531489
Push 2082 by ffxbld-merge at Mon, 01 Jul 2019 08:34:18 +0000
Bug 1474793 - Document the shared memory UA sheet setup in tree. r=bholley
7135525f4d5a8f2d8d9a99090a2aa29eb80ac0fa: Bug 1538710 - Remove disable-shrink pref r=bholley
Doug Thayer <dothayer@mozilla.com> - Mon, 15 Apr 2019 22:34:51 +0000 - rev 531466
Push 2082 by ffxbld-merge at Mon, 01 Jul 2019 08:34:18 +0000
Bug 1538710 - Remove disable-shrink pref r=bholley Differential Revision: https://phabricator.services.mozilla.com/D25134
4911ed11603a65608ee65d1c1eda7487dfb35c39: Bug 1538710 - Move texture_cache cleanup to beginning of all frames r=bholley
Doug Thayer <dothayer@mozilla.com> - Mon, 15 Apr 2019 22:34:43 +0000 - rev 531465
Push 2082 by ffxbld-merge at Mon, 01 Jul 2019 08:34:18 +0000
Bug 1538710 - Move texture_cache cleanup to beginning of all frames r=bholley ... and ensure that, if we do cleanup, we generate frames for every document. Differential Revision: https://phabricator.services.mozilla.com/D25133
1a529f967061dbe745d720c7b6a025e77a15f29a: Bug 1538710 - Remove disable-shrink pref r=bholley
Doug Thayer <dothayer@mozilla.com> - Mon, 15 Apr 2019 18:09:10 +0000 - rev 531436
Push 2082 by ffxbld-merge at Mon, 01 Jul 2019 08:34:18 +0000
Bug 1538710 - Remove disable-shrink pref r=bholley Differential Revision: https://phabricator.services.mozilla.com/D25134
afa5cc2c60328afd9261385bb40b7339de0d5633: Bug 1538710 - Move texture_cache cleanup to beginning of all frames r=bholley
Doug Thayer <dothayer@mozilla.com> - Mon, 15 Apr 2019 18:08:47 +0000 - rev 531435
Push 2082 by ffxbld-merge at Mon, 01 Jul 2019 08:34:18 +0000
Bug 1538710 - Move texture_cache cleanup to beginning of all frames r=bholley ... and ensure that, if we do cleanup, we generate frames for every document. Differential Revision: https://phabricator.services.mozilla.com/D25133
9a80bc4d626a74d84ae9b4163021d1dcbc585a24: Bug 1538710 - Remove disable-shrink pref r=bholley
Doug Thayer <dothayer@mozilla.com> - Mon, 08 Apr 2019 15:25:47 +0000 - rev 530249
Push 2082 by ffxbld-merge at Mon, 01 Jul 2019 08:34:18 +0000
Bug 1538710 - Remove disable-shrink pref r=bholley Differential Revision: https://phabricator.services.mozilla.com/D25134
f5f916011032472ba3e09b4880c856fad00da189: Bug 1538710 - Move texture_cache cleanup to beginning of all frames r=bholley
Doug Thayer <dothayer@mozilla.com> - Mon, 08 Apr 2019 15:24:03 +0000 - rev 530248
Push 2082 by ffxbld-merge at Mon, 01 Jul 2019 08:34:18 +0000
Bug 1538710 - Move texture_cache cleanup to beginning of all frames r=bholley ... and ensure that, if we do cleanup, we generate frames for every document. Differential Revision: https://phabricator.services.mozilla.com/D25133
eeca0e099b8ad7f730ce3843fa202604e0cf6fbc: Bug 1536689 - Make AssertValidDependentString asserts more fatal. r=bholley
Emilio Cobos Álvarez <emilio@crisal.io> - Wed, 20 Mar 2019 23:13:14 +0000 - rev 527200
Push 2082 by ffxbld-merge at Mon, 01 Jul 2019 08:34:18 +0000
Bug 1536689 - Make AssertValidDependentString asserts more fatal. r=bholley We should catch these issues ASAP. This NS_ASSERTION also bit me in the past. Differential Revision: https://phabricator.services.mozilla.com/D24115
fd2b7f7799733b67f300b7b0147c1c4718528685: Bug 1536466 - Fix nsTDependentString with non-null-terminated buffer assertion r=bholley
Barret Rennie <barret@brennie.ca> - Tue, 19 Mar 2019 23:51:22 +0000 - rev 527047
Push 2082 by ffxbld-merge at Mon, 01 Jul 2019 08:34:18 +0000
Bug 1536466 - Fix nsTDependentString with non-null-terminated buffer assertion r=bholley `gecko_profiler_add_text_marker` was being passed a character pointer and a length to construct a `nsDependentCString`. However, these values were coming from a Rust `&str`, which is not null-terminated, causing an debug assertion to be hit (and possible memory safety issues if mishandle the string). We now construct an `nsDependentCSubstring` instead. Differential Revision: https://phabricator.services.mozilla.com/D24032
2211f0befe5480ceb814f96274e48680b0e7ff0e: Bug 1536466 - Fix nsTDependentString with non-null-terminated buffer assertion r=bholley a=pascalc
Barret Rennie <barret@brennie.ca> - Tue, 19 Mar 2019 23:51:22 +0000 - rev 525661
Push 2032 by ffxbld-merge at Mon, 13 May 2019 09:36:57 +0000
Bug 1536466 - Fix nsTDependentString with non-null-terminated buffer assertion r=bholley a=pascalc `gecko_profiler_add_text_marker` was being passed a character pointer and a length to construct a `nsDependentCString`. However, these values were coming from a Rust `&str`, which is not null-terminated, causing an debug assertion to be hit (and possible memory safety issues if mishandle the string). We now construct an `nsDependentCSubstring` instead. Differential Revision: https://phabricator.services.mozilla.com/D24032
dadc02e71d59e18fb6829fa83509b38ea0acc58c: Bug 1530146 part 2. Back out the fix for bug 1526624, since it's no longer needed. r=bholley
Boris Zbarsky <bzbarsky@mit.edu> - Fri, 01 Mar 2019 00:19:53 +0000 - rev 522799
Push 2032 by ffxbld-merge at Mon, 13 May 2019 09:36:57 +0000
Bug 1530146 part 2. Back out the fix for bug 1526624, since it's no longer needed. r=bholley Differential Revision: https://phabricator.services.mozilla.com/D21482
fe2cba661d5eae557c0d7611bb5442fc0bfc02a2: Bug 1530146 part 1. Switch XrayWaiver to always being same-realm with its target. r=bholley
Boris Zbarsky <bzbarsky@mit.edu> - Fri, 01 Mar 2019 02:54:41 +0000 - rev 522798
Push 2032 by ffxbld-merge at Mon, 13 May 2019 09:36:57 +0000
Bug 1530146 part 1. Switch XrayWaiver to always being same-realm with its target. r=bholley Differential Revision: https://phabricator.services.mozilla.com/D21481
e097bf9457c31adfe082dd38397f0794a674a746: Bug 1512162 - Reenable stack protection for ppc64le in XPConnect. r=bholley
Cameron Kaiser <spectre@floodgap.com> - Wed, 27 Feb 2019 19:31:08 -0800 - rev 522794
Push 2032 by ffxbld-merge at Mon, 13 May 2019 09:36:57 +0000
Bug 1512162 - Reenable stack protection for ppc64le in XPConnect. r=bholley
8e58294baf24a304a10a1ac46607abc7711ad0a3: Bug 1528383 - Allow getting 'wrappedJSObject' without the attribute being defined, r=bholley
Nika Layzell <nika@thelayzells.com> - Tue, 26 Feb 2019 21:19:11 +0000 - rev 522428
Push 2032 by ffxbld-merge at Mon, 13 May 2019 09:36:57 +0000
Bug 1528383 - Allow getting 'wrappedJSObject' without the attribute being defined, r=bholley Differential Revision: https://phabricator.services.mozilla.com/D20016
1b528e3cac94793db32568726080b6cc1209b0e7: Bug 1523843 part 2. Use a single compartment for same-origin Realms in a single page (toplevel load). r=bholley
Boris Zbarsky <bzbarsky@mit.edu> - Thu, 21 Feb 2019 22:56:30 +0000 - rev 521468
Push 2032 by ffxbld-merge at Mon, 13 May 2019 09:36:57 +0000
Bug 1523843 part 2. Use a single compartment for same-origin Realms in a single page (toplevel load). r=bholley Differential Revision: https://phabricator.services.mozilla.com/D19799
9f776274089a2e001b347eb6d92e99d3decba8d8: Bug 1515582. Remove the separate XBL scope setup. r=bholley
Boris Zbarsky <bzbarsky@mit.edu> - Mon, 11 Feb 2019 21:51:47 +0000 - rev 519462
Push 2032 by ffxbld-merge at Mon, 13 May 2019 09:36:57 +0000
Bug 1515582. Remove the separate XBL scope setup. r=bholley With these changes, XBL just runs in the window scope of whatever document it's attached to. Since (outside of tests and "remote XUL") we no longer attach XBL to web documents, this is fine. And "remote XUL" already ran without the XBL scope. Native anonymous content, which used to be placed in the XBL scope to hide it from the page, is now placed in the unprivileged junk scope, so it stays hidden from the page. dom/xbl/test/test_bug944407.xul is being removed because we are changing the behavior it's trying to test for. Since we now always put the XBL in the same scope as the page, script is enabled for the XBL if and only if it's enabled for the page. dom/base/test/test_bug419527.xhtml, dom/events/test/test_bug391568.xhtml, dom/xbl/test/test_bug1086996.xhtml are being switched to a chrome test because otherwise the XBL can't see the getAnonymousNodes method. All the XBL bits are being removed from test_interfaces because we no longer have a separate XBL scope to test the behavior of. js/xpconnect/tests/mochitest/test_nac.xhtml is being removed because XBL no longer has access to NAC unless the page it's attached to does too, so the test doesn't really make sense. layout/xul/test/test_bug1197913.xul is being switched to a chrome test because its XUL elements use bindings that rely on APIs that are not exposed to normal web content. layout/reftests/bugs/495385-2f.xhtml is being removed because I can't think of a sane way to test that in the new world, short of running the reftest as chrome. And it doesn't seem worthwhile to look for a way to do that. dom/xbl/test/test_bug1098628_throw_from_construct.xhtml now needs to expectUncaughtException(), because the exception is now being thrown in Window scope. dom/xbl/test/test_bug1359859.xhtml needs to expectUncaughtException() as needed and not use XPCNativeWrapper (which it doesn't need to anyway now). dom/xbl/test/test_bug389322.xhtml, dom/xbl/test/test_bug400705.xhtml, dom/xbl/test/test_bug401907.xhtml, dom/xbl/test/test_bug403162.xhtml, dom/xbl/test/test_bug526178.xhtml, dom/xbl/test/test_bug639338.xhtml don't need to use XPCNativeWrapper anymore. dom/xbl/test/test_bug821850.html is being removed because it exists only to test XBL scopes. dom/xbl/test/file_bug950909.xml is being changed to work without a separate XBL scope (though whether the test still makes sense at that point is a bit questionable). Differential Revision: https://phabricator.services.mozilla.com/D19260
6c7ae3e0b592577012243038ec85b0b8b6460a05: Bug 1526624. Fix Xray waivers to deal with multiple globals per compartment. r=bholley
Boris Zbarsky <bzbarsky@mit.edu> - Mon, 11 Feb 2019 21:07:45 +0000 - rev 519458
Push 2032 by ffxbld-merge at Mon, 13 May 2019 09:36:57 +0000
Bug 1526624. Fix Xray waivers to deal with multiple globals per compartment. r=bholley In the new setup, they are still same-compartment with their target, but may not be same-realm (due to transplants). We could make them be same-realm by adjusting FixWaiverAfterTransplant, but this is conceptually simpler. Differential Revision: https://phabricator.services.mozilla.com/D19261
ef4325327e46517ba3cfd72a9b4e02c6ccbf9080: Bug 1346759 - Use URI comparison for null principals instead of pointer comparison. r=ckerschb,bholley
Jonathan Kingston <jkt@mozilla.com> - Mon, 11 Feb 2019 18:03:12 +0000 - rev 519405
Push 2032 by ffxbld-merge at Mon, 13 May 2019 09:36:57 +0000
Bug 1346759 - Use URI comparison for null principals instead of pointer comparison. r=ckerschb,bholley Differential Revision: https://phabricator.services.mozilla.com/D12154
6836ad129868dac54c41b17f0d70f6e5c962506e: Bug 1525629. Move wrapper denial warning state to RealmPrivate. r=bholley
Boris Zbarsky <bzbarsky@mit.edu> - Thu, 07 Feb 2019 00:26:40 +0000 - rev 518486
Push 2032 by ffxbld-merge at Mon, 13 May 2019 09:36:57 +0000
Bug 1525629. Move wrapper denial warning state to RealmPrivate. r=bholley This is supposed to be per-global state, and we're planning to have multiple globals per compartment. Differential Revision: https://phabricator.services.mozilla.com/D18850
25b050d6d1e9d926424fa0c6a2754f4ce3838722: Bug 1514049. Remove xpc::GetCompartmentPrincipal. r=bholley
Boris Zbarsky <bzbarsky@mit.edu> - Wed, 30 Jan 2019 19:16:12 +0000 - rev 518483
Push 2032 by ffxbld-merge at Mon, 13 May 2019 09:36:57 +0000
Bug 1514049. Remove xpc::GetCompartmentPrincipal. r=bholley Differential Revision: https://phabricator.services.mozilla.com/D18035
54964c38d7902f71e0d821b22f8acf1206bdf957: Bug 1514050 part 2. Stop recomputing cross-compartment wrappers on document.domain changes. r=bholley
Boris Zbarsky <bzbarsky@mit.edu> - Wed, 30 Jan 2019 19:02:34 +0000 - rev 518482
Push 2032 by ffxbld-merge at Mon, 13 May 2019 09:36:57 +0000
Bug 1514050 part 2. Stop recomputing cross-compartment wrappers on document.domain changes. r=bholley The change to test_clonewrapper.xul is because in the new setup we've already tried handing an object across origins via chrome code, so it has a cached (opaque) wrapper. When we set document.domain and pass the same object again, we end up picking up the cached wrapper when we try to wrap across the compartment boundary, so don't grant access when perhaps we should... This does lead to a possible spec violation in the following situation: 1) Two documents (A, B) start out same-site but different-origin. 2) Privileged code (system or extension) puts a reference to an object from site A into site B. This object gets an opaque CCW. 3) Both sites set document.domain to become same-effective-script-origin and then site B goes through the site A Window and the object graph hanging off it and gets to the object involved. It gets an opaque CCW when it should have a transparent CCW. We could fix this if we kept recomputing wrappers on document.domain change and just fixed the compartment filter used by the recomputation. But this seems like a pretty rare situation, and not one web sites can get into without an assist from a somewhat buggy extension or system code, so let's see whether we can just live with it and remove the recomputation. Differential Revision: https://phabricator.services.mozilla.com/D18032
97aaced3f817773ab004df571077806b59632555: Bug 1514050 part 1. Change the cross-compartment wrappers we use for web objects so we can avoid recomputing them when document.domain changes. r=bholley
Boris Zbarsky <bzbarsky@mit.edu> - Fri, 01 Feb 2019 05:26:48 +0000 - rev 518481
Push 2032 by ffxbld-merge at Mon, 13 May 2019 09:36:57 +0000
Bug 1514050 part 1. Change the cross-compartment wrappers we use for web objects so we can avoid recomputing them when document.domain changes. r=bholley We want to use a transparent CCW if there is any pair of globals, one from each compartment, which are, or have ever been, same origin-domain in the HTML spec sense. This is obviously required in the "are now same origin-domain" case, and in the "were same origin-domain" case it's required because there may be existing transparent CCWs between the compartments and we don't want them to become opaque due to a roundtrip through the compartment boundary. In practice, we need to consider two cases: 1) The two compartments started out same-origin. In this case the two CompartmentOriginInfos will have matching (in the Equals() sense) GetPrincipalIgnoringDocumentDomain(). They will also have matching SiteRef(), of course. 2) The two compartments started out different-origin but then at some point two globals in the compartments ended up same origin-domain. That requires that the two globals be same TLD+1 and have both set document.domain. So in this case the two CompartmentOriginInfos have matching SiteRef() and both test true for HasChangedDocumentDomain(). We only need to worry about this for web compartments, which means that we only need to worry about cases when security checks are symmetric (i.e. originSubsumesTarget == targetSubsumesOrigin) and neither compartment is forcing Xrays. Differential Revision: https://phabricator.services.mozilla.com/D18031
4abfd3bb993421ad8132d3cbde909c8a6c03ec6f: Bug 1471496 part 2. Change the way we do cross-compartment wrappers for Window and Location so they don't ever need to be recomputed. r=bholley
Boris Zbarsky <bzbarsky@mit.edu> - Wed, 06 Feb 2019 14:53:48 +0000 - rev 518407
Push 2032 by ffxbld-merge at Mon, 13 May 2019 09:36:57 +0000
Bug 1471496 part 2. Change the way we do cross-compartment wrappers for Window and Location so they don't ever need to be recomputed. r=bholley The end result we want is that on the web cross-compartment wrappers for WindowProxy and Location are always CrossOriginObjectWrapper. That needs to be true for both cases that are different-origin (as now) and cases that are same-origin, since they might become different-origin due to document.domain changes but we don't want that to affect the wrappers involved. On the web, all security checks are symmetric, so in WrapperFactory::Rewrap we would have originSubsumesTarget == targetSubsumesOrigin in all web cases. I claim that originSubsumesTarget == targetSubsumesOrigin && (!targetSubsumesOrigin || (!originCompartmentPrivate->wantXrays && !targetCompartmentPrivate->wantXrays)) && "object is a WindowProxy or Location" is a necessary and sufficient condition for using CrossOriginObjectWrapper. Comparing to our current code, if originSubsumesTarget and targetSubsumesOrigin are both false, then for the WindowProxy and Location cases we currently end up with the following arguments to SelectWrapper: securityWrapper: true xrayType: XrayForDOMObject waiveXrays: false So SelectWrapper ends up returning CrossOriginObjectWrapper, which the new condition keeps doing. If originSubsumesTarget and targetSubsumesOrigin are both true, then there are two cases. If both compartments have wantXrays false (which is always the case on the web), then we end up with the following arguments to SelectWrapper: securityWrapper: false xrayType: NotXray waiveXrays: false and SelectWrapper returns CrossCompartmentWrapper. We want to do CrossOriginObjectWrapper instead, as explained above. Finally, if originSubsumesTarget and targetSubsumesOrigin are both true but one of the compartments has wantXrays set, then we get: securityWrapper: false xrayType: XrayForDOMObject waiveXrays: might be true or false and then SelectWrapper might return a WaiveXrayWrapper or a PermissiveXrayDOM. In this case we do _not_ want to start returning CrossOriginObjectWrapper, and this is a non-web case anyway, since web compartments can't set wantXrays. Differential Revision: https://phabricator.services.mozilla.com/D18030
462cfc9e96dccec2f32293388f08b4c3c4b197d6: Bug 1471496 part 1. Fix IsPlatformObjectSameOrigin to do the right thing when we're doing first-party isolation but turning off its effects on scripted property access. r=bholley
Boris Zbarsky <bzbarsky@mit.edu> - Wed, 06 Feb 2019 14:53:13 +0000 - rev 518406
Push 2032 by ffxbld-merge at Mon, 13 May 2019 09:36:57 +0000
Bug 1471496 part 1. Fix IsPlatformObjectSameOrigin to do the right thing when we're doing first-party isolation but turning off its effects on scripted property access. r=bholley Differential Revision: https://phabricator.services.mozilla.com/D18029
00cdd5991ace13064e4cbd9344959a58eb7cd9e6: Bug 1471496 part 2. Change the way we do cross-compartment wrappers for Window and Location so they don't ever need to be recomputed. r=bholley
Boris Zbarsky <bzbarsky@mit.edu> - Tue, 05 Feb 2019 18:06:18 +0000 - rev 518211
Push 2032 by ffxbld-merge at Mon, 13 May 2019 09:36:57 +0000
Bug 1471496 part 2. Change the way we do cross-compartment wrappers for Window and Location so they don't ever need to be recomputed. r=bholley The end result we want is that on the web cross-compartment wrappers for WindowProxy and Location are always CrossOriginObjectWrapper. That needs to be true for both cases that are different-origin (as now) and cases that are same-origin, since they might become different-origin due to document.domain changes but we don't want that to affect the wrappers involved. On the web, all security checks are symmetric, so in WrapperFactory::Rewrap we would have originSubsumesTarget == targetSubsumesOrigin in all web cases. I claim that originSubsumesTarget == targetSubsumesOrigin && (!targetSubsumesOrigin || (!originCompartmentPrivate->wantXrays && !targetCompartmentPrivate->wantXrays)) && "object is a WindowProxy or Location" is a necessary and sufficient condition for using CrossOriginObjectWrapper. Comparing to our current code, if originSubsumesTarget and targetSubsumesOrigin are both false, then for the WindowProxy and Location cases we currently end up with the following arguments to SelectWrapper: securityWrapper: true xrayType: XrayForDOMObject waiveXrays: false So SelectWrapper ends up returning CrossOriginObjectWrapper, which the new condition keeps doing. If originSubsumesTarget and targetSubsumesOrigin are both true, then there are two cases. If both compartments have wantXrays false (which is always the case on the web), then we end up with the following arguments to SelectWrapper: securityWrapper: false xrayType: NotXray waiveXrays: false and SelectWrapper returns CrossCompartmentWrapper. We want to do CrossOriginObjectWrapper instead, as explained above. Finally, if originSubsumesTarget and targetSubsumesOrigin are both true but one of the compartments has wantXrays set, then we get: securityWrapper: false xrayType: XrayForDOMObject waiveXrays: might be true or false and then SelectWrapper might return a WaiveXrayWrapper or a PermissiveXrayDOM. In this case we do _not_ want to start returning CrossOriginObjectWrapper, and this is a non-web case anyway, since web compartments can't set wantXrays. Differential Revision: https://phabricator.services.mozilla.com/D18030
3171519994129362108b5077061e595326651aea: Bug 1471496 part 1. Fix IsPlatformObjectSameOrigin to do the right thing when we're doing first-party isolation but turning off its effects on scripted property access. r=bholley
Boris Zbarsky <bzbarsky@mit.edu> - Tue, 05 Feb 2019 18:46:15 +0000 - rev 518210
Push 2032 by ffxbld-merge at Mon, 13 May 2019 09:36:57 +0000
Bug 1471496 part 1. Fix IsPlatformObjectSameOrigin to do the right thing when we're doing first-party isolation but turning off its effects on scripted property access. r=bholley Differential Revision: https://phabricator.services.mozilla.com/D18029
9658187a54fbd9e7c5bda51fb4e5a041a7af77be: Bug 1471496 part 2. Change the way we do cross-compartment wrappers for Window and Location so they don't ever need to be recomputed. r=bholley
Boris Zbarsky <bzbarsky@mit.edu> - Thu, 31 Jan 2019 15:56:22 +0000 - rev 517437
Push 2032 by ffxbld-merge at Mon, 13 May 2019 09:36:57 +0000
Bug 1471496 part 2. Change the way we do cross-compartment wrappers for Window and Location so they don't ever need to be recomputed. r=bholley The end result we want is that on the web cross-compartment wrappers for WindowProxy and Location are always CrossOriginObjectWrapper. That needs to be true for both cases that are different-origin (as now) and cases that are same-origin, since they might become different-origin due to document.domain changes but we don't want that to affect the wrappers involved. On the web, all security checks are symmetric, so in WrapperFactory::Rewrap we would have originSubsumesTarget == targetSubsumesOrigin in all web cases. I claim that originSubsumesTarget == targetSubsumesOrigin && (!targetSubsumesOrigin || (!originCompartmentPrivate->wantXrays && !targetCompartmentPrivate->wantXrays)) && "object is a WindowProxy or Location" is a necessary and sufficient condition for using CrossOriginObjectWrapper. Comparing to our current code, if originSubsumesTarget and targetSubsumesOrigin are both false, then for the WindowProxy and Location cases we currently end up with the following arguments to SelectWrapper: securityWrapper: true xrayType: XrayForDOMObject waiveXrays: false So SelectWrapper ends up returning CrossOriginObjectWrapper, which the new condition keeps doing. If originSubsumesTarget and targetSubsumesOrigin are both true, then there are two cases. If both compartments have wantXrays false (which is always the case on the web), then we end up with the following arguments to SelectWrapper: securityWrapper: false xrayType: NotXray waiveXrays: false and SelectWrapper returns CrossCompartmentWrapper. We want to do CrossOriginObjectWrapper instead, as explained above. Finally, if originSubsumesTarget and targetSubsumesOrigin are both true but one of the compartments has wantXrays set, then we get: securityWrapper: false xrayType: XrayForDOMObject waiveXrays: might be true or false and then SelectWrapper might return a WaiveXrayWrapper or a PermissiveXrayDOM. In this case we do _not_ want to start returning CrossOriginObjectWrapper, and this is a non-web case anyway, since web compartments can't set wantXrays. Differential Revision: https://phabricator.services.mozilla.com/D18030
2ff333373fe4cc5cdd2a05ff4686f1640be5b280: Bug 1471496 part 1. Fix IsPlatformObjectSameOrigin to do the right thing when we're doing first-party isolation but turning off its effects on scripted property access. r=bholley
Boris Zbarsky <bzbarsky@mit.edu> - Thu, 31 Jan 2019 15:53:24 +0000 - rev 517436
Push 2032 by ffxbld-merge at Mon, 13 May 2019 09:36:57 +0000
Bug 1471496 part 1. Fix IsPlatformObjectSameOrigin to do the right thing when we're doing first-party isolation but turning off its effects on scripted property access. r=bholley Differential Revision: https://phabricator.services.mozilla.com/D18029
9474df714baf1145fe9cdb2ba8e659b4ac7a7404: Bug 1517055 - Revendor ANGLE mozilla/firefox-66. (1xN texture cherry-pick) r=bholley
Jeff Gilbert <jgilbert@mozilla.com> - Tue, 22 Jan 2019 11:45:51 -0800 - rev 514972
Push 1953 by ffxbld-merge at Mon, 11 Mar 2019 12:10:20 +0000
Bug 1517055 - Revendor ANGLE mozilla/firefox-66. (1xN texture cherry-pick) r=bholley Differential Revision: https://phabricator.services.mozilla.com/D17295
8c488b723dc7a5ee007d3081b651d0b55e2b0883: Bug 1517055 - Update update-angle.py for newer ANGLE changes. r=bholley
Jeff Gilbert <jgilbert@mozilla.com> - Tue, 22 Jan 2019 11:21:28 -0800 - rev 514971
Push 1953 by ffxbld-merge at Mon, 11 Mar 2019 12:10:20 +0000
Bug 1517055 - Update update-angle.py for newer ANGLE changes. r=bholley Differential Revision: https://phabricator.services.mozilla.com/D17296
565a04cfb0e443328f4b2c74e2ce439fc12eaa9f: Bug 1160757. Make it clear that XrayWrapper::getPropertyDescriptor is unused. r=bholley
Boris Zbarsky <bzbarsky@mit.edu> - Mon, 21 Jan 2019 03:34:29 +0000 - rev 514725
Push 1953 by ffxbld-merge at Mon, 11 Mar 2019 12:10:20 +0000
Bug 1160757. Make it clear that XrayWrapper::getPropertyDescriptor is unused. r=bholley Differential Revision: https://phabricator.services.mozilla.com/D15669
8c6fcfca64219879ccdefa96ee04a33d39216fbe: Bug 1363208 part 1. Add a MaybeWrapObject function that works on JSObject* instead of JS::Value. r=peterv,bholley
Boris Zbarsky <bzbarsky@mit.edu> - Mon, 21 Jan 2019 03:24:42 +0000 - rev 514657
Push 1953 by ffxbld-merge at Mon, 11 Mar 2019 12:10:20 +0000
Bug 1363208 part 1. Add a MaybeWrapObject function that works on JSObject* instead of JS::Value. r=peterv,bholley Differential Revision: https://phabricator.services.mozilla.com/D15424
afb8c84c9677465e5076dc89081aefb98e161def: Bug 1441308 - Add pref to disable texture cache clear r=bholley
Doug Thayer <dothayer@mozilla.com> - Thu, 10 Jan 2019 16:59:47 +0000 - rev 513287
Push 1953 by ffxbld-merge at Mon, 11 Mar 2019 12:10:20 +0000
Bug 1441308 - Add pref to disable texture cache clear r=bholley To facilitate testing of document splitting before it is preffed on, I'm adding a pref to disable clearing the texture cache, since this will currently crash the browser with doc splitting on. Depends on D13840 Differential Revision: https://phabricator.services.mozilla.com/D13841
95537e83071a4f37bcccdc89c69a48dc74344672: Bug 1441308 - Make WR caches document-aware r=bholley
Doug Thayer <dothayer@mozilla.com> - Thu, 10 Jan 2019 16:59:06 +0000 - rev 513285
Push 1953 by ffxbld-merge at Mon, 11 Mar 2019 12:10:20 +0000
Bug 1441308 - Make WR caches document-aware r=bholley This change makes the various WR caches segment their cached data by document, so that documents' data are not evicted out from underneath them. Differential Revision: https://phabricator.services.mozilla.com/D13343
4e654e9222bd7d2e16ab62bd3d3441059b25d0c8: Bug 1518991 - Make nsIPrincipal URI getter infallible; r=bholley
Kyle Machulis <kyle@nonpolynomial.com> - Thu, 10 Jan 2019 05:44:33 +0000 - rev 513191
Push 1953 by ffxbld-merge at Mon, 11 Mar 2019 12:10:20 +0000
Bug 1518991 - Make nsIPrincipal URI getter infallible; r=bholley nsIPrincipal::GetURI returns NS_OK for all implementations. Make it infallible so we can clean up status checks in C++ code that uses principals. Differential Revision: https://phabricator.services.mozilla.com/D16145
c5d46599eb99b0edacc1b29b66814189a0ab8423: Bug 1516237 - Fix FixWaiverAfterTransplant to nuke CCWs for oldWaiver in the new compartment. r=bholley
Jan de Mooij <jdemooij@mozilla.com> - Thu, 03 Jan 2019 09:04:02 +0000 - rev 512366
Push 1953 by ffxbld-merge at Mon, 11 Mar 2019 12:10:20 +0000
Bug 1516237 - Fix FixWaiverAfterTransplant to nuke CCWs for oldWaiver in the new compartment. r=bholley This case can come up with same-compartment realms. Keeping these CCWs would confuse RemapWrapper because it'd be called with the CCW and target in the same compartment. Differential Revision: https://phabricator.services.mozilla.com/D15491