6b21afa369f500aa762c24019299ae1122bb45ea: Bug 1343451 - part 3-2: Make IMContextWrapper dispatch eKeyDown event or eKeyUp event if IME handles native key event but we have not dispatched DOM event for it yet r?m_kato draft
Masayuki Nakano <masayuki@d-toybox.com> - Thu, 22 Feb 2018 20:56:08 +0900 - rev 763570
Push 101474 by masayuki@d-toybox.com at Tue, 06 Mar 2018 05:48:04 +0000
Bug 1343451 - part 3-2: Make IMContextWrapper dispatch eKeyDown event or eKeyUp event if IME handles native key event but we have not dispatched DOM event for it yet r?m_kato Currently, IMContextWrapper doesn't dispatch eKeyDown event and eKeyUp event if it's handled by IME. However, for conforming to UI Events, it should not eat given keyboard events completely. This patch makes IMContextWrapper dispatches eKeyDown event or eKeyUp event before dispatching first event of composition events or content command event. MozReview-Commit-ID: H2jHpViTH5Q
a260eb0b40164652d44cef2585936034563897da: Bug 1343451 - part 3-1: Make KeymapWrapper::InitKeyEvent() mark given key event as "processed by IME" if it has been handled by IME r?m_kato draft
Masayuki Nakano <masayuki@d-toybox.com> - Thu, 22 Feb 2018 19:52:53 +0900 - rev 763569
Push 101474 by masayuki@d-toybox.com at Tue, 06 Mar 2018 05:48:04 +0000
Bug 1343451 - part 3-1: Make KeymapWrapper::InitKeyEvent() mark given key event as "processed by IME" if it has been handled by IME r?m_kato For conforming UI Events spec, KeymapWrapper::InitKeyEvent() should initialize mKeyCode and mKeyNameIndex with NS_VK_PROCESSKEY and KEY_NAME_INDEX_Process if given keyboard event has already been handled by IME. For making it know if given keyboard event has been handled by IME, this patch adds additional bool argument to it and its callers. Note that this patch changes keyCode value and key value of "keydown" event if it's fired before "compositionstart" since Chromium does so on Linux. MozReview-Commit-ID: FC3tfyeeopU
74f75febda63dda554b2151bbc06f9d8a147c617: Bug 1343451 - part 2: KeyboardLayout and NativeKey should use native key code value to check if the key event was handled by IME r?m_kato draft
Masayuki Nakano <masayuki@d-toybox.com> - Wed, 01 Mar 2017 15:58:50 +0900 - rev 763568
Push 101474 by masayuki@d-toybox.com at Tue, 06 Mar 2018 05:48:04 +0000
Bug 1343451 - part 2: KeyboardLayout and NativeKey should use native key code value to check if the key event was handled by IME r?m_kato On Windows, VK_PROCESSKEY key message is sent if the key event is handled by IME (in IMM mode or IMM-IME). Therefore, we can set WidgetKeyboardEvent::mKeyCode to NS_VK_PROCESSKEY and WidgetKeyboardEvent::mKeyNameIndex to KEY_NAME_INDEX_Process simply when we receive VK_PROCESSKEY. MozReview-Commit-ID: 9B8Q7rwfXYD
89094afc68b5296e5fb7a2fc8fbf7dd6df0cf9af: Bug 1343451 - part 1: Declare (DOM|NS)_VK_PROCESSKEY for keyCode value during composition r?smaug draft
Masayuki Nakano <masayuki@d-toybox.com> - Wed, 01 Mar 2017 15:41:43 +0900 - rev 763567
Push 101474 by masayuki@d-toybox.com at Tue, 06 Mar 2018 05:48:04 +0000
Bug 1343451 - part 1: Declare (DOM|NS)_VK_PROCESSKEY for keyCode value during composition r?smaug When native key event is handled by IME, we should set keyCode to 0xE5 (229, VK_PROCESS of virtual keycode of Windows) for behaving same as the other browsers. This patch declares it same as other keyCode values. MozReview-Commit-ID: 666bB1qOEgv
3c6fcefd38a890a101027a40d7494617536c4c9a: Bug 354358 - Start to dispatch "keydown" event and "keyup" event even during in composition in Nightly and early Beta r?smaug draft
Masayuki Nakano <masayuki@d-toybox.com> - Wed, 28 Feb 2018 22:19:09 +0900 - rev 763566
Push 101474 by masayuki@d-toybox.com at Tue, 06 Mar 2018 05:48:04 +0000
Bug 354358 - Start to dispatch "keydown" event and "keyup" event even during in composition in Nightly and early Beta r?smaug For confirming to UI Events spec, we should dispatch "keydown" event and "keyup" event even during in composition. This patch makes only Nightly and early Beta start to dispatch those events during a composition. MozReview-Commit-ID: 8md7NtSdurJ
a7ddcc5bf416a27bb2117c560a7afa46749f7da4: Bug 662591 - HTMLEditor should set caret to start of first editable text node or before first editable inline node r?m_kato draft
Masayuki Nakano <masayuki@d-toybox.com> - Fri, 02 Mar 2018 14:20:25 +0900 - rev 763565
Push 101473 by masayuki@d-toybox.com at Tue, 06 Mar 2018 05:45:48 +0000
Bug 662591 - HTMLEditor should set caret to start of first editable text node or before first editable inline node r?m_kato Currently, HTMLEditor doesn't initialize caret position when it gets focus by itself in most cases. Only when it's in designMode, it may move caret to the first visible (not checking CSS actually). In most cases, caret position is adjusted when EditorBase::InitializeSelection() calls Selection::SetAncestorLimiter(). If selected range is outside of new limiter, it moves caret to start of the new limiter. However, this is really different behavior from the other browsers. The other browsers try to move caret to the first editable text node or before the first editable content such as <img>, <input>, etc. This difference causes a serious incompatible issue with Draft.js. It doesn't initialize caret position when it gets focus but it assumes that caret is always set to before <br> element if there is no other content. So, let's try to behave as what other browsers do as far as possible. This patch makes editor behave as: * if selection is already in the editing host except start of the editing host, does nothing. * if there is non-editable element before any editable node, move caret to start of the editing host. * if there is editable text node or element node which cannot have a text node, move its start or before it. * if there is no editable nodes which can contain text nodes, move caret to start of the editing host. Note that before applying this patch, in designMode, BeginningOfDocument() used document element instead of <body> element. Therefore, it may set odd position if <head> element has some text nodes with <script> or <style>. However, this doesn't make sense and for making more consistent behavior between designMode and contenteditable, this patch makes it use editing host (it's <body> element if it's in designMode). MozReview-Commit-ID: 5neYoTMq6Cc
1b345f948586f4b4bf216f29c75dd3fe3ea54082: Bug 1442255 - 7. Switch the order of fd arguments; r=me draft
Jim Chen <nchen@mozilla.com> - Tue, 06 Mar 2018 00:04:56 -0500 - rev 763564
Push 101472 by bmo:nchen@mozilla.com at Tue, 06 Mar 2018 05:06:18 +0000
Bug 1442255 - 7. Switch the order of fd arguments; r=me Switch the order of the IPC FD argument and the crash FD argument in e10s calls, because the IPC FD is the primary FD, and the crash FD should be grouped with the crash annotation FD. MozReview-Commit-ID: CAVyYAIIBPm
aa46be7b9b78086c39b02932474dc4e134d3c2d3: Bug 1442255 - 6. Adjust process count for GeckoView; r=me draft
Jim Chen <nchen@mozilla.com> - Tue, 06 Mar 2018 00:04:56 -0500 - rev 763563
Push 101472 by bmo:nchen@mozilla.com at Tue, 06 Mar 2018 05:06:18 +0000
Bug 1442255 - 6. Adjust process count for GeckoView; r=me Set process count to 1 because we only support one child process right now. MozReview-Commit-ID: HJAWvN4aqSX
e49ece736ad475468c37c5d158e013a791cf4484: Bug 1442255 - 5. Use extras bundle to initialize child processes; r=esawin draft
Jim Chen <nchen@mozilla.com> - Tue, 06 Mar 2018 00:04:56 -0500 - rev 763562
Push 101472 by bmo:nchen@mozilla.com at Tue, 06 Mar 2018 05:06:18 +0000
Bug 1442255 - 5. Use extras bundle to initialize child processes; r=esawin Pass the extras bundle from the main process to the child process through IChildProcess.start, instead of through the Intent, which never worked because intent extras are not passed to Service.onBind. MozReview-Commit-ID: I2EToBNE2Y6
2d48fa2593be051813c1e381d68983ce4315579e: Bug 1442255 - 4. Use extras bundle to initialize Gecko in Fennec; r=esawin draft
Jim Chen <nchen@mozilla.com> - Tue, 06 Mar 2018 00:04:56 -0500 - rev 763561
Push 101472 by bmo:nchen@mozilla.com at Tue, 06 Mar 2018 05:06:18 +0000
Bug 1442255 - 4. Use extras bundle to initialize Gecko in Fennec; r=esawin Use extras bundle (e.g. from an Intent) to initialize Gecko in GeckoApp and GeckoService. MozReview-Commit-ID: AmLZ8Uir8f4
ab62e17148ab29ae75315e0054aa1d23756bc9b7: Bug 1442255 - 3. Use extras bundle to initialize Gecko in GeckoView; r=esawin draft
Jim Chen <nchen@mozilla.com> - Tue, 06 Mar 2018 00:04:55 -0500 - rev 763560
Push 101472 by bmo:nchen@mozilla.com at Tue, 06 Mar 2018 05:06:18 +0000
Bug 1442255 - 3. Use extras bundle to initialize Gecko in GeckoView; r=esawin Use extras bundle to initialize Gecko in GeckoSession and GeckoViewActivity. MozReview-Commit-ID: 7dtaziVBDcg
a6544e9418272699530ad3264ab8a2f2b8c3b196: Bug 1442255 - 2. Replace GeckoThread fields with extras bundle; r=esawin draft
Jim Chen <nchen@mozilla.com> - Tue, 06 Mar 2018 00:04:55 -0500 - rev 763559
Push 101472 by bmo:nchen@mozilla.com at Tue, 06 Mar 2018 05:06:18 +0000
Bug 1442255 - 2. Replace GeckoThread fields with extras bundle; r=esawin Introduce an extras bundle in GeckoThread, which we use to store things such as extra main process arguments and child process FDs. Also use the extras bundle to store environment variables to be passed to GeckoLoader. MozReview-Commit-ID: tRlBaAXxVa
0bde54fc7e1164a2b0fef8fbd161168a45aa07ab: Bug 1442255 - 1. Replace setLastIntent with extras bundle; r=esawin draft
Jim Chen <nchen@mozilla.com> - Tue, 06 Mar 2018 00:04:55 -0500 - rev 763558
Push 101472 by bmo:nchen@mozilla.com at Tue, 06 Mar 2018 05:06:18 +0000
Bug 1442255 - 1. Replace setLastIntent with extras bundle; r=esawin GeckoLoader.setLastIntent is not a very good API for setting environment variables and is often forgotten. Replace it with an extras bundle that is passed to setupGeckoEnvironment. MozReview-Commit-ID: IFhHjLdwFC5
709eae4e54ffa3f3518745516dd5d27a05255af2: Merge mozilla-central to inbound. a=merge on a CLOSED TREE
Cosmin Sabou <csabou@mozilla.com> - Tue, 06 Mar 2018 06:31:37 +0200 - rev 763557
Push 101472 by bmo:nchen@mozilla.com at Tue, 06 Mar 2018 05:06:18 +0000
Merge mozilla-central to inbound. a=merge on a CLOSED TREE
19838b896cd704a4cbf50d7e57b8d7dd8cafcbfd: Merge inbound to mozilla-central. a=merge
Cosmin Sabou <csabou@mozilla.com> - Tue, 06 Mar 2018 06:27:48 +0200 - rev 763556
Push 101472 by bmo:nchen@mozilla.com at Tue, 06 Mar 2018 05:06:18 +0000
Merge inbound to mozilla-central. a=merge
7c01c3875cae3d9b8a3fab22c4b07efe20f6d48f: Backed out 3 changesets (bug 1387976) because of merge conflicts on AsyncTabSwitcher.jsm.
Cosmin Sabou <csabou@mozilla.com> - Tue, 06 Mar 2018 06:25:54 +0200 - rev 763555
Push 101472 by bmo:nchen@mozilla.com at Tue, 06 Mar 2018 05:06:18 +0000
Backed out 3 changesets (bug 1387976) because of merge conflicts on AsyncTabSwitcher.jsm. Backed out changeset d91b6a40b32a (bug 1387976) Backed out changeset b708ab55bc72 (bug 1387976) Backed out changeset 7958b0ccbe0b (bug 1387976)
36c84344de23aa92f96c0d40076d5262aab32ad2: Bug 1436423 - Reduce the schedule pressure limit closer to the values that users are reporting. r=mconley
Jared Wein <jwein@mozilla.com> - Mon, 05 Mar 2018 14:09:39 -0500 - rev 763554
Push 101472 by bmo:nchen@mozilla.com at Tue, 06 Mar 2018 05:06:18 +0000
Bug 1436423 - Reduce the schedule pressure limit closer to the values that users are reporting. r=mconley Note that this value, 300, is still far above the 95% threshold that telemetry is reporting (59 milliseconds) so this won't be noticeable to most users. The > 1% of users who are having this issue will benefit greatly from this change. MozReview-Commit-ID: Bd51gjc5z83
09978f543c018b2caea2cb132a2d55cc69b2647a: Bug 1443229 - Add a 'command' event listener for the urlbar search suggestions checkbox. r=Gijs
Jared Wein <jwein@mozilla.com> - Mon, 05 Mar 2018 16:17:25 -0500 - rev 763553
Push 101472 by bmo:nchen@mozilla.com at Tue, 06 Mar 2018 05:06:18 +0000
Bug 1443229 - Add a 'command' event listener for the urlbar search suggestions checkbox. r=Gijs This was inadvertently removed when the preference attribute was removed to clean up a race condition. MozReview-Commit-ID: 8yNPMwkGS3u
cfe4f208baacf94a25c1b3ed9dd8e2bd5a3a620c: Bug 1443231 - Another follow-up to fix a debug assertion in the gtest. r=botond
Botond Ballo <botond@mozilla.com> - Mon, 05 Mar 2018 17:00:46 -0500 - rev 763552
Push 101472 by bmo:nchen@mozilla.com at Tue, 06 Mar 2018 05:06:18 +0000
Bug 1443231 - Another follow-up to fix a debug assertion in the gtest. r=botond MozReview-Commit-ID: 4p1zurPLCRB
c6e5bda8eb7352bf350d4182e70491bf89ab5a82: Bug 1443252 - Make nsGlobalWindowInner/Outer final to reduce build times. r=mystor
Tom Ritter <tom@mozilla.com> - Fri, 02 Mar 2018 09:30:03 -0600 - rev 763551
Push 101472 by bmo:nchen@mozilla.com at Tue, 06 Mar 2018 05:06:18 +0000
Bug 1443252 - Make nsGlobalWindowInner/Outer final to reduce build times. r=mystor In Bug 1332680 we got a list of classes and methods we could mark 'final', as suggested by an LTO build of gcc. One of the items on that list was nsGlobalWindowInner and nsGlobalWindowOuter, with quite a lot of virtual calls: > dom/base/nsGlobalWindowInner.h:206:7: warning: Declaring type 'struct nsGlobalWindowInner' final would enable devirtualization of 483 calls > dom/base/nsGlobalWindowOuter.h:164:7: warning: Declaring type 'struct nsGlobalWindowOuter' final would enable devirtualization of 143 calls After trying it out, we saw a modest improvement to a single Talos tes (displaylist mutate got 4-8.5% better). That's not the interesting thing though. For Linux and OSX (and some flavors of Android) build times were reduced by half across the board. They're a bit variable of course, but 30-70% improvements are shown by Talos. Windows and other flavors of Android show 10-15% improvements. MozReview-Commit-ID: GlEGBt2JOTt
(0) -300000 -100000 -30000 -10000 -3000 -1000 -300 -100 -50 -20 +20 +50 +100 +300 +1000 +3000 +10000 +30000 tip