78b72994168d82c29d25eeaf6870c835851af5f8: Bug 1154874 - Add a debugger-specific DAMP test for Talos [New Frontend] draft
yulia <ystartsev@mozilla.com> - Wed, 28 Feb 2018 11:11:21 +0100 - rev 762370
Push 101163 by bmo:ystartsev@mozilla.com at Fri, 02 Mar 2018 11:18:05 +0000
Bug 1154874 - Add a debugger-specific DAMP test for Talos [New Frontend] MozReview-Commit-ID: HbVgCVPPlYw
d7d9e806c02d096bf218b106e3e5798fa19598cf: Bug 1440169 - Take TrackTicks samples in SineWaveGenerator::generate. r?achronop draft
Andreas Pehrson <pehrsons@mozilla.com> - Fri, 02 Mar 2018 11:43:57 +0100 - rev 762369
Push 101162 by bmo:apehrson@mozilla.com at Fri, 02 Mar 2018 10:47:28 +0000
Bug 1440169 - Take TrackTicks samples in SineWaveGenerator::generate. r?achronop MediaEngineDefaultAudio uses the SineWaveGenerator and passes a TrackTicks (int64_t) arg to generate(). It need to take the same type or bad things can happen. MozReview-Commit-ID: EoybtTFkWhT
59e1833f8bb4782573fbebb800338cae37b49ef7: Bug 1343451 - part 5: Make GeckoEditableSupport dispatch dummy eKeyDown and eKeyUp event during composition always r?jchen draft
Masayuki Nakano <masayuki@d-toybox.com> - Tue, 27 Feb 2018 17:24:35 +0900 - rev 762368
Push 101161 by masayuki@d-toybox.com at Fri, 02 Mar 2018 09:53:57 +0000
Bug 1343451 - part 5: Make GeckoEditableSupport dispatch dummy eKeyDown and eKeyUp event during composition always r?jchen On Android, GeckoEditableSupport has already dispatched eKeyDown event and eKeyUp event even during composition. I.e., the pref which will be enabled by bug 354358 has already been set to true only on Android. On the other hand, GeckoEditableSupport does not dispatch them if content listens to "input", "compositionstart", "compositionupdate" or "compositionend". So, different from the other platforms, we cannot test this behind pref ("dom.keyboardevent.dispatch_during_composition") even in Nightly. Therefore, this patch enables new behavior only when it's Nightly build or early Beta. And sets mKeyCode and mKeyNameIndex of the dummy KeyboardEvents to NS_VK_PROCESSKEY and KEY_NAME_INDEX_Process. MozReview-Commit-ID: Fuy0Ir2xiO5
a7b388528b45d436892767c9667672f6b055200b: Bug 1343451 - part 4: Make TextInputHandler dispatches eKeyDown event with marking it as "processed by IME" r?m_kato draft
Masayuki Nakano <masayuki@d-toybox.com> - Fri, 23 Feb 2018 23:09:43 +0900 - rev 762367
Push 101161 by masayuki@d-toybox.com at Fri, 02 Mar 2018 09:53:57 +0000
Bug 1343451 - part 4: Make TextInputHandler dispatches eKeyDown event with marking it as "processed by IME" r?m_kato First of all, TextInputHandler::HandleKeyDown() dispatches an eKeyDown event before sending IME. This is different behavior from Gecko on the other platforms and it means TextInputHandler does not know if the eKeyDown event will be handled by IME. Therefore, we need to make TextInputHandler dispatch an eKeyDown event dispatch when it needs to dispatch another event. Therefore, this patch makes TextInputHandler not dispatch an eKeyDown even from its HandleKeyDown() unless it's already has composition (because if it's already had composition, any eKeyDown event except modifier keys should be marked as "processed by IME" for compatibility with the other browsers). For dispatching eKeyDown event only once for a native keydown event, this patch implements TextInputHandlerBase::MaybeDispatchCurrentKeydownEvent() to check whether eKeyDown event has already been dispatched for the event and if it's not so, dispatches eKeyDown event. Note that on macOS, dead keys are implemented as IME. However, we need to treat dead keys as is. Therefore, if current keydown event is a dead keydown event, MaybeDispatchCurrentKeydownEvent() should NOT mark dispatching eKeyDown event and its following eKeyDown event as "processed by IME". MozReview-Commit-ID: 7epk8wdAznd
ca08aa39309aa58a429d3a19000630a5f0e78cac: 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 762366
Push 101161 by masayuki@d-toybox.com at Fri, 02 Mar 2018 09:53:57 +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
4a7b6d05b4f87f0439cb7621f757bc267126f063: 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 762365
Push 101161 by masayuki@d-toybox.com at Fri, 02 Mar 2018 09:53:57 +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
5e974a7cf452fc2b67569b731fd0b51142c85fad: 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 762364
Push 101161 by masayuki@d-toybox.com at Fri, 02 Mar 2018 09:53:57 +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
cd094e543a2d35f64ab271588b8006a06d876b53: 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 762363
Push 101161 by masayuki@d-toybox.com at Fri, 02 Mar 2018 09:53:57 +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
a5143d27fc4bdd2f593dcd2f1d836614be226a26: 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 762362
Push 101161 by masayuki@d-toybox.com at Fri, 02 Mar 2018 09:53:57 +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
282806b7f96338f6f82af76861b8548de15aad45: 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 762361
Push 101161 by masayuki@d-toybox.com at Fri, 02 Mar 2018 09:53:57 +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
d1db019ffdc6fe3e22e319bed9fdbfba6fcac07d: Bug 1437438 - Add a performance counter to track scheduler activity - r?farre r?froydnj draft
Tarek Ziadé <tarek@mozilla.com> - Mon, 12 Feb 2018 09:22:16 +0100 - rev 762360
Push 101160 by tziade@mozilla.com at Fri, 02 Mar 2018 09:53:22 +0000
Bug 1437438 - Add a performance counter to track scheduler activity - r?farre r?froydnj Adds a PeformanceCounter class that is used in DocGroup and WorkerPrivate to track runnables execution and dispatch counts. MozReview-Commit-ID: 51DLj6ORD2O
c2f5b511647d77daf9d5cba6c9d20b4fc1273d96: Bug 1437438 - Add a performance counter to track scheduler activity - r?farre r?froydnj draft
Tarek Ziadé <tarek@mozilla.com> - Mon, 12 Feb 2018 09:22:16 +0100 - rev 762359
Push 101159 by tziade@mozilla.com at Fri, 02 Mar 2018 09:27:31 +0000
Bug 1437438 - Add a performance counter to track scheduler activity - r?farre r?froydnj Adds a PeformanceCounter class that is used in DocGroup and WorkerPrivate to track runnables execution and dispatch counts. MozReview-Commit-ID: 51DLj6ORD2O
5442130484e0ff6ada27b9f7da4ce6226d9103bb: Bug 1382605 - Fix 6 tests failures on devtools/client/shared due the EventEmitter refactoring draft
yulia <ystartsev@mozilla.com> - Thu, 01 Mar 2018 15:50:10 +0100 - rev 762358
Push 101158 by bmo:ystartsev@mozilla.com at Fri, 02 Mar 2018 09:22:04 +0000
Bug 1382605 - Fix 6 tests failures on devtools/client/shared due the EventEmitter refactoring MozReview-Commit-ID: C0aXeLfZOP1
1ea5ea42758706d21c4520ce69064facb8e71e5a: Bug 1382577 - Remove old-event-emitter usage from canvasdebugger; r=sole. draft
Nicolas Chevobbe <nchevobbe@mozilla.com> - Fri, 02 Mar 2018 09:13:12 +0100 - rev 762357
Push 101157 by bmo:nchevobbe@mozilla.com at Fri, 02 Mar 2018 08:14:05 +0000
Bug 1382577 - Remove old-event-emitter usage from canvasdebugger; r=sole. MozReview-Commit-ID: ASxhdrMSWAQ
336a32c191ad64b88ab0282897eccf41a3d3cf79: Bug 1435709 - Don't attempt to use stagefright to decode theora. r?padenot draft
Jean-Yves Avenard <jyavenard@mozilla.com> - Fri, 02 Mar 2018 07:49:25 +0100 - rev 762356
Push 101156 by bmo:jyavenard@mozilla.com at Fri, 02 Mar 2018 08:04:10 +0000
Bug 1435709 - Don't attempt to use stagefright to decode theora. r?padenot MozReview-Commit-ID: 215BhSSWGBC
3f89193d86d4f1944f62528931f8d8f9060df270: Bug 1437003 - Allow H264 level up to 5.2 inclusive. r?padenot draft
Jean-Yves Avenard <jyavenard@mozilla.com> - Thu, 01 Mar 2018 09:38:45 +0100 - rev 762355
Push 101156 by bmo:jyavenard@mozilla.com at Fri, 02 Mar 2018 08:04:10 +0000
Bug 1437003 - Allow H264 level up to 5.2 inclusive. r?padenot MozReview-Commit-ID: KiwVH9BUGrV
a75b3c7f7c1640f167ba0d0153d3b50c5ced5019: Bug 1441683 - response.complete() should make the completeStatus available to the payment UI service. r?baku,mattn draft
Jared Wein <jwein@mozilla.com> - Wed, 28 Feb 2018 21:08:25 -0500 - rev 762354
Push 101155 by bmo:jaws@mozilla.com at Fri, 02 Mar 2018 07:56:36 +0000
Bug 1441683 - response.complete() should make the completeStatus available to the payment UI service. r?baku,mattn todo: add some tests in the DOM code that don't rely on the UI layer MozReview-Commit-ID: TnszpuqAa
f4344a5ec10ef1ea68494fcdb6b1f9400b4f82be: Bug 1442451 - do not restore DevTools session when disabled by policy;r=jryans draft
Julian Descottes <jdescottes@mozilla.com> - Fri, 02 Mar 2018 08:55:24 +0100 - rev 762353
Push 101154 by jdescottes@mozilla.com at Fri, 02 Mar 2018 07:55:51 +0000
Bug 1442451 - do not restore DevTools session when disabled by policy;r=jryans MozReview-Commit-ID: oORq9CltE3
f78722bc3e691043629e6cd4ffbfc23321070dca: Bug 1439831 - Enable ESLint rule mozilla/use-services for mobile/android. r?nechen draft
Mark Banner <standard8@mozilla.com> - Wed, 21 Feb 2018 08:57:28 +0000 - rev 762352
Push 101153 by bmo:standard8@mozilla.com at Fri, 02 Mar 2018 07:55:45 +0000
Bug 1439831 - Enable ESLint rule mozilla/use-services for mobile/android. r?nechen MozReview-Commit-ID: 3MuRD78hMuE
df0e967f8e8fa30a69338008b6ee296bf5e9c545: Bug 1441488 followup, remove incorrect annotation that webdriver/tests/navigation/current_url.py fails on Linux debug, since it doesn't, a=permaorange
Phil Ringnalda <philringnalda@gmail.com> - Thu, 01 Mar 2018 20:34:33 -0800 - rev 762351
Push 101153 by bmo:standard8@mozilla.com at Fri, 02 Mar 2018 07:55:45 +0000
Bug 1441488 followup, remove incorrect annotation that webdriver/tests/navigation/current_url.py fails on Linux debug, since it doesn't, a=permaorange
(0) -300000 -100000 -30000 -10000 -3000 -1000 -300 -100 -50 -20 +20 +50 +100 +300 +1000 +3000 +10000 +30000 tip