7ab520fbbc7e8117ef7d7426bab8d4d7982c61b6: Bug 1256490 - Disable C4302 to unblock compilation on VS2015; r?bobowen draft
Gregory Szorc <gps@mozilla.com> - Mon, 14 Mar 2016 17:00:09 -0700 - rev 340066
Push 12902 by gszorc@mozilla.com at Tue, 15 Mar 2016 00:00:31 +0000
Bug 1256490 - Disable C4302 to unblock compilation on VS2015; r?bobowen As part of unblocking building with VS2015u1 in automation, I'm mass disabling compiler warnings that are turned into errors. This is not the preferred mechanism to fix compilation warnings. But the warning occurs in third party code, so my hands are tied. MozReview-Commit-ID: 6n8nl517Ly
a6c7720178a5a9cbcb035a24ae1cc2bb2d4eb9a3: enable PGO draft
Gregory Szorc <gps@mozilla.com> - Tue, 08 Mar 2016 14:48:22 -0800 - rev 340065
Push 12902 by gszorc@mozilla.com at Tue, 15 Mar 2016 00:00:31 +0000
enable PGO MozReview-Commit-ID: EdiNUx21iPr
36a096a4088b06491772d7907b9066c912404064: Bug 1186060 - Build with Visual Studio 2015 Update 1; r?ted, ehsan draft
Gregory Szorc <gps@mozilla.com> - Thu, 10 Mar 2016 21:13:20 -0800 - rev 340064
Push 12902 by gszorc@mozilla.com at Tue, 15 Mar 2016 00:00:31 +0000
Bug 1186060 - Build with Visual Studio 2015 Update 1; r?ted, ehsan This commit switches Windows builds from Visual Studio 2013 to Visual Studio 2015 Update 1. Previously, Visual Studio was installed on the builers as part of the base system image. Starting with this commit, we obtain Visual Studio from a pre-generated, self-contained archive containing the executables, Windows SDK, and other support files. This means that new Windows toolchains can be installed without having to modify configuration of machines in automation! The mozconfigs for Visual Studio 2015 are a bit different from existing mozconfigs. Because it appears to be completely redundant and not necessary, the LIBPATH variable has been dropped. The order of paths in PATH, LIB, and INCLUDE has changed. The new order more accurately reflects what would be defined by vcvarsall.bat. As part of switching to Visual Studio 2015, the Universal CRT is now required. So, the 2015 mozconfigs export WIN_UCRT_REDIST_DIR to define the location to those files. The switch to Visual Studio 2015 also involves the switch from the Windows 8.1 SDK to the Windows 10 SDK. However, we still target an old version of Windows, so this hopefully shouldn't have any significant fallout. It's worth noting that switching to Visual Studio 2015 makes builds - especially PGO builds - significantly faster. Our PGO build times in automation are ~1 hour faster. Our regular builds appear to be a few minutes faster. MozReview-Commit-ID: Pa5GW8V87Q
27381cbd24a30a235c31cc6f2bdfbbeaeeb82d35: Bug 1253707 - Script to generate visual studio toolchain archive; r?ted draft
Gregory Szorc <gps@mozilla.com> - Fri, 11 Mar 2016 15:00:02 -0800 - rev 340063
Push 12902 by gszorc@mozilla.com at Tue, 15 Mar 2016 00:00:31 +0000
Bug 1253707 - Script to generate visual studio toolchain archive; r?ted Previously, Windows toolchains and related dependencies (SDKs, etc) were installed on Windows builders by people responsible for maintaining those machines. This commit takes a step in a new direction. We introduce a script (complete with documentation) that can produce a zip archive (or any archive format if people want to implement support) of the toolchain files. Basically, you install Visual Studio 2015 Community, run the script, and produce a self-contained zip file containing everything from Microsoft you need to build Firefox. With a copy of this archive and an installation of MozillaBuild, it is possible to build Firefox on a fresh Windows installation. No time-consuming Visual Studio installation needed. The goal is to upload these archives to tooltool and have our Windows builders download and extract them at run-time. At which time, we can remove all the other Visual Studio and SDK files from builders because they don't need to be baked into the image. We may find tooltool's caching isn't good enough and we have to more aggressively caching the standalone toolchain files. But that is a problem for another day. Whatever happens, we'll need the functionality in this script to produce a self-contained archive of the toolchain. There are certainly files in the produced archive that aren't needed. I think perfect is the enemy of done and we can prune the archive over time, if wanted. MozReview-Commit-ID: EckEK1a6vA3
f2859ae0e59946755dd240a3d8b97f344b0c0ef4: Bug 1250244 - (WIP, Don't commit) Implement WebVR 1.0 API draft
Kearwood (Kip) Gilbert <kgilbert@mozilla.com> - Wed, 24 Feb 2016 15:54:50 -0800 - rev 340062
Push 12901 by kgilbert@mozilla.com at Mon, 14 Mar 2016 23:52:21 +0000
Bug 1250244 - (WIP, Don't commit) Implement WebVR 1.0 API MozReview-Commit-ID: JTOmaWePlJq
95f0b2b0433d0413d756306b0c085083c51c51e8: Bug 1124033 - Replace blanket disabling of VS2015 warnings with C5026 and C5027; r?ehsan draft
Gregory Szorc <gps@mozilla.com> - Mon, 14 Mar 2016 14:38:12 -0700 - rev 340061
Push 12900 by gszorc@mozilla.com at Mon, 14 Mar 2016 23:40:40 +0000
Bug 1124033 - Replace blanket disabling of VS2015 warnings with C5026 and C5027; r?ehsan Wv:18 was added in bug 1119072 as a quick way to get the tree building with VS2015. Now that we're closer to rolling out VS2015 support, we want to expose its new warnings. This patch replaces the blanket disabling of new warnings in VS2015 with just disabling C5026 and C5027, which relate to symbols being implicitly defined as deleted. MozReview-Commit-ID: 8uniydfNJns
610201844bca202dd305da220f61cd6357650e1c: Bug 1256484 - Disable C4456 and C4458 to unblock compilation on VS2015; r?dkeeler draft
Gregory Szorc <gps@mozilla.com> - Mon, 14 Mar 2016 16:39:48 -0700 - rev 340060
Push 12899 by gszorc@mozilla.com at Mon, 14 Mar 2016 23:40:08 +0000
Bug 1256484 - Disable C4456 and C4458 to unblock compilation on VS2015; r?dkeeler As part of unblocking building with VS2015u1 in automation, I'm mass disabling compiler warnings that are turned into errors. This is not the preferred mechanism to fix compilation warnings. So hopefully someone fixes the underlying problem someday. However, there are tons of ignored warnings in security/certverifier, so I guess the workaround in this patch is par for the course. MozReview-Commit-ID: 7GZ9RpkxnwT
db2a0755f8dcc0970f9222c04398e7beae8e05ff: Bug 1256473 - Disable C4456 and C4458 to unblock compilation on VS2015; r?dkeeler draft
Gregory Szorc <gps@mozilla.com> - Mon, 14 Mar 2016 16:33:29 -0700 - rev 340059
Push 12898 by gszorc@mozilla.com at Mon, 14 Mar 2016 23:33:49 +0000
Bug 1256473 - Disable C4456 and C4458 to unblock compilation on VS2015; r?dkeeler As part of unblocking building with VS2015u1 in automation, I'm mass disabling compiler warnings that are turned into errors. This is not the preferred mechanism to fix compilation warnings. So hopefully someone fixes the underlying problem someday. However, there are tons of ignored warnings in security/certverifier, so I guess the workaround in this patch is par for the course. MozReview-Commit-ID: 7GZ9RpkxnwT
aa9d03e0fbd48a50845f6624b026a72d6155840a: Bug 1186060 - Build with Visual Studio 2015 Update 1; r?ted, ehsan draft
Gregory Szorc <gps@mozilla.com> - Thu, 10 Mar 2016 21:13:20 -0800 - rev 340058
Push 12898 by gszorc@mozilla.com at Mon, 14 Mar 2016 23:33:49 +0000
Bug 1186060 - Build with Visual Studio 2015 Update 1; r?ted, ehsan This commit switches Windows builds from Visual Studio 2013 to Visual Studio 2015 Update 1. Previously, Visual Studio was installed on the builers as part of the base system image. Starting with this commit, we obtain Visual Studio from a pre-generated, self-contained archive containing the executables, Windows SDK, and other support files. This means that new Windows toolchains can be installed without having to modify configuration of machines in automation! The mozconfigs for Visual Studio 2015 are a bit different from existing mozconfigs. Because it appears to be completely redundant and not necessary, the LIBPATH variable has been dropped. The order of paths in PATH, LIB, and INCLUDE has changed. The new order more accurately reflects what would be defined by vcvarsall.bat. As part of switching to Visual Studio 2015, the Universal CRT is now required. So, the 2015 mozconfigs export WIN_UCRT_REDIST_DIR to define the location to those files. The switch to Visual Studio 2015 also involves the switch from the Windows 8.1 SDK to the Windows 10 SDK. However, we still target an old version of Windows, so this hopefully shouldn't have any significant fallout. It's worth noting that switching to Visual Studio 2015 makes builds - especially PGO builds - significantly faster. Our PGO build times in automation are ~1 hour faster. Our regular builds appear to be a few minutes faster. MozReview-Commit-ID: Pa5GW8V87Q
8d425b5a0cb4673967a89a1c7dcda3322738a52e: Bug 1253707 - Script to generate visual studio toolchain archive; r?ted draft
Gregory Szorc <gps@mozilla.com> - Fri, 11 Mar 2016 15:00:02 -0800 - rev 340057
Push 12898 by gszorc@mozilla.com at Mon, 14 Mar 2016 23:33:49 +0000
Bug 1253707 - Script to generate visual studio toolchain archive; r?ted Previously, Windows toolchains and related dependencies (SDKs, etc) were installed on Windows builders by people responsible for maintaining those machines. This commit takes a step in a new direction. We introduce a script (complete with documentation) that can produce a zip archive (or any archive format if people want to implement support) of the toolchain files. Basically, you install Visual Studio 2015 Community, run the script, and produce a self-contained zip file containing everything from Microsoft you need to build Firefox. With a copy of this archive and an installation of MozillaBuild, it is possible to build Firefox on a fresh Windows installation. No time-consuming Visual Studio installation needed. The goal is to upload these archives to tooltool and have our Windows builders download and extract them at run-time. At which time, we can remove all the other Visual Studio and SDK files from builders because they don't need to be baked into the image. We may find tooltool's caching isn't good enough and we have to more aggressively caching the standalone toolchain files. But that is a problem for another day. Whatever happens, we'll need the functionality in this script to produce a self-contained archive of the toolchain. There are certainly files in the produced archive that aren't needed. I think perfect is the enemy of done and we can prune the archive over time, if wanted. MozReview-Commit-ID: EckEK1a6vA3
eee251dd8eb5bed2f9d4ccb5fa8f24778e432036: Bug 1124033 - Replace blanket disabling of VS2015 warnings with C5026 and C5027; r?ehsan draft
Gregory Szorc <gps@mozilla.com> - Mon, 14 Mar 2016 14:38:12 -0700 - rev 340056
Push 12898 by gszorc@mozilla.com at Mon, 14 Mar 2016 23:33:49 +0000
Bug 1124033 - Replace blanket disabling of VS2015 warnings with C5026 and C5027; r?ehsan Wv:18 was added in bug 1119072 as a quick way to get the tree building with VS2015. Now that we're closer to rolling out VS2015 support, we want to expose its new warnings. This patch replaces the blanket disabling of new warnings in VS2015 with just disabling C5026 and C5027, which relate to symbols being implicitly defined as deleted. MozReview-Commit-ID: 8uniydfNJns
163822ac5edb807b44c2cabb7ffb609a973292f7: Bug 1256482 - Disable C4312 to unblock compilation on VS2015; r?jesup draft
Gregory Szorc <gps@mozilla.com> - Mon, 14 Mar 2016 16:05:06 -0700 - rev 340055
Push 12898 by gszorc@mozilla.com at Mon, 14 Mar 2016 23:33:49 +0000
Bug 1256482 - Disable C4312 to unblock compilation on VS2015; r?jesup As part of unblocking building with VS2015u1 in automation, I'm mass disabling compiler warnings that are turned into errors. This is not the preferred mechanism to fix compilation warnings, of course. Given that the warning is in WebRTC which is third party code, there isn't much we can do about the warning. However, Google is building Chrome with Visual Studio 2015, so I wouldn't be surprised if this were fixed upstream or will be fixed upstream. Then again, we allow warnings when building WebRTC. So perhaps not. MozReview-Commit-ID: G6JP9fkCzfn
b1edb7f2ae181ffa8aa9387a769b97b5f66c2450: Bug 1254468 - Remove broken TransitionAwareCursorLoaderCallbacks r?nalexander draft
Andrzej Hunt <andrzej@ahunt.org> - Mon, 14 Mar 2016 15:38:53 -0700 - rev 340054
Push 12897 by bmo:ahunt@mozilla.com at Mon, 14 Mar 2016 23:22:21 +0000
Bug 1254468 - Remove broken TransitionAwareCursorLoaderCallbacks r?nalexander TransitionAwareCursorLoaderCallbacks is fundamentally flawed: old CursorLoader cursors _must_ not be used after onLoadFinished has been called. However we sometimes queue the cursor swapping (which is implemented by subclasses in onLoadFinishedAfterTransitions) until after transitions have finished. CursorLoader.deliverResult() closes the old cursor immediately after calling onLoadFinished (with the new cursor). At this stage the adapter is still holding onto the old (but now closed cursor), and will crash if it tries to read this cursor (which can happen if the adapter is still iterating over the cursor). Instead we should ensure that we swap the cursors during onLoadFinished - the simplest way to do this is by eliminating TransitionAwareCursorLoader and using onLoadFinished the way the Android framework expects. It's worth noting that TransitionAwareCursorLoader is obsolete: at the time it was added, home panels were placed in the HomePagerTabStrip, which notified TransitionsTracker about its transitions. However HomePagerTabStrip no longer exists, hence there's no need for us to care about these transitions anymore. (The crash seems to happen because we try to hide the doorhanger every time we reveid LOCATION_CHANGE, and each of these starts a hide transition - even if no doorhanger is shown - hence we often have a transition in progress every time we show topsites.) MozReview-Commit-ID: HsytLpHOrp2
0f85b1e60eb07dd8d8091419fbe8b57777b4bfca: Bug 1254468 - Remove (flawed) TransitionAwareCursorLoaderCallbacks r?nalexander draft
Andrzej Hunt <andrzej@ahunt.org> - Mon, 14 Mar 2016 15:38:53 -0700 - rev 340053
Push 12896 by bmo:ahunt@mozilla.com at Mon, 14 Mar 2016 23:21:28 +0000
Bug 1254468 - Remove (flawed) TransitionAwareCursorLoaderCallbacks r?nalexander TransitionAwareCursorLoaderCallbacks is fundamentally flawed: old CursorLoader cursors _must_ not be used after onLoadFinished has been called. However we sometimes queue the cursor swapping (which is implemented by subclasses in onLoadFinishedAfterTransitions) until after transitions have finished. CursorLoader.deliverResult() closes the old cursor immediately after calling onLoadFinished (with the new cursor). At this stage the adapter is still holding onto the old (but now closed cursor), and will crash if it tries to read this cursor (which can happen if the adapter is still iterating over the cursor). Instead we should ensure that we swap the cursors during onLoadFinished - the simplest way to do this is by eliminating TransitionAwareCursorLoader and using onLoadFinished the way the Android framework expects. It's worth noting that TransitionAwareCursorLoader is obsolete: at the time it was added, home panels were placed in the HomePagerTabStrip, which notified TransitionsTracker about its transitions. However HomePagerTabStrip no longer exists, hence there's no need for us to care about these transitions anymore. (The crash seems to happen because we try to hide the doorhanger every time we reveid LOCATION_CHANGE, and each of these starts a hide transition - even if no doorhanger is shown - hence we often have a transition in progress every time we show topsites.) MozReview-Commit-ID: HsytLpHOrp2
77a0d45708fb20a8172256f111958b013f00a277: Bug 1254468 - Remove (flawed) TransitionAwareCursorLoaderCallbacks r?nalexander draft
Andrzej Hunt <andrzej@ahunt.org> - Mon, 14 Mar 2016 15:38:53 -0700 - rev 340052
Push 12895 by bmo:ahunt@mozilla.com at Mon, 14 Mar 2016 23:19:14 +0000
Bug 1254468 - Remove (flawed) TransitionAwareCursorLoaderCallbacks r?nalexander TransitionAwareCursorLoaderCallbacks is fundamentally flawed: old CursorLoader cursors _must_ not be used after onLoadFinished has been called. However we sometimes queue the cursor swapping (which is implemented by subclasses in onLoadFinishedAfterTransitions) until after transitions have finished. However CursorLoader.deliverResult() closes the old cursor immediately after calling onLoadFinished (with the new cursor). At this stage the adapter is still holding onto the old (but now closed cursor), and it will crash if it tries to read this cursor (which can happen e.g. if the adapter hasn't finished iterating over the cursor). Instead we should ensure that we swap the cursors during onLoadFinished - the simplest way to do this is by eliminating TransitionAwareCursorLoader. It's worth noting that TransitionAwareCursorLoader is obsolete: at the time it was added, home panels were placed in the HomePagerTabStrip, which notified TransitionsTracker about its transitions. However HomePagerTabStrip no longer exists, hence there's no need for us to care about these transitions anymore. (The crash seems to happen because we try to hide the doorhanger every time we reveid LOCATION_CHANGE, and each of these starts a hide transition - even if no doorhanger is shown - hence we often have a transition in progress every time we show topsites.) MozReview-Commit-ID: HsytLpHOrp2
8d7803f7a57f8f97db4aa51cfb2f4735d80ccc88: Bug 1255127 - Decrease height of bookmark folders to match remote client item height. r=grisha draft
Chenxia Liu <liuche@mozilla.com> - Wed, 09 Mar 2016 11:48:55 -0800 - rev 340051
Push 12894 by cliu@mozilla.com at Mon, 14 Mar 2016 23:07:22 +0000
Bug 1255127 - Decrease height of bookmark folders to match remote client item height. r=grisha MozReview-Commit-ID: HIveNuSTuPf
deb1dba5449d15c6b697a02f688d4b19339161c6: Bug 1256482 - Disable C4312 to unblock compilation on VS2015; r?jesup draft
Gregory Szorc <gps@mozilla.com> - Mon, 14 Mar 2016 16:05:06 -0700 - rev 340050
Push 12893 by gszorc@mozilla.com at Mon, 14 Mar 2016 23:05:32 +0000
Bug 1256482 - Disable C4312 to unblock compilation on VS2015; r?jesup As part of unblocking building with VS2015u1 in automation, I'm mass disabling compiler warnings that are turned into errors. This is not the preferred mechanism to fix compilation warnings, of course. Given that the warning is in WebRTC which is third party code, there isn't much we can do about the warning. However, Google is building Chrome with Visual Studio 2015, so I wouldn't be surprised if this were fixed upstream or will be fixed upstream. Then again, we allow warnings when building WebRTC. So perhaps not. MozReview-Commit-ID: G6JP9fkCzfn
a2af8be864806b229ff329ab560a76bc553ef009: Bug 1186060 - Build with Visual Studio 2015 Update 1; r?ted, ehsan draft
Gregory Szorc <gps@mozilla.com> - Thu, 10 Mar 2016 21:13:20 -0800 - rev 340049
Push 12893 by gszorc@mozilla.com at Mon, 14 Mar 2016 23:05:32 +0000
Bug 1186060 - Build with Visual Studio 2015 Update 1; r?ted, ehsan This commit switches Windows builds from Visual Studio 2013 to Visual Studio 2015 Update 1. Previously, Visual Studio was installed on the builers as part of the base system image. Starting with this commit, we obtain Visual Studio from a pre-generated, self-contained archive containing the executables, Windows SDK, and other support files. This means that new Windows toolchains can be installed without having to modify configuration of machines in automation! The mozconfigs for Visual Studio 2015 are a bit different from existing mozconfigs. Because it appears to be completely redundant and not necessary, the LIBPATH variable has been dropped. The order of paths in PATH, LIB, and INCLUDE has changed. The new order more accurately reflects what would be defined by vcvarsall.bat. As part of switching to Visual Studio 2015, the Universal CRT is now required. So, the 2015 mozconfigs export WIN_UCRT_REDIST_DIR to define the location to those files. The switch to Visual Studio 2015 also involves the switch from the Windows 8.1 SDK to the Windows 10 SDK. However, we still target an old version of Windows, so this hopefully shouldn't have any significant fallout. It's worth noting that switching to Visual Studio 2015 makes builds - especially PGO builds - significantly faster. Our PGO build times in automation are ~1 hour faster. Our regular builds appear to be a few minutes faster. MozReview-Commit-ID: Pa5GW8V87Q
256e86799fc0e845105c4b5d8acff2c610582a24: Bug 1253707 - Script to generate visual studio toolchain archive; r?ted draft
Gregory Szorc <gps@mozilla.com> - Fri, 11 Mar 2016 15:00:02 -0800 - rev 340048
Push 12893 by gszorc@mozilla.com at Mon, 14 Mar 2016 23:05:32 +0000
Bug 1253707 - Script to generate visual studio toolchain archive; r?ted Previously, Windows toolchains and related dependencies (SDKs, etc) were installed on Windows builders by people responsible for maintaining those machines. This commit takes a step in a new direction. We introduce a script (complete with documentation) that can produce a zip archive (or any archive format if people want to implement support) of the toolchain files. Basically, you install Visual Studio 2015 Community, run the script, and produce a self-contained zip file containing everything from Microsoft you need to build Firefox. With a copy of this archive and an installation of MozillaBuild, it is possible to build Firefox on a fresh Windows installation. No time-consuming Visual Studio installation needed. The goal is to upload these archives to tooltool and have our Windows builders download and extract them at run-time. At which time, we can remove all the other Visual Studio and SDK files from builders because they don't need to be baked into the image. We may find tooltool's caching isn't good enough and we have to more aggressively caching the standalone toolchain files. But that is a problem for another day. Whatever happens, we'll need the functionality in this script to produce a self-contained archive of the toolchain. There are certainly files in the produced archive that aren't needed. I think perfect is the enemy of done and we can prune the archive over time, if wanted. MozReview-Commit-ID: EckEK1a6vA3
17435b0aedc10c2b6f4846aaeb558b1a38280b20: Bug 1124033 - Replace blanket disabling of VS2015 warnings with C5026 and C5027; r?ehsan draft
Gregory Szorc <gps@mozilla.com> - Mon, 14 Mar 2016 14:38:12 -0700 - rev 340047
Push 12893 by gszorc@mozilla.com at Mon, 14 Mar 2016 23:05:32 +0000
Bug 1124033 - Replace blanket disabling of VS2015 warnings with C5026 and C5027; r?ehsan Wv:18 was added in bug 1119072 as a quick way to get the tree building with VS2015. Now that we're closer to rolling out VS2015 support, we want to expose its new warnings. This patch replaces the blanket disabling of new warnings in VS2015 with just disabling C5026 and C5027, which relate to symbols being implicitly defined as deleted. MozReview-Commit-ID: 8uniydfNJns
(0) -300000 -100000 -30000 -10000 -3000 -1000 -300 -100 -50 -20 +20 +50 +100 +300 +1000 +3000 +10000 +30000 +100000 +300000 tip