ac55a8f97f06897ee34d65d6bbfc773091e2341e: Bug 1495067 - Enable a test. r=me
Emilio Cobos Álvarez <emilio@crisal.io> - Tue, 02 Oct 2018 18:00:48 +0200 - rev 439193
Push 34758 by dvarga@mozilla.com at Tue, 02 Oct 2018 21:45:21 +0000
Bug 1495067 - Enable a test. r=me
9e5ba5a3b22c2d6ce5cc6bd0c331af5bdec7c6a5: Bug 1494135 add pinned option to page_action manifest, r=aswan
Shane Caraveo <scaraveo@mozilla.com> - Tue, 02 Oct 2018 15:39:16 +0000 - rev 439192
Push 34758 by dvarga@mozilla.com at Tue, 02 Oct 2018 21:45:21 +0000
Bug 1494135 add pinned option to page_action manifest, r=aswan Differential Revision: https://phabricator.services.mozilla.com/D7098
66b90e5af6d162fa2c5d27b5d0df4140f108d84b: Bug 1495517 - Migrate improvesearch.topSiteSearchShortcuts pref from ActivityStream.jsm to firefox.js r=k88hudson
Ursula Sarracini <ursulasarracini@gmail.com> - Tue, 02 Oct 2018 15:37:51 +0000 - rev 439191
Push 34758 by dvarga@mozilla.com at Tue, 02 Oct 2018 21:45:21 +0000
Bug 1495517 - Migrate improvesearch.topSiteSearchShortcuts pref from ActivityStream.jsm to firefox.js r=k88hudson Differential Revision: https://phabricator.services.mozilla.com/D7325
8a9bb797623dae8f4f4d478b7adf6e1dde504de7: Bug 1490375 - Align about:addons with about:preferences sidebar r=aswan
Mark Striemer <mstriemer@mozilla.com> - Mon, 01 Oct 2018 17:15:23 +0000 - rev 439190
Push 34758 by dvarga@mozilla.com at Tue, 02 Oct 2018 21:45:21 +0000
Bug 1490375 - Align about:addons with about:preferences sidebar r=aswan Differential Revision: https://phabricator.services.mozilla.com/D7264
7a728776d81231f97d7e126cdff83c6935bbc158: Backed out changeset 1f4d7ab6cd6d (bug 1480529) for perma failing on browser_multiselect_tabs_bookmark.js
Bogdan Tara <btara@mozilla.com> - Tue, 02 Oct 2018 18:33:49 +0300 - rev 439189
Push 34758 by dvarga@mozilla.com at Tue, 02 Oct 2018 21:45:21 +0000
Backed out changeset 1f4d7ab6cd6d (bug 1480529) for perma failing on browser_multiselect_tabs_bookmark.js
ec51b039eef15fd55908f1fa1051b0624c4b4a46: Bug 1380830 - Enable container-with-clamping reftest again. r=dbaron
Jan Henning <jh+bugzilla@buttercookie.de> - Tue, 02 Oct 2018 15:23:19 +0000 - rev 439188
Push 34758 by dvarga@mozilla.com at Tue, 02 Oct 2018 21:45:21 +0000
Bug 1380830 - Enable container-with-clamping reftest again. r=dbaron Judging from the description in comment 3 and the fact that this test started failing shortly after bug 1308876 landed, it is highly likely that this test is being hit by the same issue as bug 1428670. This also makes sense given that this test is supposed to test the clamping of the effective container width for font inflation by the actually visible area of that frame - be that the viewport for a top level document as in bug 1428670, or the width of an <iframe> as in this test. Without the patches for bug 1428670, this test is still failing very frequently. With those patches applied on the other hand, no more failures are encountered. Differential Revision: https://phabricator.services.mozilla.com/D5580
57e3c8d09acea5e0bff83ddbb78d385f71dd352d: Bug 1428670 - Part 3: Store the effective container ISize within the FontInflationData. r=dbaron
Jan Henning <jh+bugzilla@buttercookie.de> - Tue, 02 Oct 2018 15:23:17 +0000 - rev 439187
Push 34758 by dvarga@mozilla.com at Tue, 02 Oct 2018 21:45:21 +0000
Bug 1428670 - Part 3: Store the effective container ISize within the FontInflationData. r=dbaron When one of the two factors governing the effective container width for font inflation changes, we need to mark all affected frames as dirty. While the visible area commonly changes because of viewport changes and we can catch those through the check for ISize resizes of the top-level frame ("!mFrame->GetParent() && isIResize"), it still seems nicer to move calculation of the effective container width into the FontInflationData itself, especially since the effective container width calculation in nsLayoutUtils is the only consumer of the NCAISize currently stored by the FontInflationData. That way - we can be sure that really all changes of the visible width will correctly mark all affected frames as dirty - can avoid repeatedly recalculating the effective container width - can also detect the cases where the effective container width actually remains the same after a change in one of its input factors and skip forcing a full dirty reflow for all descendants just because of font inflation. While the code in nsLayoutUtils was technically always using the writing mode (horizontal/vertical) of each individual frame for determining which dimension of the visible size should be used for clamping, just using the writing mode of the respective flow root should be enough, since each change in the writing mode should create a new flow root. This assumption should already hold today because 1. as per the Writing Modes CSS spec, a change in writing mode compared to its parent means that the affected block cannot be purely "inline", but at most "inline-block". 2. Generally, any non-inline frame will be marked as a font inflation container. 3. Any block frame whose writing direction doesn't match its parent will be a block formatting context, which implies NS_BLOCK_FLOAT_MGR. 4. Any block frame that has both NS_BLOCK_FLOAT_MGR set and is a font inflation container will also become a font inflation flow root. but because this chain of reasoning is not the most direct, we also add a corresponding assertion to better catch any potential bugs here. Differential Revision: https://phabricator.services.mozilla.com/D5578
87971e291470b0d0ed5be19f323312ae39ac5308: Bug 1428670 - Part 2: Correctly mark all child frames as dirty when font inflation status changes. r=dbaron
Jan Henning <jh+bugzilla@buttercookie.de> - Tue, 02 Oct 2018 15:23:12 +0000 - rev 439186
Push 34758 by dvarga@mozilla.com at Tue, 02 Oct 2018 21:45:21 +0000
Bug 1428670 - Part 2: Correctly mark all child frames as dirty when font inflation status changes. r=dbaron Before bug 1308876, child frames marked themselves as dirty during reflow if their parent was dirty, too. After bug 1308876, the point where dirtiness is being propagated to a frame's descendants has been shifted: Now, dirty parents are responsible for marking all their children as dirty, too, when the parent starts reflowing. This means that if a frame wants to mark a whole subtree as dirty *during its own* reflow, it's no longer sufficient to just mark the root of the subtree as dirty and then rely on all further children marking themselves as dirty as well when reflow reaches them. The font inflation code is one such case. When the font inflation data on a font inflation flow root has become dirty, or we're resizing the top-level frame (which because of the effective container width clamping from bug 707855 can affect the font inflation font size as well), we now need to explicitly mark all affected children as dirty. Differential Revision: https://phabricator.services.mozilla.com/D5577
205758034a6c41e5e2b33885583fd4da27b27963: Bug 1428670 - Part 1: Add reftest. r=dbaron
Jan Henning <jh+bugzilla@buttercookie.de> - Tue, 02 Oct 2018 15:23:10 +0000 - rev 439185
Push 34758 by dvarga@mozilla.com at Tue, 02 Oct 2018 21:45:21 +0000
Bug 1428670 - Part 1: Add reftest. r=dbaron The failure mode this test is testing is the following: Apart from the relevant preferences (which cannot change without reloading the page, so they're not relevant in this case), the magnitude of font size inflation for all content governed by a particular font inflation flow root depends on the flow root's effective container width, which is calculated by taking the smaller of the following two values: - The font inflation flow root's calculated NCAIsize. - The ISize of the PresContext's currently visible area. Minimum font size for font inflation then scales linearly with the effective container width. While for a plain document without frames, the visible area normally corresponds to the viewport size, the MobileViewportManager will only calculate the viewport after the "load" event or the first paint, whichever is sooner. This means that the initial reflow will proceed using the current window dimensions (on mobile this is corresponding to the display size) for the currently visible area, which in portrait mode typically means around 300 - 500 px width. After the MVM has done its viewport calculations, we'll reflow again using the new viewport size as our visible area. For non-mobile friendly pages where font inflation is relevant, the standard viewport width is 980 px. If a font inflation flow root is wider than the initial window size, this means that its effective container width is governed by the visible area and will therefore increase during the second reflow, as will correspondingly font inflation's minimum font size. While the font inflation code detects changes in a font inflation flow root's NCAISize, respectively ISize resizes of the top-level (Viewport)Frame, after bug 1308876 it no longer correctly marks all descendants of the affected flow root as dirty. If the text is contained inside an element with a fixed width, which has therefore been unaffected by the viewport width change, this means that we'll skip reflow for that text entirely, so the text gets rendered at the new, increased font size, but continues using the old layout laid out assuming the smaller initial font size. I didn't manage to force the visible area to be larger than the initial window size of 800 px using meta viewport tags, so I'm adjusting browser.viewport. desktopWidth for this test instead. This also more closely mimics the real-life failure case described above, where the viewport width gets set to a value larger than the initial window size through the special desktop page viewport width handling. Differential Revision: https://phabricator.services.mozilla.com/D5579
e2eb3d8b408f29e681eeb58de255f3ae33e7c307: Bug 1428670 - Part 0: Fix mixed tabs and spaces. r=dbaron
Jan Henning <jh+bugzilla@buttercookie.de> - Tue, 02 Oct 2018 15:23:07 +0000 - rev 439184
Push 34758 by dvarga@mozilla.com at Tue, 02 Oct 2018 21:45:21 +0000
Bug 1428670 - Part 0: Fix mixed tabs and spaces. r=dbaron Differential Revision: https://phabricator.services.mozilla.com/D5576
b5361432fe51632e058269dadb7ccdc200a04878: Bug 1492878: update list of locations with vendored `robustcheckout` r=Callek
Connor Sheehan <sheehan@mozilla.com> - Tue, 02 Oct 2018 14:35:08 +0000 - rev 439183
Push 34758 by dvarga@mozilla.com at Tue, 02 Oct 2018 21:45:21 +0000
Bug 1492878: update list of locations with vendored `robustcheckout` r=Callek There are a few external repos that hold copies of robustcheckout in various places, mainly on release engineering infrastructure that has been moved to GitHub. We should document those locations in the same place we document the upgrade steps for Mercurial in CI. Differential Revision: https://phabricator.services.mozilla.com/D6989
1f4d7ab6cd6daceaa33c294c7c078ac0ccb7f708: Bug 1480529 - Changed 'Bookmark All Tabs' to 'Bookmark Tab' for single tab selections. r=Felipe
Jared Wein <jwein@mozilla.com> - Tue, 02 Oct 2018 03:19:01 +0000 - rev 439182
Push 34758 by dvarga@mozilla.com at Tue, 02 Oct 2018 21:45:21 +0000
Bug 1480529 - Changed 'Bookmark All Tabs' to 'Bookmark Tab' for single tab selections. r=Felipe I changed the toolbar context menuitem from 'Bookmark All Tabs' to 'Bookmark Selected Tabs' because it is separated from a specific tab and thus it is not clear which tab would get bookmarked if only one is selected. This seemed much clearer to me in my testing. The wording of 'Bookmark Selected Tabs' is already used elsewhere where we have 'Reload Selected Tabs', 'Close Selected Tabs', etc. Differential Revision: https://phabricator.services.mozilla.com/D7217
0b4d8a1ecc764f1bd863641ef5c3548919345963: Bug 1495593 - Use './mach' instead of 'mach' in tup docs; r=chmanchester
Mike Shal <mshal@mozilla.com> - Mon, 01 Oct 2018 22:55:44 +0000 - rev 439181
Push 34758 by dvarga@mozilla.com at Tue, 02 Oct 2018 21:45:21 +0000
Bug 1495593 - Use './mach' instead of 'mach' in tup docs; r=chmanchester MozReview-Commit-ID: AXsQFqdIjqF Differential Revision: https://phabricator.services.mozilla.com/D7351
badcfa4ff756cf9b074d31d2d7c7003396337dcb: Bug 1474938 - Enable the multiselect tabs feature by default for release and beta builds. r=Gijs
Jared Wein <jwein@mozilla.com> - Wed, 26 Sep 2018 21:13:39 +0000 - rev 439180
Push 34758 by dvarga@mozilla.com at Tue, 02 Oct 2018 21:45:21 +0000
Bug 1474938 - Enable the multiselect tabs feature by default for release and beta builds. r=Gijs Differential Revision: https://phabricator.services.mozilla.com/D6993
e9fda19be060c1200bd2948322532e7648bed6b1: Bug 1495067 - Make HasRTLChars() consider Hebrew presentation forms as RTL (again) and not consider U+FEFF as RTL (again). r=jfkthame
Henri Sivonen <hsivonen@hsivonen.fi> - Tue, 02 Oct 2018 14:24:15 +0000 - rev 439179
Push 34758 by dvarga@mozilla.com at Tue, 02 Oct 2018 21:45:21 +0000
Bug 1495067 - Make HasRTLChars() consider Hebrew presentation forms as RTL (again) and not consider U+FEFF as RTL (again). r=jfkthame * Update encoding_rs to 0.8.8. * Change U+FEFD and U+FEFE to RTL in IS_RTL_PRESENTATION_FORM to make the Rust and C++ code agree on what's RTL. MozReview-Commit-ID: CuK6fN4pojG Differential Revision: https://phabricator.services.mozilla.com/D7285
b79da889f39bb028073d6b2b0bf042a05cb42c52: Bug 1491268 - Bookmarks policy's last field is displayed in same color like all other rows r=Felipe
Arshad Kazmi <arshadkazmi42@gmail.com> - Tue, 02 Oct 2018 14:17:29 +0000 - rev 439178
Push 34758 by dvarga@mozilla.com at Tue, 02 Oct 2018 21:45:21 +0000
Bug 1491268 - Bookmarks policy's last field is displayed in same color like all other rows r=Felipe Differential Revision: https://phabricator.services.mozilla.com/D7238
b9a19eb6f805500a3f9a80b44f2337f8d7d777e7: Bug 1370636 - [wdspec] Enable Wd jobs on Windows platforms. r=jgraham
Henrik Skupin <mail@hskupin.info> - Tue, 02 Oct 2018 13:34:02 +0000 - rev 439177
Push 34758 by dvarga@mozilla.com at Tue, 02 Oct 2018 21:45:21 +0000
Bug 1370636 - [wdspec] Enable Wd jobs on Windows platforms. r=jgraham Depends on D7418 Differential Revision: https://phabricator.services.mozilla.com/D7419
9e11b103f7ec94a03c55f0fc7ddd4eeaafde284e: Bug 1370636 - [wdspec] Temporarily disable failing tests on Windows. r=jgraham
Henrik Skupin <mail@hskupin.info> - Tue, 02 Oct 2018 13:36:25 +0000 - rev 439176
Push 34758 by dvarga@mozilla.com at Tue, 02 Oct 2018 21:45:21 +0000
Bug 1370636 - [wdspec] Temporarily disable failing tests on Windows. r=jgraham Depends on D7417 Differential Revision: https://phabricator.services.mozilla.com/D7418
ec024b2fc13a772ae7a19ebc73a36bb1deca2d5d: Bug 1370636 - [wdspec] Update mozharness configuration for geckodriver on Windows. r=jgraham
Henrik Skupin <mail@hskupin.info> - Tue, 02 Oct 2018 13:36:01 +0000 - rev 439175
Push 34758 by dvarga@mozilla.com at Tue, 02 Oct 2018 21:45:21 +0000
Bug 1370636 - [wdspec] Update mozharness configuration for geckodriver on Windows. r=jgraham The patch makes sure that the correct path to the geckodriver binary is used for the web-platform-tests script. Differential Revision: https://phabricator.services.mozilla.com/D7417
f251a29c5846f02cbf55d630db8dc724b58882fa: Bug 1470266 - [mozharness] Add --setpref argument to main desktop scripts, r=jmaher
Andrew Halberstadt <ahalberstadt@mozilla.com> - Tue, 02 Oct 2018 13:11:40 +0000 - rev 439174
Push 34758 by dvarga@mozilla.com at Tue, 02 Oct 2018 21:45:21 +0000
Bug 1470266 - [mozharness] Add --setpref argument to main desktop scripts, r=jmaher The mozharness scripts have a lot of special case arguments for one off configurations, stuff like --e10s, --enable-webrender and --gpu-required. Many of these command line args ultimately only end up setting an extra pref in the test harnesses. Instead, let's just give mozharness the ability to set prefs directly via --setpref. This way we can pass them through from taskgraph without needing to add extra configuration to mozharness when making changes like this. Differential Revision: https://phabricator.services.mozilla.com/D7191
(0) -300000 -100000 -30000 -10000 -3000 -1000 -300 -100 -50 -20 +20 +50 +100 +300 +1000 +3000 +10000 +30000 tip