5d0904a71fa8e6371ab6f564415480905cf9127b: Backed out changeset a94ec6a0d746 (bug 1386955) for build bustage CLOSED TREE UPGRADE_NSS_RELEASE
Franziskus Kiefer <franziskuskiefer@gmail.com> - Tue, 05 Sep 2017 12:42:00 +0200 - rev 659168
Push 78047 by bmo:francesco.lodolo@gmail.com at Tue, 05 Sep 2017 17:25:17 +0000
Backed out changeset a94ec6a0d746 (bug 1386955) for build bustage CLOSED TREE UPGRADE_NSS_RELEASE MozReview-Commit-ID: 8bFoSz1zPWu
9e03d843a3ab55262828eac2b1a3574adf77ba24: merge mozilla-central to mozilla-inbound. r=merge a=merge
Sebastian Hengst <archaeopteryx@coole-files.de> - Tue, 05 Sep 2017 12:38:47 +0200 - rev 659167
Push 78047 by bmo:francesco.lodolo@gmail.com at Tue, 05 Sep 2017 17:25:17 +0000
merge mozilla-central to mozilla-inbound. r=merge a=merge
a94ec6a0d746f466becf71d31b345eb36694c17a: Bug 1386955 - land NSS 4bf658832d89 UPGRADE_NSS_RELEASE, r=me
Franziskus Kiefer <franziskuskiefer@gmail.com> - Tue, 05 Sep 2017 12:28:53 +0200 - rev 659166
Push 78047 by bmo:francesco.lodolo@gmail.com at Tue, 05 Sep 2017 17:25:17 +0000
Bug 1386955 - land NSS 4bf658832d89 UPGRADE_NSS_RELEASE, r=me MozReview-Commit-ID: 1UXz41NnFtD
cabfaf23bfe23ce6db00012900b57ee3126bf5bd: bug 1396137 - update broken fips pkcs#11 module db handling code for when we use the sqlite-backed databses r?jcj draft
David Keeler <dkeeler@mozilla.com> - Fri, 01 Sep 2017 15:54:40 -0700 - rev 659165
Push 78046 by bmo:dkeeler@mozilla.com at Tue, 05 Sep 2017 17:12:33 +0000
bug 1396137 - update broken fips pkcs#11 module db handling code for when we use the sqlite-backed databses r?jcj This handles the different error code returned by NSS and that the pkcs#11 module db has a different filename. MozReview-Commit-ID: HJK4zsf6IS0
e3d9c852a8410beb6c606e4fc2febab6a76590dc: Bug 1339610 - Web extension API for container icon and colors. r?baku r?kmag draft
Jonathan Kingston <jkt@mozilla.com> - Sun, 27 Aug 2017 00:47:02 +0100 - rev 659164
Push 78045 by bmo:jkt@mozilla.com at Tue, 05 Sep 2017 17:09:24 +0000
Bug 1339610 - Web extension API for container icon and colors. r?baku r?kmag MozReview-Commit-ID: BosKoxM8FMZ
4abca9ea6f89edba823669e4b2343c1345b820d1: Bug 1396731 - Make the default font size for zh same as other languages. r?jfkthame draft 12-1396731
Kevin Hsieh <kevin.hsieh@ucla.edu> - Tue, 05 Sep 2017 10:00:42 -0700 - rev 659163
Push 78044 by bmo:kevin.hsieh@ucla.edu at Tue, 05 Sep 2017 17:07:58 +0000
Bug 1396731 - Make the default font size for zh same as other languages. r?jfkthame MozReview-Commit-ID: A4U38BXwLk0
e101637a594efcafc2a348f814d406eb29016161: Bug 1339610 - Web extension API for container icon and colors. r?baku r?kmag draft
Jonathan Kingston <jkt@mozilla.com> - Sun, 27 Aug 2017 00:47:02 +0100 - rev 659162
Push 78043 by bmo:jkt@mozilla.com at Tue, 05 Sep 2017 17:01:57 +0000
Bug 1339610 - Web extension API for container icon and colors. r?baku r?kmag MozReview-Commit-ID: BosKoxM8FMZ
46008bf2123f2d9c0aa4ce23f1dc20c0dc89a3f2: Bug 1271998 - Part 4 - Use a touch delegate to increase the clickable area of the URL bar. r?walkingice,jwu draft
Jan Henning <jh+bugzilla@buttercookie.de> - Tue, 29 Aug 2017 20:34:17 +0200 - rev 659161
Push 78042 by mozilla@buttercookie.de at Tue, 05 Sep 2017 17:01:51 +0000
Bug 1271998 - Part 4 - Use a touch delegate to increase the clickable area of the URL bar. r?walkingice,jwu Originally, the listeners that trigger editing mode and the URL bar's context menu were attached to the BrowserToolbar itself. As this doesn't work properly in conjunction with wrapping the URL TextView into a ScrollView, the listeners were moved onto the TextView itself. Bug 1389164 reduced the height of the TextView in order to better support lightweight themes with the new toolbar design, which in conjunction with the changes to support the ScrollView has the unfortunate side effect of also reducing the URL bar's hit target area. Therefore, we increase it back to its old levels by using a TouchDelegate on the ScrollView. Because Android's ScrollView implementation doesn't support TouchDelegates, we have to add the missing bits of logic back in from the default View implementation. MozReview-Commit-ID: 1nTrrNGvBza
f75bc152eacbcc5aea590e65f28eccbbe9ebdb39: Bug 1271998 - Part 3 - Scroll the URL to focus the origin for overlength URLs. r?walkingice,jwu draft
Jan Henning <jh+bugzilla@buttercookie.de> - Thu, 24 Aug 2017 22:09:56 +0200 - rev 659160
Push 78042 by mozilla@buttercookie.de at Tue, 05 Sep 2017 17:01:51 +0000
Bug 1271998 - Part 3 - Scroll the URL to focus the origin for overlength URLs. r?walkingice,jwu If the domain is long enough that it doesn't fully fit within the URL bar, we scroll it such that the end of the domain aligns with the right side of the URL bar, taking any possible fadingEdge effect into account. That way, we always try to show as much of the most important part of the origin as possible. Chrome uses a similar approach, although their URL bar neither fades nor allows scrolling. MozReview-Commit-ID: Ep4H4kO4MRH
8e3f6bfaf5b45ad0c1b1b31e346226dcca5a164c: Bug 1271998 - Part 2 - Make our URL bar scrollable. r?walkingice,jwu draft
Jan Henning <jh+bugzilla@buttercookie.de> - Sun, 27 Aug 2017 17:31:13 +0200 - rev 659159
Push 78042 by mozilla@buttercookie.de at Tue, 05 Sep 2017 17:01:51 +0000
Bug 1271998 - Part 2 - Make our URL bar scrollable. r?walkingice,jwu Limited space for URLs on mobile browsers has given rise to a class of phishing attacks that rely on a carefully crafted URL with a long subdomain being cut off such as to give the impression of another, legitimate URL [1]. We've experimented in the past with avoiding this by showing only the base domain or the EV certificate owner, but had to revert to the old behaviour because of users complaining about not being able to see as much of the URL as formerly possible. Making the displayed URL scrollable is therefore a nice solution: It allows us to choose the initial scroll position such as to put the focus on the base domain, while giving users the freedom to easily view all the rest of the URL without having to enter editing mode. To make the URL scrollable, we wrap the TextView with a HorizontalScrollView. Alternatively, it would have been possible to use a ScrollingMovementMethod with the TextView, however that way - flinging the text doesn't work out of the box - dragging the text around is still detected as a normal long-press as well and triggers the context menu [1]. E.g. https://manage-myaccount.paypal.com-webapps.verifcheck.com/signin/ (see https://twitter.com/ericlaw/status/900429796240277504 for an example screenshot). MozReview-Commit-ID: LPEXQA2kBvD
2f632c71336a048e2d6f695af3823e6765b9451c: Bug 1271998 - Part 1 - Provide a ScrollView with a more efficient fadingEdge implementation. r?walkingice,jwu draft
Jan Henning <jh+bugzilla@buttercookie.de> - Thu, 31 Aug 2017 20:06:33 +0200 - rev 659158
Push 78042 by mozilla@buttercookie.de at Tue, 05 Sep 2017 17:01:51 +0000
Bug 1271998 - Part 1 - Provide a ScrollView with a more efficient fadingEdge implementation. r?walkingice,jwu Our previous iteration of a more efficient fadingEdge implementation in FadedMultiColorTextView works by blending the text with a chosen colour. By choosing the same colour as the parent view onto which the TextView is placed, it was thus possible to achieve the impression of fading. With our new URL bar design this is no longer possible quite as easily, since the image used for a lightweight theme will now be displayed behind the URL itself as well. Since the implementation would have also needed more work to make it compatible with scrolling text or being placed in a ScrollView anyway, the fading effect is now achieved directly via the ScrollView instead. Android's built-in fadingEdge implementation calls Canvas.saveLayer (with CLIP_TO_LAYER_SAVE_FLAG omitted!) during a View's onDraw in order to fade out the contents of its children while preserving the background provided by its parents. This saveLayer call is rather expensive and is quite noticeable on a GPU profile even today. Therefore, we implement a more efficient variety of fadingEdges that paints over its children's content in onDrawForeground. To avoid any background content from being faded out, the whole view then has to be placed on a separate layer, however this is still much more efficient than calling Canvas.saveLayer and doesn't show up noticeably in a GPU profile. Prior to Marshmallow, onDrawForeground is not available, so we have to override draw instead in order to be able to paint over the content drawn by the ScrollView's descendants. This means that e.g. scrollbars would be faded out as well, but as we don't intend on showing a scrollbar within the context of this bug, it is an acceptable compromise. MozReview-Commit-ID: DCDPt6ogs0h
95e067280295699d843e324107ccb61b39672c3e: Bug 1271998 - Part 0 - Clean up imports. r? draft
Jan Henning <jh+bugzilla@buttercookie.de> - Sun, 27 Aug 2017 19:58:16 +0200 - rev 659157
Push 78042 by mozilla@buttercookie.de at Tue, 05 Sep 2017 17:01:51 +0000
Bug 1271998 - Part 0 - Clean up imports. r? MozReview-Commit-ID: 5y5C77jFYUg
0fe55f177532ffdafb2729754cbcd8ac13258613: Bug 1382440 - Fix CPUUsageWatcher on OSX and Linux r?froydnj draft
Doug Thayer <dothayer@mozilla.com> - Mon, 28 Aug 2017 14:00:22 -0700 - rev 659156
Push 78041 by bmo:dothayer@mozilla.com at Tue, 05 Sep 2017 16:37:07 +0000
Bug 1382440 - Fix CPUUsageWatcher on OSX and Linux r?froydnj Properly enclose all relevant details of CPUUsageWatcher in ifdefs which control whether it should be active or not. Additionally, apparently clock_gettime is not defined on OSX prior to 10.12, so this is failing to compile for OSX on the build server, but not locally. However, clock_get_time and getrusage should cover our use cases sufficiently. MozReview-Commit-ID: Ffi6yXLb9gO
dbf5cc906c7bfecdf94fdd715c1bc8fd2c437fd6: Bug 1382440 - Fix CPUUsageWatcher on OSX and Linux draft
Doug Thayer <dothayer@mozilla.com> - Mon, 28 Aug 2017 14:00:22 -0700 - rev 659155
Push 78040 by bmo:dothayer@mozilla.com at Tue, 05 Sep 2017 16:36:21 +0000
Bug 1382440 - Fix CPUUsageWatcher on OSX and Linux Properly enclose all relevant details of CPUUsageWatcher in ifdefs which control whether it should be active or not. Additionally, apparently clock_gettime is not defined on OSX prior to 10.12, so this is failing to compile for OSX on the build server, but not locally. However, clock_get_time and getrusage should cover our use cases sufficiently. MozReview-Commit-ID: Ffi6yXLb9gO
6f7151d2f5e56f9fe517b268dd56dde3755e524d: Bug 1382440 - Watch CPU usage in BHR r?froydnj draft
Doug Thayer <dothayer@mozilla.com> - Mon, 24 Jul 2017 13:46:09 -0700 - rev 659154
Push 78040 by bmo:dothayer@mozilla.com at Tue, 05 Sep 2017 16:36:21 +0000
Bug 1382440 - Watch CPU usage in BHR r?froydnj We would like to be able to see if a given hang in BHR occurred under high CPU load, as this is an indication that the hang is of less use to us, since it's likely that the external CPU use is more responsible for it. The way this works is fairly simple. We get the system CPU usage on a scale from 0 to 1, and we get the current process's CPU usage, also on a scale from 0 to 1, and we subtract the latter from the former. We then compare this value to a threshold, which is 1 - (1 / p), where p is the number of (virtual) cores on the machine. This threshold might need to be tuned, so that we require an entire physical core in order to not annotate the hang, but for now it seemed the most reasonable line in the sand. I should note that this considers CPU usage in child or parent processes as external. While we are responsible for that CPU usage, it still indicates that the stack we receive from BHR is of little value to us, since the source of the actual hang is external to that stack. MozReview-Commit-ID: JkG53zq1MdY
116e33a724953227e63f36f92b7f2e479f311d37: Bug 1396539 - Wait correctly for inspector load before resolving toolbox-ready. r=pbro draft
Alexandre Poirot <poirot.alex@gmail.com> - Tue, 05 Sep 2017 11:31:01 +0200 - rev 659153
Push 78039 by bmo:poirot.alex@gmail.com at Tue, 05 Sep 2017 16:22:38 +0000
Bug 1396539 - Wait correctly for inspector load before resolving toolbox-ready. r=pbro MozReview-Commit-ID: GP3O1NZqVEE
71b61ce9934a237bea01709d5b2629b04b51e1fd: Bug 1396589 - Remove unsupported API call for lower versions. r=liuche draft
Chenxia Liu <liuche@mozilla.com> - Tue, 05 Sep 2017 09:14:37 -0700 - rev 659152
Push 78038 by cliu@mozilla.com at Tue, 05 Sep 2017 16:21:48 +0000
Bug 1396589 - Remove unsupported API call for lower versions. r=liuche MozReview-Commit-ID: H1oSMcM6BCD
1f85bcaa851c6339e2bc7caa809584ec0358ede5: Bug 1396589 - Remove unsupported API call for lower versions. r=liuche draft
Chenxia Liu <liuche@mozilla.com> - Tue, 05 Sep 2017 09:14:37 -0700 - rev 659151
Push 78037 by cliu@mozilla.com at Tue, 05 Sep 2017 16:15:24 +0000
Bug 1396589 - Remove unsupported API call for lower versions. r=liuche MozReview-Commit-ID: H1oSMcM6BCD
45e821cb35601ebdd68808cf7ee652316fedc7ae: Bug 1396838 - Remove window state from wdpsec tests. r?jgraham draft
Andreas Tolfsen <ato@sny.no> - Tue, 05 Sep 2017 17:02:41 +0100 - rev 659150
Push 78036 by bmo:ato@sny.no at Tue, 05 Sep 2017 16:03:44 +0000
Bug 1396838 - Remove window state from wdpsec tests. r?jgraham MozReview-Commit-ID: 7zogEgoABnV
f53bd977b83a3fd75d9a9deb5ab1c96f9c528638: Bug 1396838 - Set window rect before every test. r?jgraham draft
Andreas Tolfsen <ato@sny.no> - Tue, 05 Sep 2017 17:01:05 +0100 - rev 659149
Push 78036 by bmo:ato@sny.no at Tue, 05 Sep 2017 16:03:44 +0000
Bug 1396838 - Set window rect before every test. r?jgraham There are DOM attributes to query a window's minimized and fullscreen states, but there is no reliable way to tell if the window is maximized. To workaround this, we set the window's size before every test to ensure it transitioned to the normal window state. MozReview-Commit-ID: DAT0E4rhmjY
(0) -300000 -100000 -30000 -10000 -3000 -1000 -300 -100 -50 -20 +20 +50 +100 +300 +1000 +3000 +10000 +30000 +100000 tip