This uses CheckedUnwrapStatic in places where we don't expect WindowProxy/Location
objects to show up or where we will throw an exception in that case anyway. I also
used this in the more complicated cases (the compartment situation in PromiseObject
for example is very complicated).
Differential Revision: https://phabricator.services.mozilla.com/D20155
--HG--
extra : moz-landing-system : lando
It's a global object, it doesn't have to be stored in nsFont. Pass it from the
caller like the user font set and co.
Depends on D20141
Differential Revision: https://phabricator.services.mozilla.com/D20142
--HG--
extra : moz-landing-system : lando
Even less so on reframe, where it's just unsound to do so. I had to give a value
to eSetValue_Internal, since otherwise I cannot check for its presence. I can
further special-case the reframe case if you prefer.
Differential Revision: https://phabricator.services.mozilla.com/D20133
--HG--
extra : moz-landing-system : lando
Updates the Redux selector that generates styleesheets with changes to account for the new array structure for the history of the CSS Rule selector. Also fixes the xpcshell mock to account for the same thing.
With this change, selector renames also get captured in the output stylesheet (they weren't in the previous implementation)
Differential Revision: https://phabricator.services.mozilla.com/D20148
--HG--
extra : moz-landing-system : lando
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
--HG--
extra : moz-landing-system : lando
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
--HG--
extra : moz-landing-system : lando
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
--HG--
extra : moz-landing-system : lando
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
--HG--
extra : moz-landing-system : lando
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-datahttps://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
--HG--
extra : moz-landing-system : lando
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
--HG--
extra : moz-landing-system : lando
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
--HG--
extra : moz-landing-system : lando
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
--HG--
extra : moz-landing-system : lando
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
--HG--
extra : moz-landing-system : lando
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-datahttps://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
--HG--
extra : moz-landing-system : lando
https://rawgit.com/w3c/input-events/v1/index.html#dfn-datahttps://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
--HG--
extra : moz-landing-system : lando
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
--HG--
extra : moz-landing-system : lando
Ted Campbell
Andy Wingo
Johann Hofmann
Matthew Noorenberghe
Alastor Wu
Mark Banner
Florin Strugariu
Ciure Andrei
Jan de Mooij
Emilio Cobos Álvarez
Glenn Watson
Julian Descottes
Marco Bonardo
Razvan Caliman
Masayuki Nakano
Dão Gottwald
Andrea Marchesini
Daisuke Akatsuka
Mike Hommey
Brindusan Cristian
sotaro
Luke Wagner