be2ebc0867b8cb434ffcc06fc619c0b4e9e0b3c6: Bug1278759 - Add tests to make sure accessibility tree is not affected by CSS flexbox markup, r=surkov draft
Marco Zehe <mzehe@mozilla.com> - Wed, 08 Jun 2016 14:08:39 +0200 - rev 376628
Push 20632 by mzehe@mozilla.com at Wed, 08 Jun 2016 12:14:42 +0000
Bug1278759 - Add tests to make sure accessibility tree is not affected by CSS flexbox markup, r=surkov MozReview-Commit-ID: F7vq0Yfy9nU
5a3a4985049a86dd170cda8d5c186caadf0d72a8: Bug 1278456 - Remove stdc++-compat hacks for libstdc++ < 4.6.1. r?froydnj draft
Mike Hommey <mh+mozilla@glandium.org> - Tue, 07 Jun 2016 13:52:04 +0900 - rev 376627
Push 20631 by bmo:mh+mozilla@glandium.org at Wed, 08 Jun 2016 12:10:51 +0000
Bug 1278456 - Remove stdc++-compat hacks for libstdc++ < 4.6.1. r?froydnj
5e8bd9b567f01a534dd7947d07c25e859b92b981: Bug 1278456 - Add the tooltool GCC library directory to LD_LIBRARY_PATH on Linux builds. r?mshal draft
Mike Hommey <mh+mozilla@glandium.org> - Tue, 07 Jun 2016 13:50:36 +0900 - rev 376626
Push 20631 by bmo:mh+mozilla@glandium.org at Wed, 08 Jun 2016 12:10:51 +0000
Bug 1278456 - Add the tooltool GCC library directory to LD_LIBRARY_PATH on Linux builds. r?mshal Build slaves on automation are based on Centos 6, which doesn't have a recent enough version of libstdc++ for our new requirements. But since we're building with a recent GCC or clang with its own libstdc++, we do have such a libstdc++ available somewhere, and the compiler picks it when invoking the linker. Problems start happening when we execute some of the built programs during the build, like host tools (e.g. nsinstall), or target programs (xpcshell, during packaging). In that case, we need the compiler's libstdc++ to be used. Which required adding the GCC or clang library directory to LD_LIBRARY_PATH. Unconveniently enough, the clang 3.5 tooltool package we're using for ASAN builds until we can update to at least 3.8 (bug 1278718) doesn't contain libstdc++.so. So for those builds, pull the GCC package from tooltool as well, and pick libstdc++ from there.
ea60204f2399a0217a173092170d42ff34f7ae8d: Bug 1278456 - Bump libstdc++ requirement to 3.4.16 (4.6.1). r?froydnj draft
Mike Hommey <mh+mozilla@glandium.org> - Tue, 07 Jun 2016 13:51:05 +0900 - rev 376625
Push 20631 by bmo:mh+mozilla@glandium.org at Wed, 08 Jun 2016 12:10:51 +0000
Bug 1278456 - Bump libstdc++ requirement to 3.4.16 (4.6.1). r?froydnj Similarly to the considerations about glibc, the Linux compatibility matrix (https://developer.mozilla.org/en-US/Firefox/Linux_compatibility_matrix) tells us no distro with Gtk+3 3.4 has a version of libstdc++ older than 4.6. The data in the matrix doesn't go to that level of detail, but Ubuntu 12.04 LTS, being the only one with version 4.6 (others have at least 4.7), it's worth noting it has version 4.6.3. Which means we can safely require libstdc++ symbols version 3.4.16 (which were added in 4.6.1). This will allow us to remove a lot of the stdc++ compatibility hacks.
373d6f827e6ecb7772418ea997989a05cfdbb6d7: Bug 1278456 - Bump glibc requirement to 2.12. r?froydnj draft
Mike Hommey <mh+mozilla@glandium.org> - Tue, 07 Jun 2016 13:49:47 +0900 - rev 376624
Push 20631 by bmo:mh+mozilla@glandium.org at Wed, 08 Jun 2016 12:10:51 +0000
Bug 1278456 - Bump glibc requirement to 2.12. r?froydnj The requirement for glibc has been set to version 2.7 for a long while. Spidermonkey uses the pthread_setname_np symbol, which is only available since glibc 2.12. So far, we've been fortunate that the symbol doesn't end up in libxul, or tests that link to js directly, because the symbol is eliminated as being called by effectively dead code. There are multiple reasons why this is going to change, one of which being changes to the way things are linked, that will make the linker not eliminate that code in some cases. Another is that eventually, the separation of build systems between js and top-level is going to fade, and the glibc checks, which apply to all gecko binaries, will also apply to js binaries. They currently are not happening, and would fail because of pthread_setname_np if they were. Taking a step back, as of version 46, the mozilla.org builds require at least Gtk+3 3.4. Which means the requirements for the underlying system have received a dramatic bump, and it's time to revisit the requirements for binary compatibility. I went through all my notes from all the recent times binary compatibility has been considered, and put together a compatibility matrix on MDN from that data as well as more recent data that I could find here and there, about the major non-rolling-release distros (RHEL, Fedora, SuSE, Debian, Ubuntu) https://developer.mozilla.org/en-US/Firefox/Linux_compatibility_matrix Considering the data there, none of the distros that have at least Gtk+3 3.4 have a glibc older than 2.13. The list of symbols that 2.13 provides that 2.12 doesn't have is not large enough, though, to really care about depending on 2.13.
26334504e7865e51915d2ec867d5d364b4f00ea7: Bug 1266450 - part7: fix html tooltip autofocus behavior;r=bgrins draft
Julian Descottes <jdescottes@mozilla.com> - Wed, 08 Jun 2016 13:32:15 +0200 - rev 376623
Push 20630 by jdescottes@mozilla.com at Wed, 08 Jun 2016 11:49:53 +0000
Bug 1266450 - part7: fix html tooltip autofocus behavior;r=bgrins For autofocus tooltips, we need to find a focusable item in order to call focus() now that the tooltip content lives in the same document as the toolbox. Updated the corresponding test and made some superficial changes to HTMLTooltip.js. MozReview-Commit-ID: L61eIxgFm3d
fcee58928b2f281acc5da3e94cff8f02a1cf83bf: Bug 1266450 - part6: migrate EventDetails tooltip;r=bgrins draft
Julian Descottes <jdescottes@mozilla.com> - Tue, 31 May 2016 11:25:43 +0200 - rev 376622
Push 20630 by jdescottes@mozilla.com at Wed, 08 Jun 2016 11:49:53 +0000
Bug 1266450 - part6: migrate EventDetails tooltip;r=bgrins For now this is a 1 to 1 migration of the existing Tooltip helper method from XUL to HTML. MozReview-Commit-ID: 9YiJLgibV9h
74de63608de290a5f947bdd1959f605457a60510: Bug 1266450 - part5: move event details tooltip css to tooltips.css;r=bgrins draft
Julian Descottes <jdescottes@mozilla.com> - Fri, 03 Jun 2016 15:07:23 +0200 - rev 376621
Push 20630 by jdescottes@mozilla.com at Wed, 08 Jun 2016 11:49:53 +0000
Bug 1266450 - part5: move event details tooltip css to tooltips.css;r=bgrins MozReview-Commit-ID: 9b1C1g0e6K5
7d36b3b733b965a1875fc3e7670e587fc038095f: Bug 1266450 - part4: allow tooltips to have a variable height;r=bgrins draft
Julian Descottes <jdescottes@mozilla.com> - Fri, 03 Jun 2016 12:52:59 +0200 - rev 376620
Push 20630 by jdescottes@mozilla.com at Wed, 08 Jun 2016 11:49:53 +0000
Bug 1266450 - part4: allow tooltips to have a variable height;r=bgrins With this changeset the tooltip's effective height can be smaller than the height specified when calling setContent. If the tooltip content is dynamic, this allows to display a small tooltip frame if the content is collapsed, and a bigger tooltip frame when it is expanded. MozReview-Commit-ID: 44vA0Rdz62m
32c9f5c6462180168a0ffeb26f047ed516ba6932: Bug 1266450 - part3: fix helper to check if click occurred in tooltip;r=bgrins draft
Julian Descottes <jdescottes@mozilla.com> - Fri, 03 Jun 2016 12:50:39 +0200 - rev 376619
Push 20630 by jdescottes@mozilla.com at Wed, 08 Jun 2016 11:49:53 +0000
Bug 1266450 - part3: fix helper to check if click occurred in tooltip;r=bgrins The existing helper checking if a click occurred inside or outside a HTMLTooltip container was failing if the click occurred in an iframe. MozReview-Commit-ID: 9AIACOukYUF
4470f401840d3aea01eb7c120c989e3553d24f99: Bug 1266450 - part2: remove iframe container for HTML tooltip;r=bgrins draft
Julian Descottes <jdescottes@mozilla.com> - Mon, 30 May 2016 23:02:58 +0200 - rev 376618
Push 20630 by jdescottes@mozilla.com at Wed, 08 Jun 2016 11:49:53 +0000
Bug 1266450 - part2: remove iframe container for HTML tooltip;r=bgrins In order to have tooltips with a variable height, the tooltip container should be allowed to resize itself on the fly, which cannot be achieved with an iframe. This changeset makes the HTMLTooltip rely on a HTML container inserted in the XUL document directly. This allows to go back to a synchronous API which also simplifies the implementation. MozReview-Commit-ID: EDcsnVSKmeU
f57c6988c9091165de91367260cf314f954362cc: Bug 1266450 - part1: move devtools tooltip styles to dedicated file;r=bgrins draft
Julian Descottes <jdescottes@mozilla.com> - Fri, 03 Jun 2016 14:36:56 +0200 - rev 376617
Push 20630 by jdescottes@mozilla.com at Wed, 08 Jun 2016 11:49:53 +0000
Bug 1266450 - part1: move devtools tooltip styles to dedicated file;r=bgrins Tooltip styles are scattered between common.css and panel-specific CSS files (e.g. inspector.css). For the HTML tooltip, the panel specific CSS files will not be applied since the tooltip container is appended to the devtools top window. This changeset creates a new tooltips.css file which is loaded by default with devtools themes. MozReview-Commit-ID: BnoRi9gLfD5
0aab68e30c0e1354f88ead24a1a75e5eab95bfa9: Bug 1276468 - Fix `sheetToUrl` function for inline style. r=jwalker
Nicolas Chevobbe <chevobbe.nicolas@gmail.com> - Mon, 06 Jun 2016 21:48:54 +0200 - rev 376616
Push 20629 by chevobbe.nicolas@gmail.com at Wed, 08 Jun 2016 11:44:20 +0000
Bug 1276468 - Fix `sheetToUrl` function for inline style. r=jwalker The function was trying to access `stylesheet` parameter's ownerNode property, which is undefined when the parameter is a StyleSheetActor. In the latter case, we use nodeHref and styleSheetIndex properties to match what is done when the parameter is a StyleSheet. MozReview-Commit-ID: 7FNoKasFYLL
f87d1fde25f3a222d3c8ae9087ddd3141348e354: Bug 1251362 - Part 19 - Remove code and resources for the old Recent Tabs panel. r=liuche
Jan Henning <jh+bugzilla@buttercookie.de> - Thu, 26 May 2016 17:40:19 +0200 - rev 376615
Push 20629 by chevobbe.nicolas@gmail.com at Wed, 08 Jun 2016 11:44:20 +0000
Bug 1251362 - Part 19 - Remove code and resources for the old Recent Tabs panel. r=liuche MozReview-Commit-ID: FQJ7j8YlV6E
4509c776bcaaf9b6aa4ec15602e26a201fc1539c: Bug 1251362 - Part 18 - Migrate (customised) home panel configurations. r=liuche
Jan Henning <jh+bugzilla@buttercookie.de> - Sat, 21 May 2016 14:39:15 +0200 - rev 376614
Push 20629 by chevobbe.nicolas@gmail.com at Wed, 08 Jun 2016 11:44:20 +0000
Bug 1251362 - Part 18 - Migrate (customised) home panel configurations. r=liuche For people with customised home panels, we need to explicitly remove the Recent Tabs panel. We also unhide the Combined History panel if it was previously hidden and additionally turn it into the default panel if the Recent Tabs panel was the previous default panel. MozReview-Commit-ID: 5CSJUTRysQU
22f8e6c629ea0cee57c186c4280bf8771e09670f: Bug 1251362 - Part 17 - Turn reading list panel migration function into a generic panel removal function. r=liuche
Jan Henning <jh+bugzilla@buttercookie.de> - Sat, 21 May 2016 18:27:55 +0200 - rev 376613
Push 20629 by chevobbe.nicolas@gmail.com at Wed, 08 Jun 2016 11:44:20 +0000
Bug 1251362 - Part 17 - Turn reading list panel migration function into a generic panel removal function. r=liuche By passing the panel types to be removed/set as new default panel as arguments instead of hard coding them, we can reuse that function for our own home panel config migration. MozReview-Commit-ID: BsMxcbInRbX
2ded136fbae5d92668e02f84a36a6005381e3e46: Bug 1251362 - Part 16 - Remove the Recent Tabs panel from the default home panel config. r=liuche
Jan Henning <jh+bugzilla@buttercookie.de> - Sun, 15 May 2016 02:22:03 +0200 - rev 376612
Push 20629 by chevobbe.nicolas@gmail.com at Wed, 08 Jun 2016 11:44:20 +0000
Bug 1251362 - Part 16 - Remove the Recent Tabs panel from the default home panel config. r=liuche MozReview-Commit-ID: IX6AkBoa3Mg
e2b22babd7b3b15e21e9e325bff5ef386611adc7: Bug 1251362 - Part 15 - Redirect direct loads of the Recent Tabs panel about:home URL to the Recent Tabs folder of the Combined History panel. r=liuche
Jan Henning <jh+bugzilla@buttercookie.de> - Thu, 26 May 2016 23:04:53 +0200 - rev 376611
Push 20629 by chevobbe.nicolas@gmail.com at Wed, 08 Jun 2016 11:44:20 +0000
Bug 1251362 - Part 15 - Redirect direct loads of the Recent Tabs panel about:home URL to the Recent Tabs folder of the Combined History panel. r=liuche After detecting multiple successive crashes in a row, we temporarily switch off automatic session restoring and display the Recent Tabs panel instead. As that panel is going to be removed, we intercept loads of the Recent Tabs panel about:home?panel=... URL and redirect them to the Combined History panel. We also use the facilities provided by bug 1060544 to jump directly to the Recent Tabs folder in that case. MozReview-Commit-ID: 7dQ7tW2dD1M
1060ef1606c577ac10f6686aba08925d79847cfe: Bug 1251362 - Part 14 - Add telemetry for restoring tabs. r=liuche
Jan Henning <jh+bugzilla@buttercookie.de> - Wed, 18 May 2016 19:04:49 +0200 - rev 376610
Push 20629 by chevobbe.nicolas@gmail.com at Wed, 08 Jun 2016 11:44:20 +0000
Bug 1251362 - Part 14 - Add telemetry for restoring tabs. r=liuche This adds telemetry for clicking on a closed tab or the "Open all" button. Methods and extras strings are based on those used for the old Recent Tabs panel. MozReview-Commit-ID: 1Kc8fACkmIc
85eee022eb7d957112571226dbe89882a5799852: Bug 1251362 - Part 13 - Only enable swipe to refresh within the Synced devices smart folder. r=liuche
Jan Henning <jh+bugzilla@buttercookie.de> - Sat, 14 May 2016 23:38:29 +0200 - rev 376609
Push 20629 by chevobbe.nicolas@gmail.com at Wed, 08 Jun 2016 11:44:20 +0000
Bug 1251362 - Part 13 - Only enable swipe to refresh within the Synced devices smart folder. r=liuche Recently closed tabs aren't synced, therefore being able to swipe to refresh within the Recent tabs folder isn't necessary. To avoid triggering a refresh by accident, we restrict swipe to refresh to the Synced devices folder itself. MozReview-Commit-ID: YwekSwQr2q
(0) -300000 -100000 -30000 -10000 -3000 -1000 -300 -100 -50 -20 +20 +50 +100 +300 +1000 +3000 +10000 +30000 +100000 +300000 tip