8ed236855a3a54d85c687e3864de415af53ed00c: Bug 1169432 part 3: Use nsTArray::Contains instead of nsTArray::IndexOf(), for brevity, in nsTableFrame. r=mats
Daniel Holbert <dholbert@cs.stanford.edu> - Fri, 05 Jun 2015 15:39:13 -0700 - rev 278313
Push 4932 by jlund@mozilla.com at Mon, 10 Aug 2015 18:23:06 +0000
Bug 1169432 part 3: Use nsTArray::Contains instead of nsTArray::IndexOf(), for brevity, in nsTableFrame. r=mats
d576f294df12d5767d8f69e88472f0a41362eb8f: Bug 1169432 part 2: Refactor nsTableFrame::Init. r=mats
Daniel Holbert <dholbert@cs.stanford.edu> - Fri, 05 Jun 2015 15:39:06 -0700 - rev 278312
Push 4932 by jlund@mozilla.com at Mon, 10 Aug 2015 18:23:06 +0000
Bug 1169432 part 2: Refactor nsTableFrame::Init. r=mats
6522add87d6bb4fa693c3089cc0c0e10ba77c301: Bug 1055310 - Step 3: Move syscall interceptions into SandboxFilter.cpp. r=kang
Jed Davis <jld@mozilla.com> - Fri, 05 Jun 2015 15:17:40 -0700 - rev 278311
Push 4932 by jlund@mozilla.com at Mon, 10 Aug 2015 18:23:06 +0000
Bug 1055310 - Step 3: Move syscall interceptions into SandboxFilter.cpp. r=kang We can now keep the part of the policy implemented by upcalls to userspace in the same place as the part of the policy that's handled entirely in the kernel. This will become more useful in the future (e.g., bug 930258).
b3f98086e8cc3cbf7cd17d8336e2bce77c255252: Bug 1055310 - Step 2: Move SIGSYS handling to Chromium TrapRegistry. r=kang
Jed Davis <jld@mozilla.com> - Fri, 05 Jun 2015 15:17:35 -0700 - rev 278310
Push 4932 by jlund@mozilla.com at Mon, 10 Aug 2015 18:23:06 +0000
Bug 1055310 - Step 2: Move SIGSYS handling to Chromium TrapRegistry. r=kang This is more complicated than I'd like it to be, because we don't have a good way to combine a specific trap function's knowledge that we want to get a crash dump with the SIGSYS handler's copy of the unprocessed signal info (which breakpad wants). The bpf_dsl interface requires a specific trap function type (via the TrapRegistry superclass), so even if we implement our own registry we can't change what's passed to it. Normally we could use thread-local storage to get around that, but it's not async signal safe. As a result there is an imperfect compromise: the trap function returns a failure with ENOSYS, Chromium's SIGSYS handler writes it into the context, our SIGSYS handler reads it back out and uses a copy of the original signal context for the crash dump. Other error codes (and returning ENOSYS via the seccomp-bpf policy itself) are handled normally.
32872aebf4abd375c974f1c752967de182680323: Bug 1055310 - Step 1: Convert seccomp-bpf policies to Chromium PolicyCompiler. r=kang
Jed Davis <jld@mozilla.com> - Fri, 05 Jun 2015 15:17:32 -0700 - rev 278309
Push 4932 by jlund@mozilla.com at Mon, 10 Aug 2015 18:23:06 +0000
Bug 1055310 - Step 1: Convert seccomp-bpf policies to Chromium PolicyCompiler. r=kang This completely rewrites SandboxFilter.cpp and removes SandboxAssembler. System calls are now loosely grouped by what they do, now that order doesn't matter, and most of the intersection the content and media plugin whitelists is moved into a common superclass. Hopefully this improves the readability and comprehensibility of the syscall policies. Also, the macros that take the syscall name are gone, because a plain case label usually suffices now (the CASES_FOR_thing macros are a little unsightly, but they're relatively simple), and at one point we saw strange macro expansion issues with system header files that #define'd some syscall names. The signal handling is not migrated yet, so Trap() actions can't be used yet; the next patch will take care of that, and to keep the intermediate state working there's a minimal shim. Bonus fix: non-const global variables use the "g" prefix; "s" is for static class members and static variables in a function (where the default is to allocate a separate copy per instance/activation).
7128670beeea8dedbce4177d8cefd65a6ae2a503: Bug 822129: don't alloc/free on every packet send in MediaPipeline r=bwc
Randell Jesup <rjesup@jesup.org> - Fri, 05 Jun 2015 15:16:45 -0400 - rev 278308
Push 4932 by jlund@mozilla.com at Mon, 10 Aug 2015 18:23:06 +0000
Bug 822129: don't alloc/free on every packet send in MediaPipeline r=bwc
56e2e974eae2ade79607f7385ab79187ca3c1861: Bug 1171094. Disallow D3D11 ANGLE with old DisplayLink drivers. r=Bas
Jeff Muizelaar <jmuizelaar@mozilla.com> - Fri, 05 Jun 2015 17:17:30 -0400 - rev 278307
Push 4932 by jlund@mozilla.com at Mon, 10 Aug 2015 18:23:06 +0000
Bug 1171094. Disallow D3D11 ANGLE with old DisplayLink drivers. r=Bas
564799379b68e31fd1731662e300a89e36447d4f: Backed out changeset 2cb094627289 (bug 822129) for cppunittest orange
Wes Kocher <wkocher@mozilla.com> - Fri, 05 Jun 2015 14:16:56 -0700 - rev 278306
Push 4932 by jlund@mozilla.com at Mon, 10 Aug 2015 18:23:06 +0000
Backed out changeset 2cb094627289 (bug 822129) for cppunittest orange
bd0374f08fcd746432a9dedb67902c4cd25a52d4: bug 1171728 - Only look for an OuterDoc accessible parent of a proxy if it doesn't have a proxy parent r=lsocks
Trevor Saunders <tbsaunde@tbsaunde.org> - Thu, 04 Jun 2015 11:32:27 -0400 - rev 278305
Push 4932 by jlund@mozilla.com at Mon, 10 Aug 2015 18:23:06 +0000
bug 1171728 - Only look for an OuterDoc accessible parent of a proxy if it doesn't have a proxy parent r=lsocks
78fc82c0601a4b90d76e2974ff4d64580c24f22b: bug 1170595 - switch to sending __delete__ from the parent instead of the child r=davidb, smaug
Trevor Saunders <tbsaunde@tbsaunde.org> - Tue, 02 Jun 2015 10:30:51 -0400 - rev 278304
Push 4932 by jlund@mozilla.com at Mon, 10 Aug 2015 18:23:06 +0000
bug 1170595 - switch to sending __delete__ from the parent instead of the child r=davidb, smaug After the child sends the __delete__ message to the parent there is a period of time in which the actor is registered, but the parent hasn't yet processed the __delete__ message. During that time the parent can still try and send messages to the child, but that will crash the child process. Fix this race by making the child send a shutdown message to the parent, and have the parent send __delete__ when it handles that message.
33283f55d8efbb3316cd690fe23c58ad5136afb6: bug 1170595 - always use IdToAccessible to convert ids to accessibles r=lsocks
Trevor Saunders <tbsaunde@tbsaunde.org> - Mon, 01 Jun 2015 15:27:35 -0400 - rev 278303
Push 4932 by jlund@mozilla.com at Mon, 10 Aug 2015 18:23:06 +0000
bug 1170595 - always use IdToAccessible to convert ids to accessibles r=lsocks
451715a0e1dc65c3a6512af8d9388272c99caebb: Bug 1164397 - Part 12: Add a test case for the service worker responding to normal and cached HTTP->HTTPS responses; r=jdm
Ehsan Akhgari <ehsan@mozilla.com> - Fri, 05 Jun 2015 14:58:29 -0400 - rev 278302
Push 4932 by jlund@mozilla.com at Mon, 10 Aug 2015 18:23:06 +0000
Bug 1164397 - Part 12: Add a test case for the service worker responding to normal and cached HTTP->HTTPS responses; r=jdm
952ffb707f787331066dd9b7c28e3362f25a749f: Bug 1164397 - Part 11: Add a test case for the service worker responding to HTTPS normal and cached Responses; r=jdm
Ehsan Akhgari <ehsan@mozilla.com> - Fri, 05 Jun 2015 14:41:33 -0400 - rev 278301
Push 4932 by jlund@mozilla.com at Mon, 10 Aug 2015 18:23:06 +0000
Bug 1164397 - Part 11: Add a test case for the service worker responding to HTTPS normal and cached Responses; r=jdm
c8adea6c500930dd09bb86d14d936308d3e9cf47: Bug 1164397 - Part 10: Add a test case for the service worker for an app:// URI responding with cached HTTP and HTTPS responses; r=jdm
Ehsan Akhgari <ehsan@mozilla.com> - Fri, 05 Jun 2015 11:57:31 -0400 - rev 278300
Push 4932 by jlund@mozilla.com at Mon, 10 Aug 2015 18:23:06 +0000
Bug 1164397 - Part 10: Add a test case for the service worker for an app:// URI responding with cached HTTP and HTTPS responses; r=jdm
a675f30287e97d3d0b94c9be9046b3f1cfefa414: Bug 1164397 - Part 9: Add a test case for the service worker for an app:// URI responding with a redirected HTTPS response; r=jdm
Ehsan Akhgari <ehsan@mozilla.com> - Fri, 05 Jun 2015 10:56:37 -0400 - rev 278299
Push 4932 by jlund@mozilla.com at Mon, 10 Aug 2015 18:23:06 +0000
Bug 1164397 - Part 9: Add a test case for the service worker for an app:// URI responding with a redirected HTTPS response; r=jdm
cbc748ab81ee24c8bde9ba22753cfe5cea503287: Bug 1164397 - Part 8: Add a test case for the service worker for an app:// URI responding with a redirected Response; r=jdm
Ehsan Akhgari <ehsan@mozilla.com> - Thu, 04 Jun 2015 16:32:31 -0400 - rev 278298
Push 4932 by jlund@mozilla.com at Mon, 10 Aug 2015 18:23:06 +0000
Bug 1164397 - Part 8: Add a test case for the service worker for an app:// URI responding with a redirected Response; r=jdm
c28b933c091d26196bbd61c408006fb2d77a3b2a: Bug 1164397 - Part 7: Add a test case for the redirected Response object being stored in the DOM Cache; r=jdm
Ehsan Akhgari <ehsan@mozilla.com> - Thu, 28 May 2015 14:06:19 -0400 - rev 278297
Push 4932 by jlund@mozilla.com at Mon, 10 Aug 2015 18:23:06 +0000
Bug 1164397 - Part 7: Add a test case for the redirected Response object being stored in the DOM Cache; r=jdm
9fe75f3e2131b2671d909290a083b33db8e4351d: Bug 1164397 - Part 6: Add a test case for the service worker responding with a redirected Response; r=jdm
Ehsan Akhgari <ehsan@mozilla.com> - Thu, 21 May 2015 11:11:20 -0400 - rev 278296
Push 4932 by jlund@mozilla.com at Mon, 10 Aug 2015 18:23:06 +0000
Bug 1164397 - Part 6: Add a test case for the service worker responding with a redirected Response; r=jdm
095f8f54dcd2a26b9302677d61337f4341a857bb: Bug 1164397 - Part 5: Save the redirected flag and the redirected URI in the DOM cache; r=bkelly
Ehsan Akhgari <ehsan@mozilla.com> - Tue, 02 Jun 2015 18:02:05 -0400 - rev 278295
Push 4932 by jlund@mozilla.com at Mon, 10 Aug 2015 18:23:06 +0000
Bug 1164397 - Part 5: Save the redirected flag and the redirected URI in the DOM cache; r=bkelly
435358bf7c12a323aef04b0605753ec586e1bfe6: Bug 1164397 - Part 4: Add infromation about whether a channel was redirected to ChannelInfo; r=jdm
Ehsan Akhgari <ehsan@mozilla.com> - Tue, 02 Jun 2015 18:01:26 -0400 - rev 278294
Push 4932 by jlund@mozilla.com at Mon, 10 Aug 2015 18:23:06 +0000
Bug 1164397 - Part 4: Add infromation about whether a channel was redirected to ChannelInfo; r=jdm
(0) -100000 -30000 -10000 -3000 -1000 -300 -100 -50 -20 +20 +50 +100 +300 +1000 +3000 +10000 +30000 +100000 +300000 tip