a097a0f0b84006530ceffbee1ebbe0bf91f8c83c: Bug 1406296 (part 1) - Remove the profiler's "displaylistdump" feature. r=mstange.
Nicholas Nethercote <nnethercote@mozilla.com> - Fri, 06 Oct 2017 17:33:30 +1100 - rev 386038
Push 32673 by archaeopteryx@coole-files.de at Fri, 13 Oct 2017 09:13:17 +0000
Bug 1406296 (part 1) - Remove the profiler's "displaylistdump" feature. r=mstange. It's not useful.
ef7ff96cd4d0fd465a7b94925358558764867c03: Bug 1407056: Follow-up: Don't try to truncate data URI strings to a longer length. r=me
Kris Maglione <maglione.k@gmail.com> - Thu, 12 Oct 2017 16:56:37 -0700 - rev 386037
Push 32673 by archaeopteryx@coole-files.de at Fri, 13 Oct 2017 09:13:17 +0000
Bug 1407056: Follow-up: Don't try to truncate data URI strings to a longer length. r=me MozReview-Commit-ID: CDsYXyrhB7T
d480c295d4eb093b1890056cc724e12bda7ac3ca: Bug 1407056: Part 3 - Test that CSP overrides apply correctly based on triggering principals. r=bz
Kris Maglione <maglione.k@gmail.com> - Thu, 12 Oct 2017 15:44:32 -0700 - rev 386036
Push 32673 by archaeopteryx@coole-files.de at Fri, 13 Oct 2017 09:13:17 +0000
Bug 1407056: Part 3 - Test that CSP overrides apply correctly based on triggering principals. r=bz MozReview-Commit-ID: EbGsI3keeG6
41e5a4b54c93e40e92e1e697efa936e90a4c5a41: Bug 1407056: Part 2 - Override page CSP for loads by expanded principals. r=bz,krizsa
Kris Maglione <maglione.k@gmail.com> - Sat, 07 Oct 2017 14:53:30 -0700 - rev 386035
Push 32673 by archaeopteryx@coole-files.de at Fri, 13 Oct 2017 09:13:17 +0000
Bug 1407056: Part 2 - Override page CSP for loads by expanded principals. r=bz,krizsa Per the CSP specification, content injected by extensions is meant to be exempt from page CSP. This patch takes care of the most common case of content injected by extension content scripts, which always have expanded principals which inherit from the page principal. In a follow-up, we'll probably need to extend the exemption to stylesheet content loaded by extension codebase principals. MozReview-Commit-ID: GlY887QAb5V
197ce71943518bfb260f2b2cb3f91b55e58f9341: Bug 1407056: Part 1 - Provide more consistent principal/origin URL to content policies. r=bz,ckerschb
Kris Maglione <maglione.k@gmail.com> - Thu, 12 Oct 2017 15:43:55 -0700 - rev 386034
Push 32673 by archaeopteryx@coole-files.de at Fri, 13 Oct 2017 09:13:17 +0000
Bug 1407056: Part 1 - Provide more consistent principal/origin URL to content policies. r=bz,ckerschb We're currently fairly vague and inconsistent about the values we provide to content policy implementations for requestOrigin and requestPrincipal. In some cases they're the triggering principal, sometimes the loading principal, sometimes the channel principal. Our existing content policy implementations which require or expect a loading principal currently retrieve it from the context node. Since no current callers require the principal to be the loading principal, and some already expect it to be the triggering principal (which there's currently no other way to retrieve), I chose to pass the triggering principal whenever possible, but use the loading principal to determine the origin URL. As a follow-up, I'd like to change the nsIContentPolicy interface to explicitly receive loading and triggering principals, or possibly just LoadInfo instances, rather than poorly-defined request origin/principal/context args. But since that may cause trouble for comm-central, I'd rather not do it as part of this bug. MozReview-Commit-ID: LqD9GxdzMte
5725fbd3af70a19207b6b326db8cc1fad561503d: Bug 1407351 - Remove E10S_TESTING_ONLY defines. r=glandium
Felipe Gomes <felipc@gmail.com> - Thu, 12 Oct 2017 21:44:59 -0300 - rev 386033
Push 32673 by archaeopteryx@coole-files.de at Fri, 13 Oct 2017 09:13:17 +0000
Bug 1407351 - Remove E10S_TESTING_ONLY defines. r=glandium MozReview-Commit-ID: jVUo2l7eQd
f60f54d7af0cc22c79a79bc5152450673530bb6b: Bug 1407351 - Remove E10S_TESTING_ONLY from devtools. r=gregtatum
Felipe Gomes <felipc@gmail.com> - Thu, 12 Oct 2017 21:44:59 -0300 - rev 386032
Push 32673 by archaeopteryx@coole-files.de at Fri, 13 Oct 2017 09:13:17 +0000
Bug 1407351 - Remove E10S_TESTING_ONLY from devtools. r=gregtatum E10s is always supported now, so there's no need for the unsupported notice anymore MozReview-Commit-ID: 6Omdvj6SbaV
b8938454c1f0fcdb58cac9c487f5c25ede5890e2: Bug 1407351 - Simplify check for e10s in about:preferences. r=jaws
Felipe Gomes <felipc@gmail.com> - Thu, 12 Oct 2017 21:44:59 -0300 - rev 386031
Push 32673 by archaeopteryx@coole-files.de at Fri, 13 Oct 2017 09:13:17 +0000
Bug 1407351 - Simplify check for e10s in about:preferences. r=jaws This code that checks the status code is not necessary, the boolean answer is already stored in Services.appinfo.browserTabsRemoteAutostart. MozReview-Commit-ID: 1Vrt4kwsjyU
537e32fd3d480517022cae84675390c0eceaa2d3: Bug 1407351 - Remove Nightly-only e10s checkbox in about:preferences. r=jaws
Felipe Gomes <felipc@gmail.com> - Thu, 12 Oct 2017 21:44:58 -0300 - rev 386030
Push 32673 by archaeopteryx@coole-files.de at Fri, 13 Oct 2017 09:13:17 +0000
Bug 1407351 - Remove Nightly-only e10s checkbox in about:preferences. r=jaws MozReview-Commit-ID: FlbrduhJRLm
3aef2a6367c8835db3de2e63fb2ec61415deb6c1: Bug 1407351 - Remove nightly-only e10s testing features from the main browser window. r=mikedeboer
Felipe Gomes <felipc@gmail.com> - Thu, 12 Oct 2017 21:44:58 -0300 - rev 386029
Push 32673 by archaeopteryx@coole-files.de at Fri, 13 Oct 2017 09:13:17 +0000
Bug 1407351 - Remove nightly-only e10s testing features from the main browser window. r=mikedeboer The only thing that I didn't remove was the process ID on the tab tooltip, which I find to be super helpful. For that, I changed the check from E10S_TESTING_ONLY to NIGHTLY_BUILD. MozReview-Commit-ID: 7AUFyHgXUAk
028a1aeddd0611aca254be24677bcafc6a276fb7: Bug 1407236 - Use allow-oom instead of error: out of memory for racy test, r=jonco
Steve Fink <sfink@mozilla.com> - Wed, 11 Oct 2017 16:28:55 -0700 - rev 386028
Push 32673 by archaeopteryx@coole-files.de at Fri, 13 Oct 2017 09:13:17 +0000
Bug 1407236 - Use allow-oom instead of error: out of memory for racy test, r=jonco
782e1972037f3830bd04cf70ac529969bb796a56: merge mozilla-central to mozilla-inbound. r=merge a=merge
Sebastian Hengst <archaeopteryx@coole-files.de> - Fri, 13 Oct 2017 00:55:27 +0200 - rev 386027
Push 32673 by archaeopteryx@coole-files.de at Fri, 13 Oct 2017 09:13:17 +0000
merge mozilla-central to mozilla-inbound. r=merge a=merge
750de14d83712561cc6b274518b1f7096c83b7cc: Bug 1406570 - "Root" compartment while entering it, r=jonco
Steve Fink <sfink@mozilla.com> - Wed, 11 Oct 2017 17:19:24 -0700 - rev 386026
Push 32673 by archaeopteryx@coole-files.de at Fri, 13 Oct 2017 09:13:17 +0000
Bug 1406570 - "Root" compartment while entering it, r=jonco
8adc032add4e21b85ff4eaa31ae0074434dc2a12: Bug 1402836 - Avoid racing while destroying JS shell contexts, r=jandem.
Brian Hackett <bhackett1024@gmail.com> - Thu, 12 Oct 2017 05:23:29 -0700 - rev 386025
Push 32673 by archaeopteryx@coole-files.de at Fri, 13 Oct 2017 09:13:17 +0000
Bug 1402836 - Avoid racing while destroying JS shell contexts, r=jandem.
d6fdc1d3b07044a6cd84adcc433d3f6a943dca20: Bug 1405397. Part 2. ScrollFrameHelper::BuildDisplayList should only have one way to determine if we are using a displayport/building a async scrollable layer. r=mstange
Timothy Nikkel <tnikkel@gmail.com> - Thu, 12 Oct 2017 17:06:21 -0500 - rev 386024
Push 32673 by archaeopteryx@coole-files.de at Fri, 13 Oct 2017 09:13:17 +0000
Bug 1405397. Part 2. ScrollFrameHelper::BuildDisplayList should only have one way to determine if we are using a displayport/building a async scrollable layer. r=mstange The variable usingDisplayPort was determining if we applied a clip to the displayport (and one other thing), and otherwise mWillBuildScrollableLayer was used to determine those type of things. When https://hg.mozilla.org/mozilla-central/rev/4c8b85e80aeb of bug 1364295 landed it actually changed behaviour even though it was only supposed to simplify code. Before that changeset mWillBuildScrollableLayer was always set to false if we weren't painting to the window because we never considered whether a displayport was set. After that changeset we actually looked to see if a displayport was set and set mWillBuildScrollableLayer to true if we had a displayport even when we weren't painting to the window. So we would have usingDisplayPort == false, and mWillBuildScrollableLayer == true. We fix that be getting rid of usingDisplayPort and using everywhere. This means that after this patch and bug 1364295 we will build display lists for event handling with mWillBuildScrollableLayer == true where we had it false before. So another patch we could make is to make all uses of mWillBuildScrollableLayer also check if we are painting to the window. The decision to expand the dirty rect to the displayport is still restricted to when we are painting to the window and happens in DecideScrollableLayer, so we don't regress bug 745936.
bda0ae08740f58686e9a0131d08a4b37881e8e51: Bug 1405397. Part 1. Only add scrollbars in the "ignore scroll frame" case if we are painting to the window. r=mstange
Timothy Nikkel <tnikkel@gmail.com> - Thu, 12 Oct 2017 17:06:19 -0500 - rev 386023
Push 32673 by archaeopteryx@coole-files.de at Fri, 13 Oct 2017 09:13:17 +0000
Bug 1405397. Part 1. Only add scrollbars in the "ignore scroll frame" case if we are painting to the window. r=mstange This change is effectively a no-op since usingDisplayPort is only true if IsPaintingToWindow() but we need it for the next patch. So I will explain why this patch is correct. At first we set usingDisplayPort to whether or not we had a displayport, which makes sense. But then in https://hg.mozilla.org/mozilla-central/rev/372d32e0ea61 (bug 745936) we had to limit this to when we weren't handling events so we didn't override the event handling dirty/hit rect of size 1x1 with the entire displayport. Then in https://hg.mozilla.org/mozilla-central/rev/254c675a98c5 (bug 980500) we added support for adding scrollbars when we are ignoring the current scroll frame. This was a hack for b2g (and maybe android, where it might still be required) since we shouldn't be drawing the scrollbars when we are specifically ignoring the scrollframe. Only android and b2g have ever used the "ignore scroll frame" mode for their main rendering, so the change was only relevant for them. This changeset simply copied the same condition for using a displayport (!aBuilder->IsForEventDelivery()) to determine when to add scrollbars. Then in https://hg.mozilla.org/mozilla-central/rev/2dc71497e243 (bug 1073290) we determined that it is useless to use displayports when we aren't drawing to the window (and actually can cause problems), so we changed the condition to use a displayport to require painting to the window (which is more restrictive then just not for event handling). However this change understandably missed the changing the condition for adding scrollbars. Thus this patch. The reason we need this is the next patch (essentially) removes the IsPaintingToWindow condition from usingDisplayPort, and then we will erroneously add scrollbars when doing drawWindow calls that also ask to ignore the root scroll frame.
bd0ad3dbf357a122d780925cc0981f3d4deb259a: Bug 1406794 - Provide the CSP keywords in both UTF8 and UTF16 forms. r=ckerschb
Nicholas Nethercote <nnethercote@mozilla.com> - Fri, 06 Oct 2017 16:16:52 +1100 - rev 386022
Push 32673 by archaeopteryx@coole-files.de at Fri, 13 Oct 2017 09:13:17 +0000
Bug 1406794 - Provide the CSP keywords in both UTF8 and UTF16 forms. r=ckerschb This avoids the need for numerous 8-to-16-bit and 16-to-8-bit string conversions. The patch also introduces a higher-order macro, FOR_EACH_CSP_KEYWORD, which defines all the stuff about the keywords in a single place and makes the code nicer.
0160c57b65d9b28c04eb78a1bba905ea57d23119: Bug 1407470 - follow-up - more fixes to crashtests.list condition. r=me
Lee Salzman <lsalzman@mozilla.com> - Thu, 12 Oct 2017 17:38:23 -0400 - rev 386021
Push 32673 by archaeopteryx@coole-files.de at Fri, 13 Oct 2017 09:13:17 +0000
Bug 1407470 - follow-up - more fixes to crashtests.list condition. r=me
7222707904762b443015aeb58cb9eda0b5aa21dc: Bug 1406510 - rewrite TextDrawTarget to push directly into display list. r=jrmuizel
Alexis Beingessner <a.beingessner@gmail.com> - Fri, 06 Oct 2017 13:06:10 -0400 - rev 386020
Push 32673 by archaeopteryx@coole-files.de at Fri, 13 Oct 2017 09:13:17 +0000
Bug 1406510 - rewrite TextDrawTarget to push directly into display list. r=jrmuizel MozReview-Commit-ID: 7rPGlYmmgeg
95c942759fe204fdbe8dd82407ea54fe6755cf18: Bug 1407854 - Part 3: Pass the child node at the offset as an extra argument where possible to CreateNode(); r=masayuki
Ehsan Akhgari <ehsan@mozilla.com> - Wed, 11 Oct 2017 23:16:00 -0400 - rev 386019
Push 32673 by archaeopteryx@coole-files.de at Fri, 13 Oct 2017 09:13:17 +0000
Bug 1407854 - Part 3: Pass the child node at the offset as an extra argument where possible to CreateNode(); r=masayuki This patch converts almost all of the call sites over to passing the extra argument explicitly.
(0) -300000 -100000 -30000 -10000 -3000 -1000 -300 -100 -50 -20 +20 +50 +100 +300 +1000 +3000 +10000 +30000 +100000 tip