abd87d1cd72dab08cb81d1848e8c794ca9d3078d: Bug 1527924 - (Part 2) Show selector diffs in the Changes panel. r=pbro
Razvan Caliman <rcaliman@mozilla.com> - Mon, 18 Feb 2019 13:14:29 +0000 - rev 459865
Push 112018 by btara@mozilla.com at Tue, 19 Feb 2019 17:39:20 +0000
Bug 1527924 - (Part 2) Show selector diffs in the Changes panel. r=pbro Depends on D19828 Updates the React component of the Changes panel to show the diff of a rule's selector if it has changed. The previous implementation assumed that a selector rename meant a whole rule removal (with the old selector) followed by a whole rule addition (with the new selector). This new implementation tracks the changes to the selector atomically. The main benefit is that if the selector is renamed, the diff in the Changes panel shows only this action and not the unchanged declarations. The test was re-enabled and adjusted to account for this difference in behaviour. This refactor was required in order to be compatible with Bug 1525238 which lays the ground work for matching rules from the client with rules from the server. This is necessary in order to have consistent behaviour for export options, like Copy Rule, which need to match the rule on the server even if its selector was changed. Differential Revision: https://phabricator.services.mozilla.com/D19830
5ffc0cb683a1229420094b35d5dc03c2a34db4ff: Bug 1527924 - (Part 1) Use array of selectors for the rule in Redux structure for Changes. r=pbro
Razvan Caliman <rcaliman@mozilla.com> - Fri, 15 Feb 2019 16:58:58 +0000 - rev 459864
Push 112018 by btara@mozilla.com at Tue, 19 Feb 2019 17:39:20 +0000
Bug 1527924 - (Part 1) Use array of selectors for the rule in Redux structure for Changes. r=pbro Refactors the Redux state for the Changes panel so that rules have a `selectors` array instead of just a single `selector` string. The `selectors` array represents the **history** of selector text the rule has over time, not the actual list of multiple selectors it has (multiple selectors are collapsed into a single comma-separated string regardless of how many they are). When the server logs changes, the rule's selector text is checked against the history of previously logged selectors. If the incoming selector is different than the _first_ item in the tracked rule's `selectors` array, it means the selector was renamed so it is pushed onto the array (added to the history). If it's the same, the whole array can be reduced to the original value because it means that either: - the selector didn't change between operations (ex: after declaration changes) - the selector reverted back to its original name. This `selectors` array is used in the React component in Part 2 of this series to render any necessary diff view of the selector. The old approach (whole rule removal + whole rule addition) is replaced by this refactor. The introduction of the StyleRyleActor actor id from the server as the rule id on the client in Bug 1525238 means that the selector change can no longer behave like two distinct rules. The actorID/rule id are preserved after selector renames. This necessary for the some export options to work consistently (like Copy Rule with changes applied). Differential Revision: https://phabricator.services.mozilla.com/D19828
d33544f0d8e6197126399ad928adc701582d947a: Bug 1528451 - Move code that starts image loads to DidSetComputedStyle. r=heycam
Emilio Cobos Álvarez <emilio@crisal.io> - Tue, 19 Feb 2019 00:40:10 +0000 - rev 459863
Push 112018 by btara@mozilla.com at Tue, 19 Feb 2019 17:39:20 +0000
Bug 1528451 - Move code that starts image loads to DidSetComputedStyle. r=heycam This is more consistent with all the other image request code, and handles pseudo-elements properly without having to add more out-of-band calls to UpdateStyleOfOwnedChildFrame and such. Differential Revision: https://phabricator.services.mozilla.com/D20107
e726a088a06c0d6ddf8c8a38d191d87e206b9171: Bug 998941 - Update web platform tests for InputEvent.data and InputEvent.dataTransfer r=smaug
Masayuki Nakano <masayuki@d-toybox.com> - Tue, 19 Feb 2019 06:34:21 +0000 - rev 459862
Push 112018 by btara@mozilla.com at Tue, 19 Feb 2019 17:39:20 +0000
Bug 998941 - Update web platform tests for InputEvent.data and InputEvent.dataTransfer r=smaug Differential Revision: https://phabricator.services.mozilla.com/D19299
14aa082701576b9cd9b73dc527c86ffa85df752a: Bug 998941 - part 2-3: Create new constructors of DataTransfer to set only plain text or nsITransferable r=smaug
Masayuki Nakano <masayuki@d-toybox.com> - Tue, 19 Feb 2019 07:13:20 +0000 - rev 459861
Push 112018 by btara@mozilla.com at Tue, 19 Feb 2019 17:39:20 +0000
Bug 998941 - part 2-3: Create new constructors of DataTransfer to set only plain text or nsITransferable r=smaug DataTransfer should have more 2 constructors. One takes |const nsAString&| and sets its data to the string. The other takes |nsITransferable*| and stores only its data with DataTransferItem. If given data is external resource like the case of `HTMLEditor::PasteTransferable()`, we should copy its data to each DataTransferItem because nsITransferable is not cycle-collectable, but DataTransfer may be grabbed by JS. Unfortunately, adding new path to initialize DataTransfer with nsITransferable instance is too risky because DataTransfer and DataTransferItem work together to initialize each of them if DataTransfer is in external mode. Therefore, this patch makes the new constructor temporarily sets it to in external mode, then, cache usable types first, then, call `FillAllExternalData()` to make each DataTransferItem initializes its data by itself, finally, make the constructor set it to internal mode and release nsITransferable instance. This is ugly implementation but the most reasonable way for now because: - We don't need to change DataTransfer nor DataTransferItem a lot in this bug. - We don't need to duplicate any code like a loop in `CacheExternalData()`. In another bug, we should redesign DataTransfer and DataTransferItem to make DataTransferable easier to be added new constructors. Differential Revision: https://phabricator.services.mozilla.com/D19298
b259d7a34058346d36896febd5cc1c94ed63a5ca: Bug 998941 - part 2-2: Make HTMLEditor set InputEvent.dataTransfer when InputEvent.inputType is "insertFromPaste", "insertFromDrop" or "insertReplacementText" r=smaug,m_kato
Masayuki Nakano <masayuki@d-toybox.com> - Tue, 19 Feb 2019 06:33:42 +0000 - rev 459860
Push 112018 by btara@mozilla.com at Tue, 19 Feb 2019 17:39:20 +0000
Bug 998941 - part 2-2: Make HTMLEditor set InputEvent.dataTransfer when InputEvent.inputType is "insertFromPaste", "insertFromDrop" or "insertReplacementText" r=smaug,m_kato InputEvent.dataTransfer should be set to non-null when InputEvent.inputType is "insertFromPaste", "insertFromDrop" or "insertReplacementText" and editor is an HTMLEditor instance: https://rawgit.com/w3c/input-events/v1/index.html#dfn-data https://w3c.github.io/input-events/#dfn-data ("insertTranspose" and "insertFromYank" are not currently supported on Gecko.) This patch makes nsContentUtils::DispatchInputEvent() take dataTransfer value and EditorBase set it via AutoEditActionDataSetter like data value. However, we need to create other constructors of DataTransfer to create its read-only instances initialized with nsITransferable or nsAString. This will be implemented by the following patch. Differential Revision: https://phabricator.services.mozilla.com/D19297
5b4aa09a20df7251ea54dea5e01687d30cbf4401: Bug 998941 - part 2-1: Implement InputEvent.dataTransfer declared by Input Events r=smaug
Masayuki Nakano <masayuki@d-toybox.com> - Tue, 19 Feb 2019 06:32:11 +0000 - rev 459859
Push 112018 by btara@mozilla.com at Tue, 19 Feb 2019 17:39:20 +0000
Bug 998941 - part 2-1: Implement InputEvent.dataTransfer declared by Input Events r=smaug InputEvent.dataTransfer is declared by Input Events Level 1 and Level 2 (i.e., not UI Events). It's necessary for "beforeinput" event on contenteditable elements because of with some InputEvent.inputType values on contenteditable, InputEvent.dataTransfer is used instead of InputEvent.data. According to the Chrome's behavior, if InputEvent.dataTransfer is created by web apps, the DataTransfer object is mutable. Otherwise, i.e., the event represents user input, the DataTransfer object is read only. We should follow this behavior. This is enabled by default. Differential Revision: https://phabricator.services.mozilla.com/D19296
ef76c4985c1a632742814949279816207396ff38: Bug 998941 - part 1-7: Make HTMLEditor set InputEvent.data to serialized color value when InputEvent.inputType is "formatBackColor" or "formatForeColor" r=smaug,m_kato,emilio
Masayuki Nakano <masayuki@d-toybox.com> - Tue, 19 Feb 2019 06:31:28 +0000 - rev 459858
Push 112018 by btara@mozilla.com at Tue, 19 Feb 2019 17:39:20 +0000
Bug 998941 - part 1-7: Make HTMLEditor set InputEvent.data to serialized color value when InputEvent.inputType is "formatBackColor" or "formatForeColor" r=smaug,m_kato,emilio Although neither Chrome nor Safari does not set InputEvent.data when the event is caused by `document.execCommand()` with `backColor`, `foreColor` nor `hiliteColor`, Safari supports styling color with touchbar and in that case, Safari sets it (*1). Additionally, currently Safari uses `rgb()` to represents a color value and using same rule to serializing color value for CSS OM matches Safari's behavior and can represent any valid color values. This patch makes given color value parsed and then serialized with same code in style system. If the value is `currentcolor`, `inherit`, `initial` or `reset`, sets the value as-is for now. Additionally, when given value is invalid, sets the value as-is for forward compatibility. Note that automated tests will be added into input-events-exec-command.html by the last patch. 1. https://github.com/w3c/input-events/issues/94#issuecomment-461061517 Differential Revision: https://phabricator.services.mozilla.com/D19295
f4039b1e1fb6696443deb7ffd152568f6c20e240: Bug 998941 - part 1-6: Make HTMLEditor set InputEvent.data when InputEvent.inputType is "fontName" r=smaug,m_kato
Masayuki Nakano <masayuki@d-toybox.com> - Tue, 19 Feb 2019 06:30:50 +0000 - rev 459857
Push 112018 by btara@mozilla.com at Tue, 19 Feb 2019 17:39:20 +0000
Bug 998941 - part 1-6: Make HTMLEditor set InputEvent.data when InputEvent.inputType is "fontName" r=smaug,m_kato Although neither Chrome nor Safari does not set InputEvent.data value when InputEvent.inputType is "fontName", but it's easy to implement. Therefore, this patch implements it as declaration of Input Events. This patch uses given value as-is. Perhaps, this shouldn't cause any problems because such value can be set to Element.style.fontFamily without any changes. Note that automated test will be added into WPT later. Differential Revision: https://phabricator.services.mozilla.com/D19294
d392cc639292ac3a3fc4a8439f7bc55b8d03ef0e: Bug 998941 - part 1-5: Make HTMLEditor set InputEvent.data when InputEvent.inputType is "insertLink" r=smaug,m_kato
Masayuki Nakano <masayuki@d-toybox.com> - Tue, 19 Feb 2019 06:30:12 +0000 - rev 459856
Push 112018 by btara@mozilla.com at Tue, 19 Feb 2019 17:39:20 +0000
Bug 998941 - part 1-5: Make HTMLEditor set InputEvent.data when InputEvent.inputType is "insertLink" r=smaug,m_kato Although neither Chrome nor Safari does not set InputEvent.data value when InputEvent.inputType is "insertLink", but it's easy to implement. Therefore, this patch implements it as declaration of Input Events. This patch sets the value to raw href attribute value because we create <a> element without absolute URI when web apps call execCommand("createLink") with relative URI. Differential Revision: https://phabricator.services.mozilla.com/D19291
cfd766ac996375620525ee17540e80d03872cf08: Bug 998941 - part 1-4: Make editor set InputEvent.data to "ltr" or "rtl" when InputEvent.inputType is "formatSetBlockTextDirection" r=smaug,m_kato
Masayuki Nakano <masayuki@d-toybox.com> - Tue, 19 Feb 2019 06:29:38 +0000 - rev 459855
Push 112018 by btara@mozilla.com at Tue, 19 Feb 2019 17:39:20 +0000
Bug 998941 - part 1-4: Make editor set InputEvent.data to "ltr" or "rtl" when InputEvent.inputType is "formatSetBlockTextDirection" r=smaug,m_kato When InputEvent.inputType is "formatSetBlockTextDirection" or "formatSetInlineTextDirection", InputEvent.data value should be one of "ltr", "rtl", "auto" or "null". https://rawgit.com/w3c/input-events/v1/index.html#dfn-data https://w3c.github.io/input-events/#dfn-data We only supports "ltr" and "rtl" when user switches the direction with Accel + Shift + X. Therefore this patch makes EditorBase set the data to "ltr" or "rtl". Oddly, with synthesizing the shortcut keys, the command is not executed properly in the automated test. Therefore, this patch dispatches the command directly. Differential Revision: https://phabricator.services.mozilla.com/D19288
ebd32851bb24a4f09ad7c02d5de5669e5c6ce7f5: Bug 998941 - part 1-3: Make TextEditor (only when not HTMLEditor instance) set InputEvent.data to inserting string when InputEvent.inputType is "insertFromPaste", "insertFromDrop" or "insertReplacementText" r=smaug,m_kato
Masayuki Nakano <masayuki@d-toybox.com> - Tue, 19 Feb 2019 06:28:57 +0000 - rev 459854
Push 112018 by btara@mozilla.com at Tue, 19 Feb 2019 17:39:20 +0000
Bug 998941 - part 1-3: Make TextEditor (only when not HTMLEditor instance) set InputEvent.data to inserting string when InputEvent.inputType is "insertFromPaste", "insertFromDrop" or "insertReplacementText" r=smaug,m_kato https://rawgit.com/w3c/input-events/v1/index.html#dfn-data https://w3c.github.io/input-events/#dfn-data Both Input Events Level 1 and Level 2 declare that InputEvent.data should be set to inserting string only on TextEditor when InputEvent.inputType is "insertFromPaste", "insertFromPasteAsQuotation", "insertFromDrop", "insertTranspose", "insertReplacementText" or "insertFromYank". Currently, we support only "insertFromPaste", "insertFromDrop", "insertReplacementText". Therefore, this patch makes TextEditor set EditorBase::mEditActionData::mData only for them (and the instance is not HTMLEditor's). Differential Revision: https://phabricator.services.mozilla.com/D19287
7eae0724c0aa291d7439cb64dc851e0026cdebe2: Bug 998941 - part 1-2: Make editor set InputEvent.data to inserting text when it sets InputEvent.inputType to "insertText" or "insertCompositionText" r=smaug,m_kato
Masayuki Nakano <masayuki@d-toybox.com> - Tue, 19 Feb 2019 06:28:19 +0000 - rev 459853
Push 112018 by btara@mozilla.com at Tue, 19 Feb 2019 17:39:20 +0000
Bug 998941 - part 1-2: Make editor set InputEvent.data to inserting text when it sets InputEvent.inputType to "insertText" or "insertCompositionText" r=smaug,m_kato This patch makes nsContentUtils::DispatchInputEvent() support to set InputEvent.data. Whether the its value should be null or DOMString depends on InputEvent.inputType value. - https://rawgit.com/w3c/input-events/v1/index.html#overview - https://rawgit.com/w3c/input-events/v1/index.html#dfn-data - https://w3c.github.io/input-events/#overview - https://w3c.github.io/input-events/#dfn-data According to the draft specs, InputEvent.data should be always inserting text when inputType is "insertText" or "insertCompositionText" (or "insertFromCompoition" if Level 2 support is enabled). Differential Revision: https://phabricator.services.mozilla.com/D19286
7773539f3fdc460a6f1ff2f3fc66e79fb998914c: Bug 998941 - part 1-1: Implement InputEvent.data of UI Events r=smaug
Masayuki Nakano <masayuki@d-toybox.com> - Tue, 19 Feb 2019 06:27:41 +0000 - rev 459852
Push 112018 by btara@mozilla.com at Tue, 19 Feb 2019 17:39:20 +0000
Bug 998941 - part 1-1: Implement InputEvent.data of UI Events r=smaug InputEvent.data notifies web apps of inserting/inserted text with "beforeinput" and "input" events. So, this is important especially for "beforeinput" event listeners. That's the reason why we need to support this before implementing "beforeinput" event. This patch adds it into InputEvent and make it enabled by default. Differential Revision: https://phabricator.services.mozilla.com/D19285
4e0848ac59042490acf497877726e63eaf200962: Bug 1528896 - Fix about:debugging-new unavailable in local & nightly builds;r=daisuke
Julian Descottes <jdescottes@mozilla.com> - Tue, 19 Feb 2019 08:03:42 +0000 - rev 459851
Push 112018 by btara@mozilla.com at Tue, 19 Feb 2019 17:39:20 +0000
Bug 1528896 - Fix about:debugging-new unavailable in local & nightly builds;r=daisuke Differential Revision: https://phabricator.services.mozilla.com/D20287
59fad017d3c5bd70958da132f8f0b319c9899b6b: Bug 1522536 - Remove redundant address bar UI tests. r=whimboo
Dão Gottwald <dao@mozilla.com> - Tue, 19 Feb 2019 07:45:46 +0000 - rev 459850
Push 112018 by btara@mozilla.com at Tue, 19 Feb 2019 17:39:20 +0000
Bug 1522536 - Remove redundant address bar UI tests. r=whimboo Differential Revision: https://phabricator.services.mozilla.com/D20269
831ac8c662c02753c5c5c6af197b47d28d1d0e2c: Bug 1487113 - nsICacheInfoChannel.preferAlternativeDataType() should expose alt-data as optional if required - tests, r=valentin
Andrea Marchesini <amarchesini@mozilla.com> - Tue, 19 Feb 2019 07:38:44 +0000 - rev 459849
Push 112018 by btara@mozilla.com at Tue, 19 Feb 2019 17:39:20 +0000
Bug 1487113 - nsICacheInfoChannel.preferAlternativeDataType() should expose alt-data as optional if required - tests, r=valentin Differential Revision: https://phabricator.services.mozilla.com/D20201
a8406df01e9590b7fefe516b4f2a6c071d6edb6c: Bug 1487113 - nsICacheInfoChannel.preferAlternativeDataType() should expose alt-data as optional if required, r=valentin
Andrea Marchesini <amarchesini@mozilla.com> - Tue, 19 Feb 2019 07:38:31 +0000 - rev 459848
Push 112018 by btara@mozilla.com at Tue, 19 Feb 2019 17:39:20 +0000
Bug 1487113 - nsICacheInfoChannel.preferAlternativeDataType() should expose alt-data as optional if required, r=valentin Differential Revision: https://phabricator.services.mozilla.com/D20200
1e97c3573ce660cdb0b5dcf2f6f67807ac3ec0d7: Bug 1487113 - Expose nsICacheInfoChannel in Respose object for wasm content-type, r=valentin,nbp
Andrea Marchesini <amarchesini@mozilla.com> - Tue, 19 Feb 2019 07:38:03 +0000 - rev 459847
Push 112018 by btara@mozilla.com at Tue, 19 Feb 2019 17:39:20 +0000
Bug 1487113 - Expose nsICacheInfoChannel in Respose object for wasm content-type, r=valentin,nbp Differential Revision: https://phabricator.services.mozilla.com/D19823
d5bafd3c816e798da0c086687dcd0e0b6f85f777: Bug 1528814: Serialize Loadinfo for PExternalHelperApp. r=mayhemer
Christoph Kerschbaumer <ckerschb@christophkerschbaumer.com> - Mon, 18 Feb 2019 18:11:22 +0100 - rev 459846
Push 112017 by mozilla@christophkerschbaumer.com at Tue, 19 Feb 2019 17:16:48 +0000
Bug 1528814: Serialize Loadinfo for PExternalHelperApp. r=mayhemer
(0) -300000 -100000 -30000 -10000 -3000 -1000 -300 -100 -50 -20 +20 +50 +100 +300 +1000 +3000 +10000 tip