19122ea4c60fba70d7f1f4dc83aea3d4e9146fdf: Bug 1186265 - Resurrect DOMQuad.bounds (deprecated) and count its uses. r=bz draft
Blake Kaplan <mrbkap@gmail.com> - Wed, 23 May 2018 16:56:22 -0700 - rev 799146
Push 110936 by bmo:mrbkap@mozilla.com at Thu, 24 May 2018 00:10:16 +0000
Bug 1186265 - Resurrect DOMQuad.bounds (deprecated) and count its uses. r=bz I've made the returned object from .bounds not live. If that's not OK, I'll resurrect DOMBounds (removed in a previous patch). This also forces DOMQuad.toJSON() to only return the points. MozReview-Commit-ID: 10TY5oJUmTN
27f02aec96bacd48512bf7f084ec902436c46666: Bug 1186265 - Update wpt test expectations now that DOMPoint is updated. r=bz draft
Blake Kaplan <mrbkap@gmail.com> - Tue, 22 May 2018 14:58:51 -0700 - rev 799145
Push 110936 by bmo:mrbkap@mozilla.com at Thu, 24 May 2018 00:10:16 +0000
Bug 1186265 - Update wpt test expectations now that DOMPoint is updated. r=bz One note: DOMPoint-001.html had a couple of instances where it was assuming that there is still a constructor that will unpack an object as the first argument. This fixes the expectations to follow what actually happens. MozReview-Commit-ID: 7YrYhk3bfbW
5da033179994a8fefc445cce78c04713cf39bad6: Bug 1186265 - Partially update DOMQuad, DOMRect, DOMMatrix. r=bz draft
Blake Kaplan <mrbkap@gmail.com> - Thu, 26 Apr 2018 14:19:58 -0700 - rev 799144
Push 110936 by bmo:mrbkap@mozilla.com at Thu, 24 May 2018 00:10:16 +0000
Bug 1186265 - Partially update DOMQuad, DOMRect, DOMMatrix. r=bz Some notes: this does not fully bring us to compliance to the current spec. Instead, these are the fixes that I needed to make in order to make css/geometry/interfaces.html pass with the DOMPoint changes in the previous patches. I don't fully understand why that patch caused the test to fail the way it did, but it ended up being easier to fix our code than understand why the harness was falling over. The DOMQuad::QuadBounds class was the source of some confusion for me. Now that DOMRectReadOnly is a concrete class with members, I wanted to avoid wasting them. However, the spec is unclear as to whether a DOMQuad's bound's should be live -- that is because DOMQuad exposes DOMPoint, we can set its points after retrieving a QuadBounds object. Our current code is live, setting the points changes the QuadBounds. Chromium's current behavior is to never update the QuadBounds object. I've left our behavior untouched in this patch (and waste 4 doubles per QuadBounds object), but I am intending to file a bug to understand what the intent of the spec is. I wonder if the author intended the points to be DOMPointReadOnly instead. If so, we could simplify the DOMRectReadOnly code and get rid of the virtual getters, which would be nice. I also wasn't thrilled to put the DOMMatrix setters on the DOMMatrixReadOnly class, but for brevity and simplicity of implementation, I've made them public. I briefly considered making the setters protected on the ReadOnly version of the class, but I'm not convinced that having to explicitly make them public on the derived class is worth the extra copies of the names. MozReview-Commit-ID: CjdW4Nbnc6A
64019ea6ed2d575285e92ac8ca0d8e036ce63c50: Bug 1186265 - Remove DOMPoint constructor taking a DOMPointInit. r=bz draft
Blake Kaplan <mrbkap@gmail.com> - Thu, 29 Mar 2018 16:19:31 -0700 - rev 799143
Push 110936 by bmo:mrbkap@mozilla.com at Thu, 24 May 2018 00:10:16 +0000
Bug 1186265 - Remove DOMPoint constructor taking a DOMPointInit. r=bz The Web IDL for DOMPoint no longer has this constructor. As far as I can tell, it is still unused, so let's follow the spec. MozReview-Commit-ID: 6Lz1BN5YAV5
0c7ccd6a9dca5d81f03a1426192fa4465ebf36d7: Bug 1461285 - Backed out 62908a56c59f (bug 1415330) for causing nested DOMSubtreeModified event.r?emilio draft
Xidorn Quan <me@upsuper.org> - Thu, 24 May 2018 09:54:37 +1000 - rev 799142
Push 110935 by xquan@mozilla.com at Thu, 24 May 2018 00:03:50 +0000
Bug 1461285 - Backed out 62908a56c59f (bug 1415330) for causing nested DOMSubtreeModified event.r?emilio MozReview-Commit-ID: HesaR9prhvy
4235e0be5cdf1c3d410ce28c38c8da1ad7cd74c0: mybase draft
Xidorn Quan <quanxunzhen@gmail.com> - Wed, 04 Feb 2015 08:24:16 +1100 - rev 799141
Push 110935 by xquan@mozilla.com at Thu, 24 May 2018 00:03:50 +0000
mybase MozReview-Commit-ID: AIse40brXhE
74468af28d05dd921aa85344c480a937f1d8bc23: Bug 1149357: Properly update responsive images for density changes. r?dholbert draft
Emilio Cobos Álvarez <emilio@crisal.io> - Wed, 23 May 2018 11:19:49 +0200 - rev 799140
Push 110934 by bmo:emilio@crisal.io at Wed, 23 May 2018 23:57:30 +0000
Bug 1149357: Properly update responsive images for density changes. r?dholbert Before that we were not notifying the image frame in any way if we ended up not doing a load, and we were instead relying on the reflow the viewport resize caused to get the new density in ComputeSize from the content node (but nowhere else, since that's the bug part 1 fixes). This was generally unsound, since you can stash random media in a sizes= attribute, which don't necessarily needs to cause a reflow. Now we need to notify necessarily because nsImageFrame stores the adjusted intrinsic size. mCurrentDensity could also get out of sync as well, when the selected image density changed, but we ended up returning early because our source hadn't change in the first early exit. This patch moves us to a model where we don't re-trigger loads for density changes if the source doesn't change (unless we pass aAlwaysLoad when we need to, per spec). This matches our previous behavior (without the bugginess of not updating the intrinsic size), and also Chromium, at least. This changes behavior in one case, which is when we don't load the same source node, but we have the same source URL, and the density does change. This could happen with <picture> and two <source>s with same source and different media and sizes. This makes our behavior consistent with the behavior we have when both the source and the density doesn't change. Blink and WebKit do trigger a second image load both when the source changes without changing density and when density changes. I'll file a spec issue, since per: https://html.spec.whatwg.org/#reacting-to-environment-changes We should be triggering the load when the density changes but the source doesn't as well, but no UA does that. I filed https://github.com/whatwg/html/issues/3709 with a little summary of the situation and what I think the behavior should be (which is what this patch implements). That being said, I'll update the impl if the spec people think otherwise :). MozReview-Commit-ID: Eqy16ygHRLo
774a94f7717e53975e091adeab1ee3d82f14d7fb: Bug 1463924 - Remove Dev. Edition promo doorhanger. r=jdescottes draft
J. Ryan Stinnett <jryans@gmail.com> - Wed, 23 May 2018 18:30:36 -0500 - rev 799139
Push 110933 by bmo:jryans@gmail.com at Wed, 23 May 2018 23:31:36 +0000
Bug 1463924 - Remove Dev. Edition promo doorhanger. r=jdescottes MozReview-Commit-ID: LIg6o35CvD2
957a23b717fe9faab39330adeee3a5490798a109: Bug 1462776 - Add subtest support to raptor; r?ahal draft
Rob Wood <rwood@mozilla.com> - Wed, 23 May 2018 15:14:41 -0400 - rev 799138
Push 110932 by rwood@mozilla.com at Wed, 23 May 2018 22:59:43 +0000
Bug 1462776 - Add subtest support to raptor; r?ahal Some minor changes to allow running subtests in Raptor. With this patch (and the other commit in this series) you can run raptor tests that have mutliple subtests. For example, you can specify a raptor test INI and every test inside that INI will be run and ultimately reported as subtests. This will allow, for example, the raptor tp6 test to have multiple testpages. Also just one of the subtests itself can be specified to be run instead of the entire INI. MozReview-Commit-ID: Fto7wNOzRft
5a27d04fc64c4df7c3198cfe8b8288d56822a323: Bug 1462776 - Run single raptor test or multiple subtests based on test name cmd line arg; r?ahal draft
Rob Wood <rwood@mozilla.com> - Fri, 18 May 2018 15:33:26 -0400 - rev 799137
Push 110932 by rwood@mozilla.com at Wed, 23 May 2018 22:59:43 +0000
Bug 1462776 - Run single raptor test or multiple subtests based on test name cmd line arg; r?ahal MozReview-Commit-ID: 3hVDkEgqCD
6cbb709709fada41e6c257f3a7456469ef91a18c: Bug 1461046 Part 5: Add reftests that verify empty shapes still contribute their edges to float areas. draft
Brad Werth <bwerth@mozilla.com> - Wed, 23 May 2018 12:46:54 -0700 - rev 799136
Push 110931 by bwerth@mozilla.com at Wed, 23 May 2018 22:55:34 +0000
Bug 1461046 Part 5: Add reftests that verify empty shapes still contribute their edges to float areas. MozReview-Commit-ID: 9YiQoNZSG5i
8f018a31429842bf03dfde6e0f42ba9dfa558303: Bug 1461046 Part 4: Change PolygonShapeInfo to tolerate polygons with only 1 or 2 vertices. draft
Brad Werth <bwerth@mozilla.com> - Tue, 22 May 2018 15:54:21 -0700 - rev 799135
Push 110931 by bwerth@mozilla.com at Wed, 23 May 2018 22:55:34 +0000
Bug 1461046 Part 4: Change PolygonShapeInfo to tolerate polygons with only 1 or 2 vertices. MozReview-Commit-ID: ICcIUulgSCW
94790779bc98916363e99abee636cfd6c67f333b: Bug 1461046 Part 3: Change RoundedBoxShapeInfo to tolerate empty rects. draft
Brad Werth <bwerth@mozilla.com> - Fri, 18 May 2018 17:38:41 -0700 - rev 799134
Push 110931 by bwerth@mozilla.com at Wed, 23 May 2018 22:55:34 +0000
Bug 1461046 Part 3: Change RoundedBoxShapeInfo to tolerate empty rects. MozReview-Commit-ID: FNQwXdeqfua
d9caef56884d21e049cabd034f8b45d08a5097de: Bug 1461046 Part 2: Change ShapeUtils::ComputeInsetRect to return the inverse of a rect deflated more than its bounds can tolerate. draft
Brad Werth <bwerth@mozilla.com> - Fri, 18 May 2018 17:51:19 -0700 - rev 799133
Push 110931 by bwerth@mozilla.com at Wed, 23 May 2018 22:55:34 +0000
Bug 1461046 Part 2: Change ShapeUtils::ComputeInsetRect to return the inverse of a rect deflated more than its bounds can tolerate. MozReview-Commit-ID: IScKyqzjMoy
c639199998386b5d1b49f9d90c3f3fe37afde57f: Bug 1461046 Part 1: Change EllipseShapeInfo to tolerate empty circles/ellipses and treat them as singular points/lines (possibly expanded by shape-margin). draft
Brad Werth <bwerth@mozilla.com> - Fri, 18 May 2018 17:13:22 -0700 - rev 799132
Push 110931 by bwerth@mozilla.com at Wed, 23 May 2018 22:55:34 +0000
Bug 1461046 Part 1: Change EllipseShapeInfo to tolerate empty circles/ellipses and treat them as singular points/lines (possibly expanded by shape-margin). MozReview-Commit-ID: 69VQiRjhtqA
01eca14ea03cd6cffba04d5e8274977d300849e1: Bug 1458767 - Lazy require the HighlightersOverlay in the Inspector. r=pbro draft
Gabriel Luong <gabriel.luong@gmail.com> - Wed, 23 May 2018 18:53:18 -0400 - rev 799131
Push 110930 by bmo:gl@mozilla.com at Wed, 23 May 2018 22:53:41 +0000
Bug 1458767 - Lazy require the HighlightersOverlay in the Inspector. r=pbro MozReview-Commit-ID: Ca8Mi4BEorA
0a7302e2690ccc2b809e2eb3df655756839f5425: Bug 1462434 - Prevent baseline coverage tests from being skipped. r?jmaher draft
Gregory Mierzwinski <gmierz2@outlook.com> - Wed, 23 May 2018 12:41:52 -0400 - rev 799130
Push 110929 by bmo:gmierz2@outlook.com at Wed, 23 May 2018 22:53:05 +0000
Bug 1462434 - Prevent baseline coverage tests from being skipped. r?jmaher This patch prevents baseline coverage tests from being skipped when too many tests are being run. MozReview-Commit-ID: JVTOYZAXbwf
5db2cf61b2385c5d5978cd79a71a353541378ea0: Bug 1450069 - Have the raptor control server shutdown the browser; r?ahal draft
Rob Wood <rwood@mozilla.com> - Wed, 23 May 2018 18:45:51 -0400 - rev 799129
Push 110928 by rwood@mozilla.com at Wed, 23 May 2018 22:52:24 +0000
Bug 1450069 - Have the raptor control server shutdown the browser; r?ahal Having the control server shutdown the browser via the browser pid is a better (and cross-browser) solution. MozReview-Commit-ID: 19Gwg5TwIIy
10f52bc1b0a47a7f0ca708d0f78e2b4d03e438c6: Bug 1457084 - Increase max chunk memory usage limit, r=mayhemer
Michal Novotny <michal.novotny> - Wed, 23 May 2018 05:03:00 +0300 - rev 799128
Push 110928 by rwood@mozilla.com at Wed, 23 May 2018 22:52:24 +0000
Bug 1457084 - Increase max chunk memory usage limit, r=mayhemer We can hit the limit very easily when writing javascript bytecode as alternative data to the cache entry because all data is written at once but CacheFileOutputStream splits it into chunks which are then written on a backgound thread. 40MB was chosen because bytecode is usually 4x-10x larger than the original data, so it can occupy most of the cache entry which is limited to 50MB.
b6657c5618f0c1ad287f8448301ba6131a795c15: Bug 1456871 - Consider increasing disk cache size, r=mayhemer
Michal Novotny <michal.novotny> - Tue, 22 May 2018 14:14:00 +0300 - rev 799127
Push 110928 by rwood@mozilla.com at Wed, 23 May 2018 22:52:24 +0000
Bug 1456871 - Consider increasing disk cache size, r=mayhemer The patch changes default cache size on desktop and mobile. The smart cache size calculation is changed to grow faster. It also introduces a cache size limit for users who have enabled clearing cache on shutdown, which should reduce number of shutdown crashes (bug 1356853).
(0) -300000 -100000 -30000 -10000 -3000 -1000 -300 -100 -50 -20 +20 +50 +100 +300 +1000 +3000 +10000 +30000 tip