7a7064a1e6a935da858cd6d48b713adc3ee84bc8: Bug 1406087: All PingCentre pings should go to production by default. draft
Marina Samuel <msamuel@mozilla.com> - Thu, 05 Oct 2017 11:12:17 -0400 - rev 675559
Push 83174 by bmo:msamuel@mozilla.com at Thu, 05 Oct 2017 15:13:51 +0000
Bug 1406087: All PingCentre pings should go to production by default. MozReview-Commit-ID: 9ZmAG9fBWqX
21653fe97c4ea16fb9f3075fbc00f5a40aafbd27: All PingCentre pings should go to production by default. draft
Marina Samuel <msamuel@mozilla.com> - Thu, 05 Oct 2017 11:12:17 -0400 - rev 675558
Push 83173 by bmo:msamuel@mozilla.com at Thu, 05 Oct 2017 15:12:55 +0000
All PingCentre pings should go to production by default. MozReview-Commit-ID: 9ZmAG9fBWqX
3c79e0c7f49e7f7239300ad833e15f1847dab39a: Bug 1399886 - use photon colors for highlighted devtools toolbar icons;r=gl draft
Julian Descottes <jdescottes@mozilla.com> - Thu, 05 Oct 2017 17:07:24 +0200 - rev 675557
Push 83172 by jdescottes@mozilla.com at Thu, 05 Oct 2017 15:07:58 +0000
Bug 1399886 - use photon colors for highlighted devtools toolbar icons;r=gl MozReview-Commit-ID: LCEArSoizyk
183c0e03a22917c3e4ea3b8631ab998f61ffa106: Bug 1406085 - Only consider array indices to be indexed properties. draft
Oriol Brufau <oriol-bugzilla@hotmail.com> - Thu, 05 Oct 2017 17:03:07 +0200 - rev 675556
Push 83171 by bmo:oriol-bugzilla@hotmail.com at Thu, 05 Oct 2017 15:03:31 +0000
Bug 1406085 - Only consider array indices to be indexed properties. MozReview-Commit-ID: AEH4BeFunxh
65aba6b36b9fb6d3fa8f281454827a693bc26b36: Bug 1404495 - Back out changeset 3e7cd55f6cb9 to go back to different colors for connecting and loading on unselected tabs. r?mconley draft
Jared Wein <jwein@mozilla.com> - Thu, 05 Oct 2017 11:00:37 -0400 - rev 675555
Push 83170 by bmo:jaws@mozilla.com at Thu, 05 Oct 2017 15:01:08 +0000
Bug 1404495 - Back out changeset 3e7cd55f6cb9 to go back to different colors for connecting and loading on unselected tabs. r?mconley MozReview-Commit-ID: JTVjsavmob6
554cd7fe7479c2cad7a3e246280eaf611a8c59f1: Bug 143038 Make users can scroll contents horizontally with vertical wheel operation with a modifier r?smaug draft
Masayuki Nakano <masayuki@d-toybox.com> - Thu, 05 Oct 2017 01:12:35 +0900 - rev 675554
Push 83169 by masayuki@d-toybox.com at Thu, 05 Oct 2017 15:01:00 +0000
Bug 143038 Make users can scroll contents horizontally with vertical wheel operation with a modifier r?smaug This patch declares a new pref, "mousewheel.modifier_to_treat_vertical_wheel_as_horizontal_scroll", this takes a keycode of modifier keys as its value. The default value is 16 (NS_VK_SHIFT) on Windows, Linux and Android and 0 (meaning disabled) on macOS. The reason why this new feature is disabled on macOS is, if user turns vertical wheel of mice with Shift key, macOS notifies us of horizontal scroll events. So, we don't need to care this feature by ourselves on macOS. If a modifier keycode is specified to the pref as expected, EventStateManager and EventStateManager::WheelPrefs treats vertical wheel operation as horizontal scroll when coming wheel event without the modifier causes scroll. In such case, EventStateManager::WheelPrefs::NeedToTreatAsHorizontalScroll() returns true. Otherwise, false. If this returns true, default action handler of wheel events such as EventStateManager::PostHandleEvent() and IAPZCTreeManager::ReceiveInputEvent() swaps deltaX values and deltaY values of coming wheel event temporarily and restore them. AutoTemporarilyWheelDeltaSwapper in WheelHandlingHelper guarantees this restoring. So, this patch does NOT change any wheel event information on web apps. Only changes its default action. This is same behavior as Chromium. Note that with this patch, users cannot navigate the tab's history with Shift + vertical-wheel in the default settings. However, I guess that the usage of this feature is less than the number of users who wants to scroll contents horizontally with vertical mouse wheel. Of course, Shift + horizontal-wheel is available for navigating tab's history even after this change. MozReview-Commit-ID: E4X3yZzLEAl
be1c8cdd429ef4a7afcf6dbe491958e78a84ff2d: Bug 1390562 - part 1: HTML editor shouldn't split <div> container at inserting a line break for backward compatibility if defaultParagraphSeparator is "br" r?m_kato draft
Masayuki Nakano <masayuki@d-toybox.com> - Tue, 03 Oct 2017 19:36:39 +0900 - rev 675553
Push 83169 by masayuki@d-toybox.com at Thu, 05 Oct 2017 15:01:00 +0000
Bug 1390562 - part 1: HTML editor shouldn't split <div> container at inserting a line break for backward compatibility if defaultParagraphSeparator is "br" r?m_kato Starting from bug 1297414, HTMLEditor treats <div> container as same as <p> container at inserting a line break. This new behavior is check in WPT. So, it's better to use the new behavior for compatibility with other browsers. However, we're still using <br> as default paragraph separator for backward compatibility even though this is non-standard behavior. So, although, the old behavior is odd, we should keep treating them differently in the backward compatibility mode. Actually, this behavior change causes an incompatibility problem in Gmail, and may be in other web apps. MozReview-Commit-ID: INCihKYmcPd
5b5686c3dfe949b416feb8e768a9c1746da69097: Bug 1390562 - part 0: Add automated tests r?m_kato draft
Masayuki Nakano <masayuki@d-toybox.com> - Tue, 03 Oct 2017 18:33:40 +0900 - rev 675552
Push 83169 by masayuki@d-toybox.com at Thu, 05 Oct 2017 15:01:00 +0000
Bug 1390562 - part 0: Add automated tests r?m_kato MozReview-Commit-ID: 7cgxdWClOBQ
1af91017b9193d3880bc5153ba33a3ab6db84e24: Bug 1404206 - part 3: Make GeckoInputConnection handle "mozAwesomebar" inputmode value as "url" r?jchen, gijs draft
Masayuki Nakano <masayuki@d-toybox.com> - Fri, 29 Sep 2017 16:11:20 +0900 - rev 675551
Push 83169 by masayuki@d-toybox.com at Thu, 05 Oct 2017 15:01:00 +0000
Bug 1404206 - part 3: Make GeckoInputConnection handle "mozAwesomebar" inputmode value as "url" r?jchen, gijs Although, Firefox for Android doesn't use urlbarBindings.xml for declaring its awesome bar, for consistency with widget code for desktop OSes, GeckoInputConnection should treat "mozAwesomebar" inputmode value as "url" since Android doesn't have any special input type for "search" and we should keep current behavior. MozReview-Commit-ID: DpUnUx4E2Sp
c9e2e1eca4fdb6c3a56c1dfa90725b2c33f7700d: Bug 1404206 - part 2: Make TSFTextStore and IMEHandler handle "mozAwesomebar" inputmode value r?m_kato, gijs draft
Masayuki Nakano <masayuki@d-toybox.com> - Fri, 29 Sep 2017 15:15:14 +0900 - rev 675550
Push 83169 by masayuki@d-toybox.com at Thu, 05 Oct 2017 15:01:00 +0000
Bug 1404206 - part 2: Make TSFTextStore and IMEHandler handle "mozAwesomebar" inputmode value r?m_kato, gijs When "mozAwesomebar" is set to inputmode value, that means that the Smart Location Bar gets focus. In that case, we should notify IME of input scopes as "URL" because on-screen keyboard for URL has some useful additional keys but they are not hindrances even when users want to type non-URL text. On the other hand, MS-IME for Japanese and Google Japanese Input changes their open state to "closed" if we notify them of URL input scope. A lot of users complain about this behavior. Therefore, we should notify only them of "Default" input scope even when "mozAwesomebar" has focus. MozReview-Commit-ID: DIgqpR7TXQx
213cd828a7f444a3b2e82c5e30f8beaed57c0216: Bug 1404206 - part 1: Smart Location Bar should have special inputmode value, mozAwesomebar r?smaug, gijs draft
Masayuki Nakano <masayuki@d-toybox.com> - Fri, 29 Sep 2017 14:44:06 +0900 - rev 675549
Push 83169 by masayuki@d-toybox.com at Thu, 05 Oct 2017 15:01:00 +0000
Bug 1404206 - part 1: Smart Location Bar should have special inputmode value, mozAwesomebar r?smaug, gijs Smart Location Bar (a.k.a URL bar) has some features, loading inputted URL directly, searching bookmark items and history items, and search inputted words with registered search engine. So, it does not make sense its inputmode is "url". E.g., neither showing URL specific software keyboard nor switching IME open state automatically for typing URL may not be expected in most cases. Unfortunately, there is no proper inputmode value for Smart Location Bar. Therefore, this patch uses "mozAwesomebar" value and accepts the value only in chrome documents. This value should be handled by each native IME handler properly. MozReview-Commit-ID: 7vUnbpg91F2
8f330fb0cf281d518d5c457a49392551ffe1a21e: Bug 1390313 - Item added to the overflow menu should scale down and fade out. ui-r=epang r?Gijs draft
Erica Wright <ewright@mozilla.com> - Mon, 18 Sep 2017 16:15:24 -0400 - rev 675548
Push 83168 by bmo:ewright@mozilla.com at Thu, 05 Oct 2017 14:47:27 +0000
Bug 1390313 - Item added to the overflow menu should scale down and fade out. ui-r=epang r?Gijs MozReview-Commit-ID: 5PxydbSfhpz
8787e33dca5a64daf048836d0d0263b907453258: Bug 1405720 - ensure only 1 theme is ever shown as selected in customize mode, r?johannh,jaws draft
Gijs Kruitbosch <gijskruitbosch@gmail.com> - Thu, 05 Oct 2017 15:17:12 +0100 - rev 675547
Push 83167 by gijskruitbosch@gmail.com at Thu, 05 Oct 2017 14:46:46 +0000
Bug 1405720 - ensure only 1 theme is ever shown as selected in customize mode, r?johannh,jaws The previous code here always set the `isActive` property on all themes. When writing the patch for bug 1402981 I ran into issues because the default theme has an `isActive` property anyway (it's a different type of object). So I tried to avoid setting `isActive` if it was already present. Unfortunately, the result was that `isActive` values, once set, weren't correctly updated. Worse, these values are (and were, prior to bug 1402981) serialized into prefs. There's no point serializing these values, all that will happen is that they'll start mismatching the 'real' state of the world (LightweightThemeManager.currentTheme). So instead, let's just not set the `isActive` property at all, and rely solely on the ID of the current theme (or the default theme's ID, now that we no longer support non-lightweight-themes) to establish whether any of the themes should appear selected or not. MozReview-Commit-ID: 7rajS71FoQR
1f4eb06f4eec3acedc0f195dcccaec8b91d569f1: Bug 1405927 - Change PushGlyphs to take webrender formats. r?jrmuizel draft
Alexis Beingessner <a.beingessner@gmail.com> - Wed, 04 Oct 2017 13:49:51 -0400 - rev 675546
Push 83166 by bmo:a.beingessner@gmail.com at Thu, 05 Oct 2017 14:40:35 +0000
Bug 1405927 - Change PushGlyphs to take webrender formats. r?jrmuizel Also cleans up a bunch of TextDrawTarget code as fallout. This is a significant perf win for textFrames. MozReview-Commit-ID: J1BDkXZdvnc
0a7258499ba010ad1f28bbe634f8fd2f3782ced8: Bug 1405927 - Remove TextLayer support from nsDisplayText. r?mattwoodrow draft
Alexis Beingessner <a.beingessner@gmail.com> - Wed, 04 Oct 2017 13:49:51 -0400 - rev 675545
Push 83166 by bmo:a.beingessner@gmail.com at Thu, 05 Oct 2017 14:40:35 +0000
Bug 1405927 - Remove TextLayer support from nsDisplayText. r?mattwoodrow MozReview-Commit-ID: J1BDkXZdvnc
7b84fcc99ee6728988137081389f13c714d19b24: Bug 1390313 - Item added to the overflow menu should scale down and fade out. ui-r=epang r?Gijs draft
Erica Wright <ewright@mozilla.com> - Mon, 18 Sep 2017 16:15:24 -0400 - rev 675544
Push 83165 by bmo:ewright@mozilla.com at Thu, 05 Oct 2017 14:27:58 +0000
Bug 1390313 - Item added to the overflow menu should scale down and fade out. ui-r=epang r?Gijs MozReview-Commit-ID: 5PxydbSfhpz
dd5d097168b8a3aa3e194d3d31e0ac48e3c06f64: Bug 1405349 - [reftest] Refactor manifest parsing from reftest.jsm to standalone module draft
Andrew Halberstadt <ahalberstadt@mozilla.com> - Mon, 02 Oct 2017 12:03:43 -0400 - rev 675543
Push 83164 by ahalberstadt@mozilla.com at Thu, 05 Oct 2017 14:14:31 +0000
Bug 1405349 - [reftest] Refactor manifest parsing from reftest.jsm to standalone module There are two motivations for this change. First, reftest.jsm has become very large and monolithic. It has lots of global state and is hard to modify without breaking something. This change is a first attempt at dividing reftest.jsm into multiple standalone(ish) modules. This will make it easier to comprehend and extend. Second, we'd like to implement "run-by-manifest" mode for reftest. This means we'll restart the browser between each manifest run. This means much of the state which is normally stored in global variables in reftest.jsm, will instead need to be stored in python. A prerequisite to doing that is parsing the manifests before starting the test suite. A prerequisite to that is moving the manifest parsing code into a standalone JSM. This is the first step. MozReview-Commit-ID: 42epTs8EU1O
25bc8a430a6face614e0d3560f09e386c8c89939: Bug 1405983 - Part 2: Modify tests for delay. r?pbro draft
Daisuke Akatsuka <dakatsuka@mozilla.com> - Thu, 05 Oct 2017 22:42:57 +0900 - rev 675542
Push 83163 by bmo:dakatsuka@mozilla.com at Thu, 05 Oct 2017 13:44:02 +0000
Bug 1405983 - Part 2: Modify tests for delay. r?pbro MozReview-Commit-ID: 6ByuW2Q33Vf
f9d5d44806629204aaef60b997ee81d34cde5337: Bug 1405983 - Part 2: Modify tests for delay. r?pbro draft
Daisuke Akatsuka <dakatsuka@mozilla.com> - Thu, 05 Oct 2017 22:27:51 +0900 - rev 675541
Push 83162 by bmo:dakatsuka@mozilla.com at Thu, 05 Oct 2017 13:41:29 +0000
Bug 1405983 - Part 2: Modify tests for delay. r?pbro MozReview-Commit-ID: 6ByuW2Q33Vf
3ee3d25bc0f9c649f4b6d2c0a29ec0e9462a3b7d: Bug 1405983 - Part 1: Display delay area in summary graph as 0 if fill is none or forwards. r?pbro draft
Daisuke Akatsuka <dakatsuka@mozilla.com> - Thu, 05 Oct 2017 21:23:14 +0900 - rev 675540
Push 83162 by bmo:dakatsuka@mozilla.com at Thu, 05 Oct 2017 13:41:29 +0000
Bug 1405983 - Part 1: Display delay area in summary graph as 0 if fill is none or forwards. r?pbro MozReview-Commit-ID: 6PRlPThxRw8
(0) -300000 -100000 -30000 -10000 -3000 -1000 -300 -100 -50 -20 +20 +50 +100 +300 +1000 +3000 +10000 +30000 +100000 tip