baa3bfef08bd89510532275fb2fa91616a34c1da: Bug 1216489 - 2. Cleanup width and height calculations in TabsPanel. r=sebastian
Tom Klein <twointofive@gmail.com> - Wed, 30 Nov 2016 17:31:37 -0600 - rev 491673
Push 47374 by kwierso@gmail.com at Thu, 02 Mar 2017 02:14:53 +0000
Bug 1216489 - 2. Cleanup width and height calculations in TabsPanel. r=sebastian MozReview-Commit-ID: I1chEZDnOyR
b96ede86735972a43f0ee84954887763b4d6ab37: Bug 1216489 - 1. Cleanup TabsPanel includes and remove member variable. r=sebastian
Tom Klein <twointofive@gmail.com> - Wed, 30 Nov 2016 17:02:53 -0600 - rev 491672
Push 47374 by kwierso@gmail.com at Thu, 02 Mar 2017 02:14:53 +0000
Bug 1216489 - 1. Cleanup TabsPanel includes and remove member variable. r=sebastian MozReview-Commit-ID: 9eTBEf8xj1l
8a62afb4f1790a2d78d0a9f8cdfa5d20fba9f71b: Bug 1340929 - Don't scroll to a new tab opened from a link. r=sebastian
Tom Klein <twointofive@gmail.com> - Wed, 22 Feb 2017 21:54:11 -0600 - rev 491671
Push 47374 by kwierso@gmail.com at Thu, 02 Mar 2017 02:14:53 +0000
Bug 1340929 - Don't scroll to a new tab opened from a link. r=sebastian We used to scroll in addTab to make sure a new tab created by a close-tab-undo at the start or the end of the list was made visible instead of staying where it was created off the edge. We're now taking care of that in selectTab (where it should have stayed in the first place), where the select in that case occurs between the time when the new tab is added to the adapter and when the layout gets updated. In the case where the new tab is at the start, that means the check 'position < layoutManager.findFirstCompletelyVisibleItemPosition()' in selectTab reads '0 < 0', which fails (which is why we need the new check for 'position == 0'), but the check 'position > layoutManager.findLastCompletelyVisibleItemPosition()' for a tab added at the end reads 'new_lengh -1 > old_length - 1' which already passes, so we don't need a special case for undo-tab-close adds at the end in selectTab. Tabs added at the end by a normal "create new tab" still scroll for the same reason. Robotium was confused by the duplicate 'add_tab' ids from the tab strip and the tabs panel, so I renamed one of them. Also note that the 'getTabId' added to TabStripItemView for testing already exists on TabLayoutItemView, but the two classes don't share a common base. MozReview-Commit-ID: BzG2r8BSs90
42093254f824bc2676ca935ec2c11bcf8c6d0574: Bug 1343539: Enable unit and talos tests for macosx64 opt. r=catlee
Wander Lairson Costa <wcosta@mozilla.com> - Wed, 01 Mar 2017 15:26:13 -0300 - rev 491670
Push 47374 by kwierso@gmail.com at Thu, 02 Mar 2017 02:14:53 +0000
Bug 1343539: Enable unit and talos tests for macosx64 opt. r=catlee BBB schedules macosx64 debug unit tests, but opt is schedule by buildbot itself. MozReview-Commit-ID: I8FqzCHgzga
01131dccb20c5228b2826356ae6ed1c7d479a40a: servo: Merge #15416 - Fix border shorthand serialization (from karlding:servo-15395_border_serialization); r=emilio
Karl <karlding@users.noreply.github.com> - Wed, 01 Mar 2017 09:50:49 -0800 - rev 491669
Push 47374 by kwierso@gmail.com at Thu, 02 Mar 2017 02:14:53 +0000
servo: Merge #15416 - Fix border shorthand serialization (from karlding:servo-15395_border_serialization); r=emilio Fix border shorthand serialization when sides are not identical. I think I managed to get the serialization to work as expected. I added a check to ensure that the **border-width**, **border-style** and **border-color** were the same, before performing the serialization. I'm still a Rust newbie, so if there's a more idiomatic way of doing things (or any critiques in general), please let me know! --- <!-- Thank you for contributing to Servo! Please replace each `[ ]` by `[X]` when the step is complete, and replace `__` with appropriate data: --> - [X] `./mach build -d` does not report any errors - [X] `./mach test-tidy` does not report any errors - [X] These changes fix #15395 <!-- Either: --> - [X] There are tests for these changes <!-- Pull requests that do not address these steps are welcome, but they will require additional verification as part of the review process. --> Source-Repo: https://github.com/servo/servo Source-Revision: f0257364c26ef89e7652eabe73a3788388adf5ca
b25d9cfea3f9b5b822109af7ea4d90ae04463a7e: Bug 1337115 - Part 2 - Send telemetry if session restore completely fails and we're not on the first run. r=sebastian
Jan Henning <jh+bugzilla@buttercookie.de> - Fri, 17 Feb 2017 20:02:33 +0100 - rev 491668
Push 47374 by kwierso@gmail.com at Thu, 02 Mar 2017 02:14:53 +0000
Bug 1337115 - Part 2 - Send telemetry if session restore completely fails and we're not on the first run. r=sebastian For a fresh profile it is expected that there are no session files to restore from, however afterwards we should normally always have a valid - if possibly empty - session file available. We try excluding the first run case by checking the first run pref used by Telemetry so far and see whether we get any reasonable results out of this... MozReview-Commit-ID: 2ZxmLqwhk32
1f45e38b27af6a061a9b71dcdff3cf9074d4b629: Bug 1337115 - Part 1 - Make "Is first run" pref generally useable. r=sebastian
Jan Henning <jh+bugzilla@buttercookie.de> - Thu, 23 Feb 2017 22:16:26 +0100 - rev 491667
Push 47374 by kwierso@gmail.com at Thu, 02 Mar 2017 02:14:53 +0000
Bug 1337115 - Part 1 - Make "Is first run" pref generally useable. r=sebastian This pref could be useful for things outside of the TelemetryCorePingDelegate as well, so we have it live in GeckoApp now. MozReview-Commit-ID: 2JZ3vNqSzcl
d3241c1454e4c6639533ecc3c38c7f7912f7f0b3: Bug 1303060: Fix problematic annotation on mscom::InParamWalker; r=staticbustage-fix
Aaron Klotz <aklotz@mozilla.com> - Wed, 01 Mar 2017 11:05:35 -0700 - rev 491666
Push 47374 by kwierso@gmail.com at Thu, 02 Mar 2017 02:14:53 +0000
Bug 1303060: Fix problematic annotation on mscom::InParamWalker; r=staticbustage-fix MozReview-Commit-ID: 2QtUJ4Bbk1m
e91de6fb2b3dce9c932428265b0fdb630ea470d7: Merge inbound to central, a=merge
Wes Kocher <wkocher@mozilla.com> - Wed, 01 Mar 2017 17:18:37 -0800 - rev 491665
Push 47374 by kwierso@gmail.com at Thu, 02 Mar 2017 02:14:53 +0000
Merge inbound to central, a=merge MozReview-Commit-ID: 7vInHaD1geB
a18510cb914956cbdd95cbec9404ca9d7ddcfb03: Bug 1342354 - Add pref pref on/off switch for new bookmark features. r?ahunt draft
Nevin Chen <cnevinchen@gmail.com> - Fri, 24 Feb 2017 18:05:10 +0800 - rev 491664
Push 47373 by bmo:cnevinchen@gmail.com at Thu, 02 Mar 2017 02:04:04 +0000
Bug 1342354 - Add pref pref on/off switch for new bookmark features. r?ahunt MozReview-Commit-ID: 1Rz7rAao5Is
b97b79caaa7ae18a7fa396bd5e096e09685f0d1b: Bug 1343716 - Use Windows style paths for TOOLTOOL_CACHE. r?mshal draft
Mike Hommey <mh+mozilla@glandium.org> - Wed, 01 Mar 2017 11:26:39 +0900 - rev 491663
Push 47372 by bmo:mh+mozilla@glandium.org at Thu, 02 Mar 2017 01:37:33 +0000
Bug 1343716 - Use Windows style paths for TOOLTOOL_CACHE. r?mshal Currently, tooltool is a python script, but when called from mozharness, it's wrapped with a shell script. What happens is that mozharness gets the msys-style paths, passes them to the shell script, then the shell script calls the python tooltool, and the transition msys->win32 makes that call use windows style paths. For bug 1313111, I want to replace tooltool with a mach command, and the shell script would go away. Calling a mach command (or python tooltool, for that matter) directly from mozharness with a msys-style path doesn't work. OTOH, calling the current shell script with a Windows style path (with forward slashes, for good measure) does work, and is future-proof.
9a57bf2c18422f20a4f43c067bbfb7bdaa438c2d: Bug 1341434 - document high-level client-side implementation details for system add-ons r?aswan draft
Robert Helmer <rhelmer@mozilla.com> - Tue, 21 Feb 2017 13:34:05 -0800 - rev 491662
Push 47371 by rhelmer@mozilla.com at Thu, 02 Mar 2017 01:31:02 +0000
Bug 1341434 - document high-level client-side implementation details for system add-ons r?aswan MozReview-Commit-ID: fvF5EjepYr
56f4e781211cc1c0e2a57beee7af83f0406bf677: Bug 1343713 - Avoid mozconfig failures when clang-cl/msvc are not present. r?ted draft
Mike Hommey <mh+mozilla@glandium.org> - Wed, 01 Mar 2017 11:10:14 +0900 - rev 491661
Push 47370 by bmo:mh+mozilla@glandium.org at Thu, 02 Mar 2017 01:24:32 +0000
Bug 1343713 - Avoid mozconfig failures when clang-cl/msvc are not present. r?ted The `cd $PATH && pwd` pattern doesn't work when $PATH doesn't exist, so move them in a block only executed when the directory exists.
1b6440e59642a7de922a02b0fde6707650efd2fd: Bug 1343713 - Avoid mozconfig failure when sccache is not there. r?ted draft
Mike Hommey <mh+mozilla@glandium.org> - Wed, 01 Mar 2017 11:06:40 +0900 - rev 491660
Push 47370 by bmo:mh+mozilla@glandium.org at Thu, 02 Mar 2017 01:24:32 +0000
Bug 1343713 - Avoid mozconfig failure when sccache is not there. r?ted The build will fail during configure anyways in that case, not silently fallback to compiling without it.
27271e4ccb68eb67f2f9fb8d2c46ebe2097a3f23: Bug 1341434 - document high-level client-side implementation details for system add-ons r?aswan draft
Robert Helmer <rhelmer@mozilla.com> - Tue, 21 Feb 2017 13:34:05 -0800 - rev 491659
Push 47369 by rhelmer@mozilla.com at Thu, 02 Mar 2017 01:20:25 +0000
Bug 1341434 - document high-level client-side implementation details for system add-ons r?aswan MozReview-Commit-ID: fvF5EjepYr
1b89555dd6cc3da58944352970db915967bc00e4: Bug 1341434 - document high-level client-side implementation details for system add-ons r?aswan draft
Robert Helmer <rhelmer@mozilla.com> - Tue, 21 Feb 2017 13:34:05 -0800 - rev 491658
Push 47368 by rhelmer@mozilla.com at Thu, 02 Mar 2017 01:18:08 +0000
Bug 1341434 - document high-level client-side implementation details for system add-ons r?aswan MozReview-Commit-ID: fvF5EjepYr
1db4b96f85963f144b4dd0c1985a7634c904e5a9: Bug 1258360: Implement onMessageExternal and onConnectExternal. r?mixedpuppy draft
Kris Maglione <maglione.k@gmail.com> - Sat, 11 Feb 2017 13:28:18 -0800 - rev 491657
Push 47367 by maglione.k@gmail.com at Thu, 02 Mar 2017 01:16:16 +0000
Bug 1258360: Implement onMessageExternal and onConnectExternal. r?mixedpuppy MozReview-Commit-ID: 7NTrgyWpXbv
d3163043facfcb29ecfd5593c56e35fc0f1313d0: Bug 1341434 - document high-level client-side implementation details for system add-ons r?kmag draft
Robert Helmer <rhelmer@mozilla.com> - Tue, 21 Feb 2017 13:34:05 -0800 - rev 491656
Push 47366 by rhelmer@mozilla.com at Thu, 02 Mar 2017 01:15:50 +0000
Bug 1341434 - document high-level client-side implementation details for system add-ons r?kmag MozReview-Commit-ID: fvF5EjepYr
9b9323015bb2dae1af6ec0b66d06eb30363a876c: Bug 1258360: Implement onMessageExternal and onConnectExternal. r?mixedpuppy draft
Kris Maglione <maglione.k@gmail.com> - Sat, 11 Feb 2017 13:28:18 -0800 - rev 491655
Push 47365 by maglione.k@gmail.com at Thu, 02 Mar 2017 01:00:07 +0000
Bug 1258360: Implement onMessageExternal and onConnectExternal. r?mixedpuppy MozReview-Commit-ID: 7NTrgyWpXbv
e77029e048140ddfc860b422ec34a03a8d411b16: Bug 1058040, part 13 - Have nsImageBoxFrame pass context paint to VectorImage. r=dholbert
Jonathan Watt <jwatt@jwatt.org> - Fri, 27 Jan 2017 02:22:44 +0000 - rev 491654
Push 47365 by maglione.k@gmail.com at Thu, 02 Mar 2017 01:00:07 +0000
Bug 1058040, part 13 - Have nsImageBoxFrame pass context paint to VectorImage. r=dholbert
(0) -300000 -100000 -30000 -10000 -3000 -1000 -300 -100 -50 -20 +20 +50 +100 +300 +1000 +3000 +10000 +30000 +100000 +300000 tip