291f380e8167d4245c3e24fe6375968e02fb635e: Bug 1411198 - Unlabeled voice input button. r=mcomella
s37syed <shah@shahsyed.me> - Mon, 14 May 2018 21:35:34 -0400 - rev 419236
Push 34031 by nbeleuzu@mozilla.com at Tue, 22 May 2018 09:47:31 +0000
Bug 1411198 - Unlabeled voice input button. r=mcomella Added contentDescription strings for QR Code and Voice Input MozReview-Commit-ID: 6tpoewhPxev
e86e1123dd47e8b3563aa09d5740d54333df8203: Bug 1458159 - Use rounding instead of ceiling on max{Ascent,Descent} for DWriteFont. r=jfkthame
Xidorn Quan <me@upsuper.org> - Tue, 22 May 2018 11:43:30 +1000 - rev 419235
Push 34031 by nbeleuzu@mozilla.com at Tue, 22 May 2018 09:47:31 +0000
Bug 1458159 - Use rounding instead of ceiling on max{Ascent,Descent} for DWriteFont. r=jfkthame The ceiling was introduced in bug 549190 for improve the consistency of underline positioning. However, removing ceiling now doesn't seem to regress the testcases in that bug, probably thanks to improvement in other part. The ceiling here causes us to have different font metrics than other browsers on Windows, and can lead to webcompat issue. We also don't do this for other backends. So it's probably better removing it in favor of rounding. There are several test changes: * min-intrinsic-with-percents-across-elements.html changes result due to height of wrapping div in reference page depends on line height, so a fixed line height is set to work around the issue. * 368020-1.html changes result because a slightly different line-height triggers bug 1462514. It is changed to use fixed line-height to work around the issue. * 456147.xul is disabled because it compares XUL against HTML page, but XUL has different approach to position text in its elements than HTML. Specifically, XUL elements don't seem to respect line height while HTML elements do. The original line height in the file was probably chosen to make the HTML match XUL, so it seems to be non-trivial to fix it in a platform-independent way. * sizing-orthog-{vlr,vrl}-in-htb-{008,020}.xht fails due to text in <p> after the testing block shifts 1px up for unknown reason. MozReview-Commit-ID: 2WJG1AigWl1
5d49624da2d588bc17d16ee5f4c3af845ea87d26: Bug 1463012 - Use Node.contains instead of isAncestorOrSelf r=mixedpuppy
Oriol Brufau <oriol-bugzilla@hotmail.com> - Tue, 15 May 2018 13:33:14 +0200 - rev 419234
Push 34031 by nbeleuzu@mozilla.com at Tue, 22 May 2018 09:47:31 +0000
Bug 1463012 - Use Node.contains instead of isAncestorOrSelf r=mixedpuppy MozReview-Commit-ID: 9lxgl5bupBF
331be24ce5e6fecb336729ba857cd2ffd5573970: Bug 1419893 - Add windowId parameter in browserAction methods r=mixedpuppy
Oriol Brufau <oriol-bugzilla@hotmail.com> - Fri, 06 Apr 2018 23:18:44 +0200 - rev 419233
Push 34031 by nbeleuzu@mozilla.com at Tue, 22 May 2018 09:47:31 +0000
Bug 1419893 - Add windowId parameter in browserAction methods r=mixedpuppy MozReview-Commit-ID: FFb4I1wmTH
de4e1b2221d7f35bd5c3fa1ea8134451f0d7a38f: Bug 1454686 - Remove Lint error suppression for unused strings; r=mcomella
Petru Lingurar <petru.lingurar@softvision.ro> - Wed, 16 May 2018 15:59:56 +0300 - rev 419232
Push 34031 by nbeleuzu@mozilla.com at Tue, 22 May 2018 09:47:31 +0000
Bug 1454686 - Remove Lint error suppression for unused strings; r=mcomella Strings needed for this feature were added in a separate bug - 1445798 which were causing Lint errors. When this feature will land there will be no need for the suppression. MozReview-Commit-ID: IhtTS8rHLwz
d21bb52a99dce11eddb59a480275a75edd5277d7: Bug 1454686 - Respond to changes in the new preference state state; r=mcomella
Petru Lingurar <petru.lingurar@softvision.ro> - Wed, 16 May 2018 15:54:13 +0300 - rev 419231
Push 34031 by nbeleuzu@mozilla.com at Tue, 22 May 2018 09:47:31 +0000
Bug 1454686 - Respond to changes in the new preference state state; r=mcomella Because Mma cannot work if Health Report is disabled by the user (Settings - Privacy) we will treat toggling Health Report on/off the same as we treat toggling the new preference from Settings - Notifications. Toggling Health Report on will inform about the need to start LeanPlum (useful if the user did not explicitly stopped LP notifications but only Health Report which in turn disabled LeanPlum also) but there are other checks made afterwards (BrowserAp() is informed about this which calls GeckoPreferences.isMmaAvailable(..)) to decide if LP can and should be enabled. Toggling any of these preferences will trigger an event caught by BrowserApp which can either - immediately initialize LeanPlum (if the toggle was off LP is not running) as it would normally do when the app first starts - stop LeanPlum reporting to servers, flush the per-session available messages and resets the LP started status so that it can be restarted in the same app session (like if the user toggles the feature again) MozReview-Commit-ID: 1SmhN0NucWW ***
c6586abb677359e0a876a6d26d897af84149c67b: Bug 1454686 - Small refactoring of Mma related methods; r=mcomella
Petru Lingurar <petru.lingurar@softvision.ro> - Thu, 17 May 2018 18:55:38 +0300 - rev 419230
Push 34031 by nbeleuzu@mozilla.com at Tue, 22 May 2018 09:47:31 +0000
Bug 1454686 - Small refactoring of Mma related methods; r=mcomella With the adding of the new preference that Mma depends on we need to have only one place where all the conditions for considering if Mma is available are checked - GeckoPreferences.isMmaAvailableAndEnabled() Added only one place from where the availability of the LP experiments should be checked as that currently involves two checks - MmaDelegate.isMmaExperimentEnabled(..) Also renamed isMmaEnabled() from MmaDelegate() and initSwitchboard from BrowserApp() to better express what those methods do. MozReview-Commit-ID: BCJqM9b5JbW ***
84312c7af401068076933a2928043be3167571ee: Bug 1454686 - MmaLeanPlumImp().stop() will now stop LP, stop showing messages and allow restart in same app session; r=mcomella
Petru Lingurar <petru.lingurar@softvision.ro> - Thu, 17 May 2018 18:45:01 +0300 - rev 419229
Push 34031 by nbeleuzu@mozilla.com at Tue, 22 May 2018 09:47:31 +0000
Bug 1454686 - MmaLeanPlumImp().stop() will now stop LP, stop showing messages and allow restart in same app session; r=mcomella According to current LP documentation there are no SDK APIs to allow users to fully stop LP: events reporting and message displaying there. After extensive testing and investigations I think I found the least intrusive way to offer that. We will use internal methods but which are public so I hope they will be supported in the future also. Nevertheless we will need to maintain this in regards to future SDK updates. MozReview-Commit-ID: Ke3HGAyCqVA ***
a371b3bb0cd60bbd82374a32bc8749230209ac6c: Bug 1454686 - Add a new preference under Settings - Notifications; r=mcomella
Petru Lingurar <petru.lingurar@softvision.ro> - Wed, 16 May 2018 11:49:35 +0300 - rev 419228
Push 34031 by nbeleuzu@mozilla.com at Tue, 22 May 2018 09:47:31 +0000
Bug 1454686 - Add a new preference under Settings - Notifications; r=mcomella The behavior of this new preference is dynamic in that: - it will be hidden if LeanPlum is not available for the device - it will be toggled off and disabled if Health Report is disabled by the user MozReview-Commit-ID: 1x9zZukyygr ***
d6f131d9d8a00d576330ae7fee1ab662d6359574: Backed out changeset 1be70a3d127f (bug 1458159) for reftest failures in sizing-orthog-vlr-in-htb-008.xht on a CLOSED TREE
Noemi Erli <nerli@mozilla.com> - Tue, 22 May 2018 04:23:47 +0300 - rev 419227
Push 34031 by nbeleuzu@mozilla.com at Tue, 22 May 2018 09:47:31 +0000
Backed out changeset 1be70a3d127f (bug 1458159) for reftest failures in sizing-orthog-vlr-in-htb-008.xht on a CLOSED TREE
5c86999026eaf01f11b1fb58e18ccae0c03c1781: Bug 1461979 - change faulty assert to warning r=dholbert
Morgan Rae Reschenberg <mreschenberg@berkeley.edu> - Mon, 21 May 2018 15:35:31 -0700 - rev 419226
Push 34031 by nbeleuzu@mozilla.com at Tue, 22 May 2018 09:47:31 +0000
Bug 1461979 - change faulty assert to warning r=dholbert MozReview-Commit-ID: 1cFN6Hk2Bdj
0ee7d4aa1799029d38c95d75eefe4a401cbd2800: Backed out changeset 98e368b5c4be (bug 1463035) for failures in tools/profiler/tests/chrome/test_profile_worker.html on a CLOSED TREE
Noemi Erli <nerli@mozilla.com> - Tue, 22 May 2018 03:16:44 +0300 - rev 419225
Push 34031 by nbeleuzu@mozilla.com at Tue, 22 May 2018 09:47:31 +0000
Backed out changeset 98e368b5c4be (bug 1463035) for failures in tools/profiler/tests/chrome/test_profile_worker.html on a CLOSED TREE
0c033165b03fe8f9b25b63f67d9d1d772f708b8f: Bug 1396839 - "Nightly Start Page" tooltip is displayed for "Home" button when Activity Stream overrides about:home. r=Felipe,flod
Ed Lee <edilee@mozilla.com> - Mon, 21 May 2018 11:41:58 -0700 - rev 419224
Push 34031 by nbeleuzu@mozilla.com at Tue, 22 May 2018 09:47:31 +0000
Bug 1396839 - "Nightly Start Page" tooltip is displayed for "Home" button when Activity Stream overrides about:home. r=Felipe,flod MozReview-Commit-ID: 8aDobXKBIg0
f4958a88bd863f9805cbf393801289df97c7afa6: Bug 1461693 - add missing params to changeInfo for tabs.onUpdated, r=rpl
Shane Caraveo <scaraveo@mozilla.com> - Mon, 21 May 2018 12:53:08 -0400 - rev 419223
Push 34031 by nbeleuzu@mozilla.com at Tue, 22 May 2018 09:47:31 +0000
Bug 1461693 - add missing params to changeInfo for tabs.onUpdated, r=rpl MozReview-Commit-ID: 1brjyYc7PwW
1be70a3d127fa7e5cfced92c29175c5f8907cb44: Bug 1458159 - Use rounding instead of ceiling on max{Ascent,Descent} for DWriteFont. r=jfkthame
Xidorn Quan <me@upsuper.org> - Tue, 01 May 2018 15:18:55 +1000 - rev 419222
Push 34031 by nbeleuzu@mozilla.com at Tue, 22 May 2018 09:47:31 +0000
Bug 1458159 - Use rounding instead of ceiling on max{Ascent,Descent} for DWriteFont. r=jfkthame The ceiling was introduced in bug 549190 for improve the consistency of underline positioning. However, removing ceiling now doesn't seem to regress the testcases in that bug, probably thanks to improvement in other part. The ceiling here causes us to have different font metrics than other browsers on Windows, and can lead to webcompat issue. We also don't do this for other backends. So it's probably better removing it in favor of rounding. There are several test changes: * min-intrinsic-with-percents-across-elements.html changes result due to height of wrapping div in reference page depends on line height, so a fixed line height is set to work around the issue. * 368020-1.html changes result because a slightly different line-height triggers bug 1462514. It is changed to use fixed line-height to work around the issue. * 456147.xul is disabled because it compares XUL against HTML page, but XUL has different approach to position text in its elements than HTML. Specifically, XUL elements don't seem to respect line height while HTML elements do. The original line height in the file was probably chosen to make the HTML match XUL, so it seems to be non-trivial to fix it in a platform-independent way. * sizing-orthog-{vlr,vrl}-in-htb-{008,020}.xht fails due to text in <p> after the testing block shifts 1px up for unknown reason. MozReview-Commit-ID: 2WJG1AigWl1
9c10d9a7198331b7a650cef79ed37f36d23a2c88: Bug 1176019 - Don't let cache interfere with tab warming r=mconley
Doug Thayer <dothayer@mozilla.com> - Tue, 15 May 2018 09:31:13 -0700 - rev 419221
Push 34031 by nbeleuzu@mozilla.com at Tue, 22 May 2018 09:47:31 +0000
Bug 1176019 - Don't let cache interfere with tab warming r=mconley While working to reproduce the stale content bug with tab warming I realized that my work here had inadvertently clobbered tab warming by immediately calling the tab unload code. This wasn't necessary, and I didn't need to put the cached tab deactivation code in the unload method, it just seemed initially convenient. This should make more sense overall. MozReview-Commit-ID: 9v9dYZTa1Dv
94bfb6800a01efd5560ad29dc2e770ced662c70b: Bug 1176019 - Clear cached layers on location change r=mconley
Doug Thayer <dothayer@mozilla.com> - Tue, 15 May 2018 09:29:16 -0700 - rev 419220
Push 34031 by nbeleuzu@mozilla.com at Tue, 22 May 2018 09:47:31 +0000
Bug 1176019 - Clear cached layers on location change r=mconley To avoid a flash of stale content in the event of a slow tab switch, we need to make sure we remove a tab from the cache if its location changes while it's in the background. MozReview-Commit-ID: ElpoWhhjb0n
27f6f789b1940eaaad96223fac928ca2bb371dd7: Bug 1176019 - Force a paint when switching to a loaded tab r=mconley
Doug Thayer <dothayer@mozilla.com> - Mon, 14 May 2018 23:45:00 -0700 - rev 419219
Push 34031 by nbeleuzu@mozilla.com at Tue, 22 May 2018 09:47:31 +0000
Bug 1176019 - Force a paint when switching to a loaded tab r=mconley This is fairly straightforward, other than the fact that the nomenclature gets a bit awkward with the aForce parameter on the ForcePaint methods. I'm not sure which direction to go with this - "aForce" seems a fairly intuitive name for what we want, and I'm kind of inclined to say the existing ForcePaint mechanic should be renamed to something like PaintWithInterrupt, or PaintWithPriority. MozReview-Commit-ID: Bj9DROug1pC
dd85a2be4527c4dfaff44280d26bec7e8ffc7bd8: Bug 1176019 - Fix browser_tabswitchbetweenplugins.js r=mconley
Doug Thayer <dothayer@mozilla.com> - Tue, 08 May 2018 15:26:15 -0700 - rev 419218
Push 34031 by nbeleuzu@mozilla.com at Tue, 22 May 2018 09:47:31 +0000
Bug 1176019 - Fix browser_tabswitchbetweenplugins.js r=mconley After digging into this, I'm still not entirely sure why the timing has changed such that the checks don't work immediately. I have a strong suspicion though that it's simply because our tab switch is now instant, resulting in the necessary messages just being a little bit behind. Hopefully this is an acceptable bandaid. MozReview-Commit-ID: H1wKW1UQBxp
8ff26293b8985c7aaee637cd174f2f0fcbc2d352: Bug 1176019 - Fix browser_bug1196539.js painting check r=mconley
Doug Thayer <dothayer@mozilla.com> - Tue, 08 May 2018 09:49:24 -0700 - rev 419217
Push 34031 by nbeleuzu@mozilla.com at Tue, 22 May 2018 09:47:31 +0000
Bug 1176019 - Fix browser_bug1196539.js painting check r=mconley MozReview-Commit-ID: HgzcSIdIh1h
(0) -300000 -100000 -30000 -10000 -3000 -1000 -300 -100 -50 -20 +20 +50 +100 +300 +1000 +3000 +10000 +30000 +100000 tip