1b423cf639262473ebcc57998bbcf274daa889d5: Bug 1608657 - Drop version check from WMFDecoderDllName and inline when possible. r=jya
Alex Henrie <alexhenrie24@gmail.com> - Tue, 14 Jan 2020 01:18:49 +0000 - rev 510056
Push 37013 by malexandru@mozilla.com at Tue, 14 Jan 2020 09:44:10 +0000
Bug 1608657 - Drop version check from WMFDecoderDllName and inline when possible. r=jya Only Windows 7 and later are now supported. Differential Revision: https://phabricator.services.mozilla.com/D59604
5511edd700f79dd849bc3a769e8a5e38dd78745f: 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 01:09:45 +0000 - rev 510055
Push 37013 by malexandru@mozilla.com at Tue, 14 Jan 2020 09:44:10 +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
1fb9cf2264b668a76d3671a5a3b06f67c587c0c0: Bug 970802 - part 4: Make `TextControlState` dispatch "beforeinput" event if there is no `TextEditor` r=smaug
Masayuki Nakano <masayuki@d-toybox.com> - Wed, 08 Jan 2020 09:24:33 +0000 - rev 510054
Push 37013 by malexandru@mozilla.com at Tue, 14 Jan 2020 09:44:10 +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
6b185296c742e870768b834c1e2533ac7ac16351: Bug 970802 - part 3: Implement `beforeinput` event dispatcher and add `onbeforeinput` event handler attribute r=smaug
Masayuki Nakano <masayuki@d-toybox.com> - Wed, 08 Jan 2020 09:23:40 +0000 - rev 510053
Push 37013 by malexandru@mozilla.com at Tue, 14 Jan 2020 09:44:10 +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
ce6853e64ed663a8b0656e2e7073a8e53200a33f: Bug 970802 - part 2: HTML editor command classes shouldn't handle edit actions multiple times r=m_kato
Masayuki Nakano <masayuki@d-toybox.com> - Wed, 08 Jan 2020 09:22:52 +0000 - rev 510052
Push 37013 by malexandru@mozilla.com at Tue, 14 Jan 2020 09:44:10 +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
aa9bd45c09b1c4d0bb5d9beb50e2c211defe4fc8: Bug 970802 - part 1: Add `beforeinput` event tests into existing mochitests r=smaug
Masayuki Nakano <masayuki@d-toybox.com> - Wed, 08 Jan 2020 09:22:50 +0000 - rev 510051
Push 37013 by malexandru@mozilla.com at Tue, 14 Jan 2020 09:44:10 +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
a89ab01aec47fc6f457ddf6bfd2650e407f169d3: Bug 1606485 - Check containing parent frames for 'contain:layout/paint' in grid container frames. r=emilio
Emily McDonough <emcdonough@mozilla.com> - Tue, 14 Jan 2020 01:06:56 +0000 - rev 510050
Push 37013 by malexandru@mozilla.com at Tue, 14 Jan 2020 09:44:10 +0000
Bug 1606485 - Check containing parent frames for 'contain:layout/paint' in grid container frames. r=emilio This prevents grid container frames from being considered subgrid (even when they have contain:layout/paint) when they are themselves a grid item of a contain grid. Differential Revision: https://phabricator.services.mozilla.com/D59790
b3591e00dc30dc75b9dd99a5ae9c8edde1d7aa6d: Bug 1606485 - Add crash testcases for nested subgrids with contain: strict r=emilio
Emily McDonough <emcdonough@mozilla.com> - Tue, 14 Jan 2020 01:06:49 +0000 - rev 510049
Push 37013 by malexandru@mozilla.com at Tue, 14 Jan 2020 09:44:10 +0000
Bug 1606485 - Add crash testcases for nested subgrids with contain: strict r=emilio Differential Revision: https://phabricator.services.mozilla.com/D59820
44e9e8835e9f79ef3d642e67f9391b76f214e515: Bug 1031664 - Enable outline-style: auto. r=mats
Emilio Cobos Álvarez <emilio@crisal.io> - Tue, 14 Jan 2020 00:54:35 +0000 - rev 510048
Push 37013 by malexandru@mozilla.com at Tue, 14 Jan 2020 09:44:10 +0000
Bug 1031664 - Enable outline-style: auto. r=mats With the gtk fix in place is there any reason not to do this? I'll send an intent if so. Let me know if you want to keep it on nightly / early beta for a while, too. Differential Revision: https://phabricator.services.mozilla.com/D57935
af8850d24e1533d4102b38dbf4868bc5e5549ae3: Bug 1608925 - Stub out Personalization reducer component and devtools. r=gvn
Scott <scott.downe@gmail.com> - Tue, 14 Jan 2020 00:40:02 +0000 - rev 510047
Push 37013 by malexandru@mozilla.com at Tue, 14 Jan 2020 09:44:10 +0000
Bug 1608925 - Stub out Personalization reducer component and devtools. r=gvn Differential Revision: https://phabricator.services.mozilla.com/D59784
29d14e521aeca4250a9b5671a347a7c78987496f: Bug 1608763 - Assign DoH Rollout component to Firefox::Security. r=nhnt11
Johann Hofmann <jhofmann@mozilla.com> - Tue, 14 Jan 2020 00:34:17 +0000 - rev 510046
Push 37013 by malexandru@mozilla.com at Tue, 14 Jan 2020 09:44:10 +0000
Bug 1608763 - Assign DoH Rollout component to Firefox::Security. r=nhnt11 Differential Revision: https://phabricator.services.mozilla.com/D59659
c29b2c0e72223d35511fd9910b69a2bd3036939b: Bug 1608977 - Remove declaration of JS_GetSharedArrayBufferViewType; r=jwalden
Edgar Chen <echen@mozilla.com> - Tue, 14 Jan 2020 00:22:13 +0000 - rev 510045
Push 37013 by malexandru@mozilla.com at Tue, 14 Jan 2020 09:44:10 +0000
Bug 1608977 - Remove declaration of JS_GetSharedArrayBufferViewType; r=jwalden The implementation was removed from Bug 1176214. Differential Revision: https://phabricator.services.mozilla.com/D59800
492f2ffadfa28a3996f877cc1772d1743f7bc4d3: Bug 1608506 - Split helper_basic_double_tap_zoom.html out into its own test group which only runs on mobile. r=hiro
Botond Ballo <botond@mozilla.com> - Tue, 14 Jan 2020 00:22:55 +0000 - rev 510044
Push 37013 by malexandru@mozilla.com at Tue, 14 Jan 2020 09:44:10 +0000
Bug 1608506 - Split helper_basic_double_tap_zoom.html out into its own test group which only runs on mobile. r=hiro This test needs mobile viewport sizing because we gate double tap zooming on that. Differential Revision: https://phabricator.services.mozilla.com/D59590
10c4b29373fe2ab52e51ea5b2be2698c8b1028f8: Bug 1608506 - Avoid using mobile viewport sizing in test_group_zoom-2.html. r=hiro
Botond Ballo <botond@mozilla.com> - Tue, 14 Jan 2020 00:22:47 +0000 - rev 510043
Push 37013 by malexandru@mozilla.com at Tue, 14 Jan 2020 09:44:10 +0000
Bug 1608506 - Avoid using mobile viewport sizing in test_group_zoom-2.html. r=hiro Note, in helper_bug1280013.html, since we are now zooming to 2x, the quantities specified in CSS pixels need to be scaled down by 2x accordingly, to maintain the relative positions of the elements and gestures on the screen. Differential Revision: https://phabricator.services.mozilla.com/D59589
925d323581b2068ca5ca6b35e8158a25d7752659: Bug 1608506 - Avoid using mobile viewport sizing in test_group_touchevents-4.html. r=hiro
Botond Ballo <botond@mozilla.com> - Tue, 14 Jan 2020 00:22:43 +0000 - rev 510042
Push 37013 by malexandru@mozilla.com at Tue, 14 Jan 2020 09:44:10 +0000
Bug 1608506 - Avoid using mobile viewport sizing in test_group_touchevents-4.html. r=hiro Differential Revision: https://phabricator.services.mozilla.com/D59588
20b367eea138dcc2bbeaa9c1aa1ec49948899ad1: Bug 1608506 - Use nsIDOMWindowUtils.setResolutionAndScaleTo() rather than initial-scale to zoom in most APZ mochitests. r=hiro
Botond Ballo <botond@mozilla.com> - Tue, 14 Jan 2020 00:22:30 +0000 - rev 510041
Push 37013 by malexandru@mozilla.com at Tue, 14 Jan 2020 09:44:10 +0000
Bug 1608506 - Use nsIDOMWindowUtils.setResolutionAndScaleTo() rather than initial-scale to zoom in most APZ mochitests. r=hiro The exception is the tests in test_group_minimum_scale_size.html, which are specifically testing mobile viewport sizing behaviour. Differential Revision: https://phabricator.services.mozilla.com/D59587
ec6194dd2e2564894fe1dea4e8f3f19a2737d27c: Bug 1608506 - Only force dom.meta-viewport.enabled=true for APZ subtests that actually need it. r=hiro
Botond Ballo <botond@mozilla.com> - Tue, 14 Jan 2020 00:22:20 +0000 - rev 510040
Push 37013 by malexandru@mozilla.com at Tue, 14 Jan 2020 09:44:10 +0000
Bug 1608506 - Only force dom.meta-viewport.enabled=true for APZ subtests that actually need it. r=hiro Differential Revision: https://phabricator.services.mozilla.com/D59586
b3d0b186aff53d05d8ceeeb6aa372ea0ac009658: Bug 1600919 - work around XUL layout bug by manually measuring wrapping description element in reset profile dialog, r=MattN,zbraniecki
Gijs Kruitbosch <gijskruitbosch@gmail.com> - Mon, 13 Jan 2020 23:42:29 +0000 - rev 510039
Push 37013 by malexandru@mozilla.com at Tue, 14 Jan 2020 09:44:10 +0000
Bug 1600919 - work around XUL layout bug by manually measuring wrapping description element in reset profile dialog, r=MattN,zbraniecki This is basically the same technique as `descriptionHeightWorkaround` in the PanelMultiView implementation (from bug 1009116). Differential Revision: https://phabricator.services.mozilla.com/D58948
caa6177248f7ab3bbdc02bf103811f7bbf03f9d7: Bug 1604222 - Implement disable(APP_DISABLED) for WebExtension. r=snorp
Agi Sferro <agi@sferro.dev> - Mon, 13 Jan 2020 23:32:33 +0000 - rev 510038
Push 37013 by malexandru@mozilla.com at Tue, 14 Jan 2020 09:44:10 +0000
Bug 1604222 - Implement disable(APP_DISABLED) for WebExtension. r=snorp Differential Revision: https://phabricator.services.mozilla.com/D59223
8efb3300928844d9ed5d3da412a39aa21c6d4924: Bug 1604222 - Add embedderDisabled field to addon. r=mixedpuppy
Agi Sferro <agi@sferro.dev> - Mon, 13 Jan 2020 23:08:03 +0000 - rev 510037
Push 37013 by malexandru@mozilla.com at Tue, 14 Jan 2020 09:44:10 +0000
Bug 1604222 - Add embedderDisabled field to addon. r=mixedpuppy This allows embedding applications to disable addons independently of the user disabled field. Differential Revision: https://phabricator.services.mozilla.com/D59222
(0) -300000 -100000 -30000 -10000 -3000 -1000 -300 -100 -50 -20 +20 +50 +100 +300 +1000 +3000 +10000 +30000 tip