427faa0aef8748a75e17d48162a719142e9296c6: Bug 1591564 - Update glean-preview to 0.0.4 r=janerik
Chris H-C <chutten@mozilla.com> - Mon, 13 Jan 2020 18:52:24 +0000 - rev 510100
Push 37014 by cbrindusan@mozilla.com at Tue, 14 Jan 2020 21:43:07 +0000
Bug 1591564 - Update glean-preview to 0.0.4 r=janerik Differential Revision: https://phabricator.services.mozilla.com/D57977
fc040effba1ca601e9b94396d0201ceb82c713ba: Bug 1591564 - Debug log when failing to send pings r=janerik,emilio
Chris H-C <chutten@mozilla.com> - Mon, 13 Jan 2020 18:52:16 +0000 - rev 510099
Push 37014 by cbrindusan@mozilla.com at Tue, 14 Jan 2020 21:43:07 +0000
Bug 1591564 - Debug log when failing to send pings r=janerik,emilio Differential Revision: https://phabricator.services.mozilla.com/D57359
5edf28e3c13bef06f41b47d856e6f9813d5e0ac0: Bug 1591564 - Convert FOGotype Glean pings to pingsender format and send them r=janerik
Chris H-C <chutten@mozilla.com> - Mon, 13 Jan 2020 18:52:09 +0000 - rev 510098
Push 37014 by cbrindusan@mozilla.com at Tue, 14 Jan 2020 21:43:07 +0000
Bug 1591564 - Convert FOGotype Glean pings to pingsender format and send them r=janerik Differential Revision: https://phabricator.services.mozilla.com/D57108
43d749cff07e050028f1e3e5c382ed7e2fb8fb08: Bug 1591564 - Determine from the pref whether Glean upload is enabled r=janerik,emilio
Chris H-C <chutten@mozilla.com> - Mon, 13 Jan 2020 18:52:06 +0000 - rev 510097
Push 37014 by cbrindusan@mozilla.com at Tue, 14 Jan 2020 21:43:07 +0000
Bug 1591564 - Determine from the pref whether Glean upload is enabled r=janerik,emilio Since we're the only one sending data, and we're doing so infrequently, let's get the pref value before each ping send instead of building a pref observer right this second. Differential Revision: https://phabricator.services.mozilla.com/D57107
6dbc2325d1ed6dcc3ec3ae36a873874c7807d526: Bug 1591564 - Assemble a 'prototype' ping every hour. r=janerik
Chris H-C <chutten@mozilla.com> - Mon, 13 Jan 2020 18:51:59 +0000 - rev 510096
Push 37014 by cbrindusan@mozilla.com at Tue, 14 Jan 2020 21:43:07 +0000
Bug 1591564 - Assemble a 'prototype' ping every hour. r=janerik Differential Revision: https://phabricator.services.mozilla.com/D57106
b18f5ee1249459ea8bb4ec8793ef775c87f707f2: Bug 1591564 - Initialize the FOGotype when Telemetry inits r=janerik,emilio
Chris H-C <chutten@mozilla.com> - Mon, 13 Jan 2020 18:51:51 +0000 - rev 510095
Push 37014 by cbrindusan@mozilla.com at Tue, 14 Jan 2020 21:43:07 +0000
Bug 1591564 - Initialize the FOGotype when Telemetry inits r=janerik,emilio Differential Revision: https://phabricator.services.mozilla.com/D57105
7386e5251a9513ab635f13483f86c94d599f2f11: Bug 1608084 - Disable webdriver/tests/minimize_window/user_prompts.py as it is consistently timing out in the Linux coverage build. r=whimboo
Marco Castelluccio <mcastelluccio@mozilla.com> - Tue, 14 Jan 2020 07:14:53 +0000 - rev 510094
Push 37014 by cbrindusan@mozilla.com at Tue, 14 Jan 2020 21:43:07 +0000
Bug 1608084 - Disable webdriver/tests/minimize_window/user_prompts.py as it is consistently timing out in the Linux coverage build. r=whimboo Depends on D59792 Differential Revision: https://phabricator.services.mozilla.com/D59793
30de211777522aa28103fda6faebc51e80b06552: Bug 1608956 - Disable webdriver/tests/close_window/close.py as it is consistently timing out in the Linux coverage build. r=whimboo
Marco Castelluccio <mcastelluccio@mozilla.com> - Tue, 14 Jan 2020 07:15:02 +0000 - rev 510093
Push 37014 by cbrindusan@mozilla.com at Tue, 14 Jan 2020 21:43:07 +0000
Bug 1608956 - Disable webdriver/tests/close_window/close.py as it is consistently timing out in the Linux coverage build. r=whimboo Differential Revision: https://phabricator.services.mozilla.com/D59792
c31f6054754f87cbcbc6ec288a26eed3c6bac9ac: Bug 1587387 Ignore error 572 when stoping mitmproxy r=tarek
Florin Strugariu <fstrugariu@mozilla.com> - Tue, 14 Jan 2020 08:21:42 +0000 - rev 510092
Push 37014 by cbrindusan@mozilla.com at Tue, 14 Jan 2020 21:43:07 +0000
Bug 1587387 Ignore error 572 when stoping mitmproxy r=tarek Differential Revision: https://phabricator.services.mozilla.com/D59743
89dcc457c42f9f3a78cb5bf9ecbc18835ff7192a: Bug 1600878 - P3. Do not store contentBlockingEvent in RemoteSecurityUI.jsm r=timhuang,Ehsan
Dimi Lee <dlee@mozilla.com> - Tue, 17 Dec 2019 11:25:27 +0000 - rev 510091
Push 37014 by cbrindusan@mozilla.com at Tue, 14 Jan 2020 21:43:07 +0000
Bug 1600878 - P3. Do not store contentBlockingEvent in RemoteSecurityUI.jsm r=timhuang,Ehsan ContentBlockingEvents is now accessed via WindowGlobalActor::ContentBlockingEvents. Updating and storing contentBlockingEvent in RemoteSecurityUI are no longer needed. Depends on D55622 Differential Revision: https://phabricator.services.mozilla.com/D55623
bd432376ef0d60c6f77a251ce6ed56285f5464a6: Bug 1600878 - P2. Use contentBlockingEvents in WindowGlobalParent instead of contentBlockingEvent in RemoteSecurityUI r=timhuang,Ehsan
Dimi Lee <dlee@mozilla.com> - Tue, 17 Dec 2019 11:25:23 +0000 - rev 510090
Push 37014 by cbrindusan@mozilla.com at Tue, 14 Jan 2020 21:43:07 +0000
Bug 1600878 - P2. Use contentBlockingEvents in WindowGlobalParent instead of contentBlockingEvent in RemoteSecurityUI r=timhuang,Ehsan ContentBlockingEvent in RemoteSecurityUI is updated after receiving a notification from a child process. Since contentBlockingEvent will be removed from the child, this patch removes the use of contentBlockingEvent in RemoteSecurityUI and uses the API defined in WindowGlobalActor. Depends on D55621 Differential Revision: https://phabricator.services.mozilla.com/D55622
7535e00d33e9c5201a27720ae735830dbdc146fb: Bug 1600878 - P1. Add contentBlockingEvent attribute to WindowGlobalActors.webidl r=timhuang,Ehsan
Dimi Lee <dlee@mozilla.com> - Tue, 17 Dec 2019 11:25:25 +0000 - rev 510089
Push 37014 by cbrindusan@mozilla.com at Tue, 14 Jan 2020 21:43:07 +0000
Bug 1600878 - P1. Add contentBlockingEvent attribute to WindowGlobalActors.webidl r=timhuang,Ehsan This allows us to access contentBlockingEvents in the parent process through a WindowGlobalParent object. Differential Revision: https://phabricator.services.mozilla.com/D55621
d8692534449fd857ec2bbc8ca30ed6480b795ab5: Bug 1565027 - check browsertime node install
Tarek Ziadé <tarek@mozilla.com> - Tue, 14 Jan 2020 08:14:35 +0000 - rev 510088
Push 37014 by cbrindusan@mozilla.com at Tue, 14 Jan 2020 21:43:07 +0000
Bug 1565027 - check browsertime node install Teach `mach browsertime` to tell you to `mach browsertime --setup` if we're not already set up Differential Revision: https://phabricator.services.mozilla.com/D59501
08999096f418499e6d5597c4ae0962d03c5be273: Bug 1607522 - hard stop if Pillow or pyssim could not be installed r=nalexander
Tarek Ziadé <tarek@mozilla.com> - Tue, 14 Jan 2020 08:04:54 +0000 - rev 510087
Push 37014 by cbrindusan@mozilla.com at Tue, 14 Jan 2020 21:43:07 +0000
Bug 1607522 - hard stop if Pillow or pyssim could not be installed r=nalexander Let's stop if the packages could not be installed. Also, let's skip the call if we find them. Differential Revision: https://phabricator.services.mozilla.com/D59690
f6a56b3d09559e65945cdff58c2e64759232fe63: Bug 970802 - part 5: Make `AutoEditActionDataSetter` created method dispatch "beforeinput" event r=smaug,m_kato
Masayuki Nakano <masayuki@d-toybox.com> - Tue, 14 Jan 2020 07:18:51 +0000 - rev 510086
Push 37014 by cbrindusan@mozilla.com at Tue, 14 Jan 2020 21:43:07 +0000
Bug 970802 - part 5: Make `AutoEditActionDataSetter` created method dispatch "beforeinput" event r=smaug,m_kato `AutoEditActionDataSetter` is created in the stack when editor's public method is called and that guarantees lifetime of global objects in editor such as editor itself, selection controller, etc. The dispatcher of `beforeinput` event returns `NS_ERROR_EDITOR_ACTION_CANCELED` if an event is actually dispatched but canceled. The reason why it's an error is, editor code must stop handling anything when any methods return error. So, returning an error code is reasonable in editor module. But when it's filtered by `EditorBase::ToGenericNSResult()` at return statement of public methods, it's converted to `NS_SUCCESS_DOM_NO_OPERATION`. This avoids throwing new exception, but editor class users in C++ can distinguish whether each edit action is canceled or handled. The reason why we should not throw new exception from XPCOM API is, without taking care of each caller may break some our UI (especially for avoiding to break comm-central). Therefore, this patch does not make XPCOM methods return error code when `beforeinput` event is canceled. In most cases, immediately after creating `AutoEditActionDataSetter` is good timing to dispatch `beforeinput` event since editor has not touched the DOM yet. If `beforeinput` requires `data` or `dataTransfer`, methods need to dispatch `beforeinput` event after that. Alhtough this is not a good thing from point of view of consistency of the code. However, I have no better idea. Note 1: Our implementation does NOT conform to the spec about event order between `keypress` and `beforeinput` (dispatching `beforeinput` event after `keypress` event). However, we follow all other browsers' behavior so that it must be safe and the spec should be updated for backward compatibility. Spec issue: https://github.com/w3c/uievents/issues/220 Note 2: Our implementation does NOT conform to the spec about event order between `compositionupdate` and `beforeinput`. Our behavior is same as Safari, but different from Chrome. This might cause web-compat issues. However, our behavior does make sense from point of view of consistency of event spec. Additionally, at both `compositionupdate` and `beforeinput`, composition string in editor has not been modified yet. Therefore, this may not cause web-compat issues (and I hope so). Spec issue: https://github.com/w3c/input-events/issues/49 Note that this patch makes editor detect bugs that `beforeinput` event hasn't been handled yet when it dispatches `input` event or modifying `data` and `dataTransfer` value are modified after dispatching `beforeinput` event with `MOZ_ASSERT`s. Differential Revision: https://phabricator.services.mozilla.com/D58127
2dbb6572374cd021f7727c3ffdd0c4251b3731fb: Bug 970802 - part 4: Make `TextControlState` dispatch "beforeinput" event if there is no `TextEditor` r=smaug
Masayuki Nakano <masayuki@d-toybox.com> - Tue, 14 Jan 2020 07:16:34 +0000 - rev 510085
Push 37014 by cbrindusan@mozilla.com at Tue, 14 Jan 2020 21:43:07 +0000
Bug 970802 - part 4: Make `TextControlState` dispatch "beforeinput" event if there is no `TextEditor` r=smaug If `TextControlState` does not have `TextEditor` and its `SetValue()` is called from `SetUserInput()`, `TextControlState` itself needs to dispatch `beforeinput` event. If the value is modified by `beforeinput` event listener, it's intended that `preventDefault()` is called by the web apps. However, the behavior in this case is not mentioned by UI Events nor Input Events spec. We should just file a spec issue instead of emulating Chrome's behavior for now because it requires more changes, but this case must be an edge case. The spec issue is: https://github.com/w3c/input-events/issues/106 Differential Revision: https://phabricator.services.mozilla.com/D58126
2ce2d30b65e7a6951dcc7f65ad02225297a932b7: Bug 970802 - part 3: Implement `beforeinput` event dispatcher and add `onbeforeinput` event handler attribute r=smaug
Masayuki Nakano <masayuki@d-toybox.com> - Tue, 14 Jan 2020 07:15:45 +0000 - rev 510084
Push 37014 by cbrindusan@mozilla.com at Tue, 14 Jan 2020 21:43:07 +0000
Bug 970802 - part 3: Implement `beforeinput` event dispatcher and add `onbeforeinput` event handler attribute r=smaug This patch makes `nsContentUtils::DispatchInputEvent()` dispatch `beforeinput` event too. And also adds `onbeforeinput` event handler which is really important for feature detection (although Chrome has not implemented this attribute yet: https://bugs.chromium.org/p/chromium/issues/detail?id=947408). However, we don't implement `InputEvent.getTargetRanges()` in this bug and implementing `beforeinput` event may hit bugs of some web apps. Therefore, this patch disables `beforeinput` event by default even in Nightly channel. Differential Revision: https://phabricator.services.mozilla.com/D58125
648ad637c58e6f0558f769666ddb18d36b550344: Bug 970802 - part 2: HTML editor command classes shouldn't handle edit actions multiple times r=m_kato
Masayuki Nakano <masayuki@d-toybox.com> - Tue, 14 Jan 2020 07:14:55 +0000 - rev 510083
Push 37014 by cbrindusan@mozilla.com at Tue, 14 Jan 2020 21:43:07 +0000
Bug 970802 - part 2: HTML editor command classes shouldn't handle edit actions multiple times r=m_kato Some HTML editor command classes call `*AsAction()` methods multiple times. That causes that user needs multiple undo/redo for a command and one command causes multiple "input" events. For both compatibility with the other browsers and making "beforeinput" cancelable, they should call `*AsAction()` once. Instead, `HTMLEditor` should handle related element deletion. This patch makes `HTMLEditor::RemoveInlinePropertyInternal()` remove multiple elements if its caller allows, and `HTMLEditor::SetInlinePropertyAsAction()` call `RemoveInlinePropertyInternal()` in some cases. According to comm-central and BlueGriffon, we can make `HTMLEditor::RemoveInlineProperty()` also removes the related methods automatically because comm-central does same thing from script and BlueGriffon does not use this. However, we cannot do that for `HTMLEditor::SetInlineProperty()` because BlueGriffon may call it with any HTML5 elements and does not expect removing elements in same block at that time. If we needed to reduce the overhead of comm-central, we could change only `RemoveInlineProperty()`, but it would make these APIs behavior inconsistent. Differential Revision: https://phabricator.services.mozilla.com/D58124
9b29ee6fd8912d1ce80428da27afc686666b9691: Bug 970802 - part 1: Add `beforeinput` event tests into existing mochitests r=smaug
Masayuki Nakano <masayuki@d-toybox.com> - Tue, 14 Jan 2020 07:14:50 +0000 - rev 510082
Push 37014 by cbrindusan@mozilla.com at Tue, 14 Jan 2020 21:43:07 +0000
Bug 970802 - part 1: Add `beforeinput` event tests into existing mochitests r=smaug This patch adds a lot of `beforeinput` event tests into existing mochitests which test `input` events. But this does not add tests of canceling `beforeinput` event because it requires really complicated path until implementing `beforeinput` actually. Note that `beforeinput` event is not fired with `Document.execCommand()`. Therefore, this patch does not add WPT for testing `beforeinput` event. And unfortunately, WPT cannot test most cases of the new tests. Differential Revision: https://phabricator.services.mozilla.com/D58123
b9f97507c65183b7429147f3d7274d44e4821c75: Bug 1412401: accessible/tests/mochitest/events/docload/test_docload_root.html: Wait for focus event after opening the dialog. r=MarcoZ
James Teh <jteh@mozilla.com> - Tue, 14 Jan 2020 06:59:56 +0000 - rev 510081
Push 37014 by cbrindusan@mozilla.com at Tue, 14 Jan 2020 21:43:07 +0000
Bug 1412401: accessible/tests/mochitest/events/docload/test_docload_root.html: Wait for focus event after opening the dialog. r=MarcoZ Previously, when opening the dialog, we only waited for a reorder event. This could mean we programmatically closed the dialog before it was ever focused. That in turn would mean that focus would never be fired on the previous window when the dialog was closed, causing the close dialog test to time out. Differential Revision: https://phabricator.services.mozilla.com/D59826
(0) -300000 -100000 -30000 -10000 -3000 -1000 -300 -100 -50 -20 +20 +50 +100 +300 +1000 +3000 +10000 +30000 tip