4ba5232e1ff12891dbb584654ce19cf284c3f5db: Bug 1441868 - Remove unused css properties; r=bgrins.
Nicolas Chevobbe <nchevobbe@mozilla.com> - Wed, 28 Feb 2018 17:59:32 +0100 - rev 450899
Push 148 by fmarier@mozilla.com at Thu, 29 Mar 2018 23:06:47 +0000
Bug 1441868 - Remove unused css properties; r=bgrins. This also reveals a regression on the border color for warning and error messages in dark mode, which is fixed by this patch. MozReview-Commit-ID: H24hOYVhpr7
bea5b87950b7a2b6d733ef0498648a0e00bab765: Bug 1441830 - Clean up and simplify treechildren styling on Windows. r=jaws
Dão Gottwald <dao@mozilla.com> - Wed, 28 Feb 2018 18:16:00 +0100 - rev 450898
Push 148 by fmarier@mozilla.com at Thu, 29 Mar 2018 23:06:47 +0000
Bug 1441830 - Clean up and simplify treechildren styling on Windows. r=jaws MozReview-Commit-ID: 5V3alTQkNdj
0a2b1c60cec54c6bf65265429d8bee32bfd8b565: Bug 1436113 - Part 2: Refactor "shield-recipe-client" to "normandy" r=Gijs
Mike Cooper <mcooper@mozilla.com> - Wed, 21 Feb 2018 15:02:04 -0800 - rev 450897
Push 148 by fmarier@mozilla.com at Thu, 29 Mar 2018 23:06:47 +0000
Bug 1436113 - Part 2: Refactor "shield-recipe-client" to "normandy" r=Gijs This includes simplifiying the startup process, migrating to a new pref namespace, renaming files, and updating references to the code. MozReview-Commit-ID: A2cYpsjCOAE
88dd78f248e2d6d26af1076b795eff5576c5238b: Bug 1436113 - Part 1: Move browser/extensions/shield-recipe-client to toolkit/components/normandy r=Gijs
Mike Cooper <mcooper@mozilla.com> - Wed, 28 Feb 2018 09:40:47 -0800 - rev 450896
Push 148 by fmarier@mozilla.com at Thu, 29 Mar 2018 23:06:47 +0000
Bug 1436113 - Part 1: Move browser/extensions/shield-recipe-client to toolkit/components/normandy r=Gijs MozReview-Commit-ID: LidgzhI4Z7h
c723ca78deaaf05ec7589b0070fca8154614d4c8: Bug 1174003 part 11: [css-flexbox] Remove IsCrossAxisHorizontal(), and make IsMainAxisHorizontal() a private implementation detail. r=mats
Daniel Holbert <dholbert@cs.stanford.edu> - Wed, 28 Feb 2018 09:41:16 -0800 - rev 450895
Push 148 by fmarier@mozilla.com at Thu, 29 Mar 2018 23:06:47 +0000
Bug 1174003 part 11: [css-flexbox] Remove IsCrossAxisHorizontal(), and make IsMainAxisHorizontal() a private implementation detail. r=mats At this point in the series: - AxisOrientationTracker::IsCrossAxisHorizontal() has zero callers, so it can be deleted. - AxisOrientationTracker::IsMainAxisHorizontal() only has two callers, and both are inside its own class. So it's effectively become an implementation detail of its class, and it can be made private. (I'm not entirely removing it, because it does make its two callers more readable. The callers are working with a physical-axis-dependent type, 'LayoutDeviceIntSize', which comes from an API that isn't logical-axis-friendly, "GetMinimumWidgetSize", so they're not easily logicalized. So: it's nice to keep IsMainAxisHorizontal() around as an internal convenience method to tell us whether to extract the width or height inside of these two specific methods. But we don't want to introduce more callers, so let's leave it around & make it private.) MozReview-Commit-ID: 1iz1e52NmxV
d0c4313e6d22595665e4cc78e81c9829e1d9a960: Bug 1174003 part 10: [css-flexbox] Remove GET_MAIN_COMPONENT/GET_CROSS_COMPONENT macros (expanding each at its only remaining callsite). r=mats
Daniel Holbert <dholbert@cs.stanford.edu> - Wed, 28 Feb 2018 09:41:13 -0800 - rev 450894
Push 148 by fmarier@mozilla.com at Thu, 29 Mar 2018 23:06:47 +0000
Bug 1174003 part 10: [css-flexbox] Remove GET_MAIN_COMPONENT/GET_CROSS_COMPONENT macros (expanding each at its only remaining callsite). r=mats This patch doesn't affect behavior. Each of these macros only had one caller remaining, and this patch simply expands each of these macros at its sole callsite. Note that I'm using the "IsMainAxisHorizontal()" helper in *both* expansions here, which makes the alternative variant "IsCrossAxisHorizontal()" unused as of this patch. The next patch in this series will remove that now-unused method, which will reduce the "Horizontal"-querying API surface here. The documentation for the macros is still relevant to their still-existing "_LOGICAL" variants (and those variants do still have callers), so I'm updating the documentation to be about those variants. MozReview-Commit-ID: 5i32VYXzo3r
ec67f4f9bb892efc2186108f99775f88f5b0e213: Bug 1174003 part 9: [css-flexbox] Remove GET_MAIN_COMPONENT calls from CheckForMinSizeAuto(). r=mats
Daniel Holbert <dholbert@cs.stanford.edu> - Wed, 28 Feb 2018 09:40:48 -0800 - rev 450893
Push 148 by fmarier@mozilla.com at Thu, 29 Mar 2018 23:06:47 +0000
Bug 1174003 part 9: [css-flexbox] Remove GET_MAIN_COMPONENT calls from CheckForMinSizeAuto(). r=mats This patch doesn't change behavior. The GET_MAIN_COMPONENT macro (some of whose calls I'm removing here) makes a call to IsMainAxisHorizontal() under the hood. So I want to get rid of calls to this this macro, to get closer to killing that method. In this code, we're interested in the flex item's min-size property in the flex container's main axis. This patch makes us simply use MinISize/MinBSize (in terms of the *flex container's* writing mode) to get the appropriate min-size property. The call to IsRowOriented() (querying the flex container's "flex-direction" property) tells us whether the inline or block axis is the main axis. This patch also does away with an unnecessary axis-specific 'overflow-{x/y}' check, which we don't need to bother with, as noted in a new code-comment (due to how the 'overflow' subproperties influence each other). MozReview-Commit-ID: Kqyh69W5IQJ
dd08d793fa67b55cfcbadd63c9522079e94cae78: Bug 1174003 part 8: [css-flexbox] Change flex item intrinsic ratio calculations to use logical axes and a LogicalSize. r=mats
Daniel Holbert <dholbert@cs.stanford.edu> - Tue, 27 Feb 2018 16:32:58 -0800 - rev 450892
Push 148 by fmarier@mozilla.com at Thu, 29 Mar 2018 23:06:47 +0000
Bug 1174003 part 8: [css-flexbox] Change flex item intrinsic ratio calculations to use logical axes and a LogicalSize. r=mats This patch doesn't affect behavior. It does the following: - Changes the AxisOrientationTracker "GetMainComponent/GetCrossComponent" APIs to take a LogicalSize rather than a nsSize. - Changes FlexItem::mIntrinsicRatio to be a LogicalSize rather than a nsSize. - Simplifies the MainSizeFromAspectRatio() helper-function (in particular, it removes a call to IsCrossAxisHorizontal(), which is an API I'm gradually removing in this patch series.) MozReview-Commit-ID: KXUmaUVPMZa
af2524d9b0ab33a8ccdc53535ce4622017d3b764: Bug 1174003 part 7: [css-flexbox] Logicalize IsCrossAxisHorizontal() check in GetBaselineOffsetFromOuterCrossSize (and simplify a condition for baseline fallback). r=mats
Daniel Holbert <dholbert@cs.stanford.edu> - Tue, 27 Feb 2018 15:50:30 -0800 - rev 450891
Push 148 by fmarier@mozilla.com at Thu, 29 Mar 2018 23:06:47 +0000
Bug 1174003 part 7: [css-flexbox] Logicalize IsCrossAxisHorizontal() check in GetBaselineOffsetFromOuterCrossSize (and simplify a condition for baseline fallback). r=mats This patch doesn't change our behavior -- not in opt builds, at least. In debug builds, this patch does change an assertion condition, to remove a usage of IsCrossAxisHorizontal(). This means debug builds may proceed a bit further when loading e.g. bug 1384266's testcase (which up until now was tripping this assertion). Now that testcase fails a slighlty later assertion (which I'll sort out on that bug). The first hunk of this patch is just a simplification -- replacing a complicated condition (IsRowOriented==IsOrthogonalTo) with a simpler formulation of the same condition. I'm making that simplification in this patch so that we're more clearly consistent about what condition we depend on for baseline alignment. After this patch, that (simplified) condition matches the condition that we assert inside of GetBaselineOffsetFromOuterCrossEdge(). Note: I'm adding two XXXdholbert comments in this patch, for outstanding issues that I ran across which are out-of-scope for this patch series. MozReview-Commit-ID: 5x5xqWWilQZ
88d72b7833f55d731132e60ae6a4641452ceadcd: Bug 1174003 part 6: [css-flexbox] Replace ComputedCrossSize() helper with a new API that uses logical axes internally. r=mats
Daniel Holbert <dholbert@cs.stanford.edu> - Tue, 27 Feb 2018 15:46:55 -0800 - rev 450890
Push 148 by fmarier@mozilla.com at Thu, 29 Mar 2018 23:06:47 +0000
Bug 1174003 part 6: [css-flexbox] Replace ComputedCrossSize() helper with a new API that uses logical axes internally. r=mats This patch doesn't affect behavior. It removes a helper-function that simply returned nsStylePosition::mWidth or mHeight -- whichever was in the flex container's cross axis. This helper was only used to answer the question "is the cross size 'auto'", at a single callsite. So, this patch replaces the helper with a new helper that more directly answers that question. The new helper's implementation uses logical axes for its reasoning, too, whereas the removed one used physical axes (and in particular, it relied on AxisOrientationTracker::IsCrossAxisHorizontal(), which I'll be getting rid of later in this patch series). MozReview-Commit-ID: EJ8MObTauZH
0653058864dfaf8379c00e69d7648e62032dac20: Bug 1174003 part 5: [css-flexbox] Remove is-{main,cross}-axis-horizontal checks from ReflowFlexItem. r=mats
Daniel Holbert <dholbert@cs.stanford.edu> - Tue, 27 Feb 2018 15:40:18 -0800 - rev 450889
Push 148 by fmarier@mozilla.com at Thu, 29 Mar 2018 23:06:47 +0000
Bug 1174003 part 5: [css-flexbox] Remove is-{main,cross}-axis-horizontal checks from ReflowFlexItem. r=mats This patch mostly[1] doesn't affect behavior. It just changes some ReflowInput width/height-setting logic to use ISize/BSize setters instead of width/height setters. To help with this, I'm also adding some more getters to answer the question "is this flex item's {inline,block} axis the same as the flex container's {main,cross} axis", for convenience/readability at callsites. (All of these getters are simply giving a different view of the same underlying single bit of information.) [1] One way this patch *kind of* affects behavior: it generalizes the conditions under which we set the NS_FRAME_CONTAINS_RELATIVE_BSIZE flag on a flex item. But that doesn't actually have any user-visible effects right now, because that flag's only purpose is to determine whether we should reflow, and currently we always reflow all flex items. If/when that changes, though (i.e. when we start reflowing flex items more selectively), this patch is adding a reftest that may test this generalized behavior. (The reftest actually trivially passes right now, due to unrelated bug 1441348.) MozReview-Commit-ID: 4NEKLBAjowh
201aadc96164accd39ee4ffcb6e5108ad17eccbc: Bug 1174003 part 4: [css-flexbox] Remove IsMainAxisHorizontal() check from DoFlexLayout(). r=mats
Daniel Holbert <dholbert@cs.stanford.edu> - Tue, 27 Feb 2018 15:40:18 -0800 - rev 450888
Push 148 by fmarier@mozilla.com at Thu, 29 Mar 2018 23:06:47 +0000
Bug 1174003 part 4: [css-flexbox] Remove IsMainAxisHorizontal() check from DoFlexLayout(). r=mats This patch doesn't affect behavior. It just replaces some (correct) physical-axis-dependent code with equivalent logical-axis-dependent code. MozReview-Commit-ID: 27QJU2cFWh
934b53dafa35502ca511f2cc59efed30323a9dba: Bug 1174003 part 3: [css-flexbox] Make GetMarginSizeInMainAxis() take a LogicalMargin, instead of nsMargin. r=mats
Daniel Holbert <dholbert@cs.stanford.edu> - Tue, 27 Feb 2018 15:40:10 -0800 - rev 450887
Push 148 by fmarier@mozilla.com at Thu, 29 Mar 2018 23:06:47 +0000
Bug 1174003 part 3: [css-flexbox] Make GetMarginSizeInMainAxis() take a LogicalMargin, instead of nsMargin. r=mats This patch doesn't change behavior. It just makes us use logical axes/types instead of physical ones for this particular API and its caller. MozReview-Commit-ID: Jt6SECGI9EU
0d797523af037f15a866a7d4fb8571fa362d6a3c: Bug 1174003 part 2: [css-flexbox] Reformat code around GetMinimumWidgetSize call slightly. r=mats
Daniel Holbert <dholbert@cs.stanford.edu> - Tue, 27 Feb 2018 11:26:43 -0800 - rev 450886
Push 148 by fmarier@mozilla.com at Thu, 29 Mar 2018 23:06:47 +0000
Bug 1174003 part 2: [css-flexbox] Reformat code around GetMinimumWidgetSize call slightly. r=mats This patch doesn't change behavior. It's purely to allow the next patch to be more surgical. Specifically, this patch: - splits a subtract-and-clamp operation into two separate operations. - splits one a comment into two. ...so that the next patch can swap out these variables for new ones, without pushing these lines over 80 characters. MozReview-Commit-ID: 4N5sI755CqF
cacbcc051b29afff404638157e99201cf71c68b9: Bug 1174003 part 1: [css-flexbox] Remove unused method nsFlexContainerFrame::IsHorizontal. r=mats
Daniel Holbert <dholbert@cs.stanford.edu> - Tue, 27 Feb 2018 11:21:22 -0800 - rev 450885
Push 148 by fmarier@mozilla.com at Thu, 29 Mar 2018 23:06:47 +0000
Bug 1174003 part 1: [css-flexbox] Remove unused method nsFlexContainerFrame::IsHorizontal. r=mats MozReview-Commit-ID: JzvGzJvMhLS
10bd2edbcc9f852448821e2e3fd3f05bc02cc7ec: bug 1435753 - Resume collection of extended data from Release Candidate builds on beta, too r=froydnj,gfritzsche
Chris H-C <chutten@mozilla.com> - Tue, 27 Feb 2018 14:12:43 -0500 - rev 450884
Push 148 by fmarier@mozilla.com at Thu, 29 Mar 2018 23:06:47 +0000
bug 1435753 - Resume collection of extended data from Release Candidate builds on beta, too r=froydnj,gfritzsche Before Firefox 58 we collected extended collection from users on nightly, aurora, and beta. Then we had to change things (see bug 1406391). In doing so, we accidentally stopped receiving data from "release candidate" beta builds. This patch resumes that collection by detecting an RC build as having a MOZ_UPDATE_CHANNEL of "release", but an app.update.channel of "beta" MozReview-Commit-ID: 3EzzDtQj8Kw
e41dd572e115030f4d00fead7bb25911f0b86dbe: Bug 1429904 - Remove ProfileBuffer::Reset(). r=njn
Markus Stange <mstange@themasta.com> - Thu, 15 Feb 2018 21:49:05 -0500 - rev 450883
Push 148 by fmarier@mozilla.com at Thu, 29 Mar 2018 23:06:47 +0000
Bug 1429904 - Remove ProfileBuffer::Reset(). r=njn MozReview-Commit-ID: AzIyYByoesS
8cbd19b941a0da825948274e2720fa01f6e27e10: Bug 1429904 - Remove unused arguments and return values. r=njn
Markus Stange <mstange@themasta.com> - Sat, 17 Feb 2018 19:21:05 -0500 - rev 450882
Push 148 by fmarier@mozilla.com at Thu, 29 Mar 2018 23:06:47 +0000
Bug 1429904 - Remove unused arguments and return values. r=njn MozReview-Commit-ID: 9P0TKavkwgA
544e3884d895cf1be55c55e40e8a0c2be56f7aa6: Bug 1429904 - When a JSContext for a thread is about to go away, collect enough information about any JIT entries in the buffer so that the entire buffer can be streamed to JSON. r=njn
Markus Stange <mstange@themasta.com> - Wed, 28 Feb 2018 00:17:16 -0500 - rev 450881
Push 148 by fmarier@mozilla.com at Thu, 29 Mar 2018 23:06:47 +0000
Bug 1429904 - When a JSContext for a thread is about to go away, collect enough information about any JIT entries in the buffer so that the entire buffer can be streamed to JSON. r=njn This changeset changes behavior. If the profile is streamed before any JSContext has gone away, we now iterate over the entire buffer twice (per thread): First, to collect information about JIT frames, and then again when we build the JSON for the samples. The first traversal stores small pieces of JSON for JIT fromes in individual strings, and the second iteration splices those strings into the thread JSON's frame table. When the JSContext for a thread goes away, we no longer build JSON for samples, and we don't reset the profiler buffer. We now only build the JSON for JIT frames. Once the complete profile is requested and we build samples for it, we iterate over the entire buffer, and look up the cached JIT frame information for JitReturnAddr entries from the correct range. Different parts of the buffer may correspond to the life time of different JSContexts: For each JSContext we will have one range in the JITFrameInfo, and we can look up the correct range based on the buffer position of the JitReturnAddr entry that we're processing. This new way of doing things has multiple advantages: - We no longer reset the buffer, so we no longer lose information about other threads. - All threads from a given process now always have sample data for the same time range. Before this change, the "partial profile" from a thread that lost its JSContext could extend further into the past than the other threads' profiles. - Requesting profiles multiple times now has more consistent results. Before this change, the first requested profile would include the partial profile, but then the partial profile was discarded. And the second requested profile would not contain any data for the time before the JSContext went away. - We now do less work when a thread's JSContext goes away. This should decrease the interruption time. MozReview-Commit-ID: 3KhnPtBijna
34f12869088652fd5005d790a57ac9c9d6418c3d: Bug 1429904 - Add JITFrameInfo. r=njn
Markus Stange <mstange@themasta.com> - Wed, 28 Feb 2018 00:13:51 -0500 - rev 450880
Push 148 by fmarier@mozilla.com at Thu, 29 Mar 2018 23:06:47 +0000
Bug 1429904 - Add JITFrameInfo. r=njn MozReview-Commit-ID: DashxIKyzYZ
(0) -300000 -100000 -30000 -10000 -3000 -1000 -300 -100 -50 -20 +20 +50 +100 +300 +1000 +3000 +10000 +30000 tip