If an imgCacheValidator object is destroyed without calling
imgCacheValidator::OnStartRequest, or imgRequest::Init fails in
OnStartRequest, we left the bound proxies hanging on an update. Now we
cancel the new request, and bind the validating proxies to said request
to ensure their listeners fail gracefully.
The previous commit moved creating installers to be side effect of creating
packages. This makes the installer step not actually do anything. So remove the
step from automation.
Differential Revision: https://phabricator.services.mozilla.com/D864
--HG--
extra : rebase_source : 75b67a6e57031ae189dafe1d9854e4105aa22621
extra : source : fcb756834abbdbe0ae6e59a8cfdf39024f50a226
The uninstaller was being built as a side-effect of building `setup.exe`. In
Bug 1385227, that was moved from "somewhere" to part of the windows installer
packaging, which happens after the zip and mar are generated. Since the
installer we ship is actually repackaged from the zip[1], we stopped shipping
translated uninstallers.
This changes things around so that the uninstaller gets translated:
- Explicitly build the uninstaller as part of the L10n repack step.
- Use the same logic to build the installer locally as we do to create the ones
we ship.
[1] Except on Thunderbird
Differential Revision: https://phabricator.services.mozilla.com/D672
--HG--
extra : rebase_source : 05fe935c1d2a9fbfeef786819bfe5913ed8ef862
extra : source : d6bf22099e2195dcb64c3c3d7700d3edd0850a3a
We now vendor pip via the vendored copy of virtualenv. Stop trying to install a
specific version of pip elsewhere, particularly stop downgrading it.
Differential Revision: https://phabricator.services.mozilla.com/D962
--HG--
extra : rebase_source : 1788809942aff772c57d675db2631f72bbf2b8c9
The previous commit moved creating installers to be side effect of creating
packages. This makes the installer step not actually do anything. So remove the
step from automation.
Differential Revision: https://phabricator.services.mozilla.com/D864
--HG--
extra : rebase_source : 174a366890da295634ef8971d0608ea60979f110
extra : histedit_source : 06fdd0e2ccb93f061ba5a40c2a4137eed9898916
The uninstaller was being built as a side-effect of building `setup.exe`. In
Bug 1385227, that was moved from "somewhere" to part of the windows installer
packaging, which happens after the zip and mar are generated. Since the
installer we ship is actually repackaged from the zip[1], we stopped shipping
translated uninstallers.
This changes things around so that the uninstaller gets translated:
- Explicitly build the uninstaller as part of the L10n repack step.
- Use the same logic to build the installer locally as we do to create the ones
we ship.
[1] Except on Thunderbird
Differential Revision: https://phabricator.services.mozilla.com/D672
--HG--
extra : rebase_source : 2b28b9ff7196d12f4a188c8dddf750b9a5efac5b
extra : histedit_source : 9bc28891950ae8c226cfdefef6f8121ce0b51f58
The previous implementation treated any zero coordinate as pixels,
regardless of its unit type. For example, 0% would be converted to 0px.
This changed the shape value resulting in unintentional unit mismatch
after editing a coordinate which started off as 0% or 0em or 0vh, etc.
This patch fixes that and preserves the unit type for zero coordinates.
It changes the implementation of isUnitless() to return false for values
like 0%, 0px, 0em, 0.00000%, etc.
It introduces getUnitToPixelRatio() to get the ratio by which to
multiply a pixel value to convert it to the given unit during shape
editing operations (point move, scale, translate, rotate, etc.)
The ratio is constant by unit type. Previously, this ratio was
calculated in-place for each unit value. Values which started as zero,
always resulted in a ratio equal to zero. This multiplied with a pixel
value resulted zero. So the previous code defaulted to ratio of 1 when
the ratio was zero, but this meant that a 1:1 ratio between pixels and
another unit type (%, em, vh) would result in disproportionate
shape changes (1px of mouse travel would result in 1em). This is why
isUnitless() originally discarded the original unit from a zero
coordinate and replaced it with pixels; to account for this fallback
ratio of 1.
MozReview-Commit-ID: 49tyLfYjkLO
This hard codes the visual studio version to 2015. We did the same thing for the
gyp build. It also sets default paths for visual studio, which are ignored by the
remainder of the build system.
This was required to get gn code generation working on a fresh install of
Windows. I must have had similar changes on my old Windows VM but missed
commiting them as part of the gyp to gn build switch.
MozReview-Commit-ID: 7fYngpdIwxh
--HG--
extra : rebase_source : de24b50f8e19465d8c145ce96c31d4ad7cc52e57
...on Windows, at least. Apparently if you have environment variables
set that contain multibyte characters, and ask for them with getenv, you
get garbage. Or perhaps you get something sensible, but then passing it
to fopen produces garbage. Either way, the most reasonable way to
handle this is to use the Windows wide-character APIs all over.
