This will make being more granular with cloning easier, and we don't
need it after the previous patch.
This leaves DeclarationBlock only for the style attribute for now, we
need it for the AttrStyles stuff. But I plan to move that to
MiscContainer instead or so.
Differential Revision: https://phabricator.services.mozilla.com/D300052
nsCSSPropertyID only enumerates non custom properties, but the name suggests
otherwise. (eCSSPropertyExtra_variable only signals a custom property and does
not carry the custom name.) This mismatch has been confusing and also blocks
renaming AnimatedPropertyID to CSSPropertyId.
This patch renames nsCSSPropertyID to NonCustomCSSPropertyId to make the non
custom scope explicit. It also normalizes identifier naming (aPropID ->
aPropId, mID -> mId, etc.) for consistency.
No behavior changes intended.
Potential follow-ups:
- Move the enum to the mozilla namespace.
- Convert the enum to an enum class.
- Rename nsCSSPropertyIDSet.
Differential Revision: https://phabricator.services.mozilla.com/D271443
To distinguish whether a DOM modification is expected one or not, we
need to know what the editor is doing and what is expected result by
the mutation.
This patch adds some wrapper classes of DOM API calls and make all
callers of them except the target is very new node which has not been
connected to any DOM.
Differential Revision: https://phabricator.services.mozilla.com/D260587
This reverts commit 73d1ab198c.
Revert "Bug 1973655 - part 2: Make `HTMLEditorMutationObserver.cpp` r=m_kato"
This reverts commit 8603a23c33.
Revert "Bug 1973655 - part 1: Make the editor module not call DOM API to modify the DOM directly r=m_kato"
This reverts commit a8abe8d84c.
To distinguish whether a DOM modification is expected one or not, we
need to know what the editor is doing and what is expected result by
the mutation.
This patch adds some wrapper classes of DOM API calls and make all
callers of them except the target is very new node which has not been
connected to any DOM.
Differential Revision: https://phabricator.services.mozilla.com/D260587
This patch changes the backing prefs by relying on the tristate offered
by browser.display.document_color_use instead of
browser.display.use_system_colors. This simplifies the color
decision tree, and offers a simplified UI.
The tristate preference offered to the user is as follows:
1. "Use platform's contrast settings" (document_color_use=0)
2. "Off" - never use HCM, regardless of platform setting (document_color_use=1)
3. "On" - always use HCM, regardless of platform setting (document_color_use=2)
Option 3 also reveals a colors UI for the user to choose the palette the
browser HCM will use (bg/text/link/visited).
There are three color palettes to choose from in light of the preference
above they are:
1. WIDGET_COLORS: The OS's configured colors used by its theme.
2. HARDCODED_COLORS: Colors deemed as standard and are hard coded into
Firefox (eg. white on black text, blue and purple links).
3. PREFERENCE_COLORS: Colors that are stored in preferences and are
configurable from the colors UI (eg. browser.visited_color and
browser.display.background_color)
The decision over which palette to use is as follows:
* If we are styling browser UI -> WIDGET_COLORS
* else, if resist fingerprinting is enabled -> HARDCODED_COLORS
* else, if document_color_use==0 AND OS HCM is on -> WIDGET_COLORS
* else, if document_color_use==2 -> PREFERENCE_COLORS
* else -> HARDCODED_COLORS
Differential Revision: https://phabricator.services.mozilla.com/D211115
This patch changes the backing prefs by relying on the tristate offered
by browser.display.document_color_use instead of
browser.display.use_system_colors. This simplifies the color
decision tree, and offers a simplified UI.
The tristate preference offered to the user is as follows:
1. "Use platform's contrast settings" (document_color_use=0)
2. "Off" - never use HCM, regardless of platform setting (document_color_use=1)
3. "On" - always use HCM, regardless of platform setting (document_color_use=2)
Option 3 also reveals a colors UI for the user to choose the palette the
browser HCM will use (bg/text/link/visited).
There are three color palettes to choose from in light of the preference
above they are:
1. WIDGET_COLORS: The OS's configured colors used by its theme.
2. HARDCODED_COLORS: Colors deemed as standard and are hard coded into
Firefox (eg. white on black text, blue and purple links).
3. PREFERENCE_COLORS: Colors that are stored in preferences and are
configurable from the colors UI (eg. browser.visited_color and
browser.display.background_color)
The decision over which palette to use is as follows:
* If we are styling browser UI -> WIDGET_COLORS
* else, if resist fingerprinting is enabled -> HARDCODED_COLORS
* else, if document_color_use==0 AND OS HCM is on -> WIDGET_COLORS
* else, if document_color_use==2 -> PREFERENCE_COLORS
* else -> HARDCODED_COLORS
Differential Revision: https://phabricator.services.mozilla.com/D211115
We have more readable and faster versions (that just omit the namespace
arg).
Mostly done via sed, with a couple helpers to use the faster lookups
where possible.
Differential Revision: https://phabricator.services.mozilla.com/D181795
Currently, our editor sets `color` attribute of `<font>` to given value as-is.
However, the other browsers normalize it to `#[0-9a-z]{6}` before setting the
value, and some WTP expects the behavior. Therefore, we need to follow it for
avoiding meaningless failures.
According to WPT, the parameter can be `"transparent"` even without
`styleWithCSS`. Additionally, CSS color values are also allowed if
`styleWithCSS` is `true`. Therefore, this patch includes some fixes for them
too to avoid new failures.
Differential Revision: https://phabricator.services.mozilla.com/D167500
Currently, Gecko does not support updating `font-size` style even in the CSS
mode. Therefore, `CSSEditUtils` claims that `<font size="...">` style is not
CSS editable. Supporting it requires a lot of new code but currently we don't
have any reports about this poor support. Therefore, we should only try to
make the style editor remove `font-size` properties around selection at setting
`<font size="...">` style for now.
Additionally, Blink and WebKit does not allow to nest multiple `<font>` elements
and `<span>` elements which specify `font-size`, `font-family` or `color`. When
setting one of the styles, they split ancestors which are related to the style
at range boundaries. Then, unwrap the unnecessary elements. This makes the
DOM tree simpler, thus, the later handling will be simpler. Therefore, it's
worthwhile to follow them.
Unfortunately, there are some logic differences when handling styles in elements
having `id` attribute. Therefore, there are some new test failures, but I guess
that it does not cause any problems in web apps in the wild because it's hard to
manage editable identified elements in cross browsers and I have no idea of
motivations to do it.
Depends on D166617
Differential Revision: https://phabricator.services.mozilla.com/D167011
Blink's behavior is better than Gecko. That is, when selected range crosses
an inline element boundary, Blink shrinks selected range to select only
children, but Gecko extends selected range to cover all inline parents around
the range. E.g., when setting `abc[<i>def]</i>ghi` to `<b>`, Chrome changes it
to `abc<i><b>def</b></i>ghi`, but Gecko changes it to `abc<b><i>def</i></b>ghi`.
The Gecko's behavior is odd especially when `abc<i>[def]</i>ghi` since user
does not select the `<i>`, but Gecko wraps it in new `<b>`.
However, if the range contains an inline element entirely, e.g.,
`abc[<i>def</i>]ghi`, Chrome changes it to `abc<b><i>def</i></b>ghi` without
shrinking the range. This is reasonable too.
On the other hand, there is a case that browsers need to extend the range.
That is an parent inline element has the style of what we're setting a range to.
E.g., `abc<span style="background-color: red"><b>[def]</b></span>ghi`, user
wants to update the style attribute of the `<span>` element rather than wrapping
the selected text node with new `<span>` element in the `<b>`. Therefore,
if shrunken range starts from very beginning of a node or ends at very end of
a node and the inline parents have same style, we need extend the range to wrap
it. (Note that Gecko deletes same styles in range with
`HTMLEditor::RemoveStyleInside`. Therefore, wrapping most distant inline
element makes Gecko works as expected.)
Finally, if the containers of range boundaries are not same one, we should
extend the range to save the number of creating element. E.g.,
`<span>[abc</span> <span>def]</span>` should become
`<b><span>abc</span> <span>def</span>` rather than
`<span><b>abc</b></span><b> </b><span><b>def</b></span>`.
Note that the new expected failures are caused by the difference of selection
range after applying the style. That should be fixed by the following patch.
Depends on D164521
Differential Revision: https://phabricator.services.mozilla.com/D164522
And also making it and `BuildCSSDeclarations` return pairs of CSS property and
value with an array makes their callers simpler.
Depends on D162517
Differential Revision: https://phabricator.services.mozilla.com/D162518
This patch creates a base class of `EditorInlineStyle`, the name is
`EditorElementStyle`. It requires only attribute of HTML. However, it's
obviously different from `EditorInlineStyle`'s rule which is `mHTMLProperty`
cannot be `nullptr`. Therefore, the methods which can treat only
`EditorInlineStyle` do not want the data only whose attribute is not `nullptr`.
For solving this issue at build time, this approach is better than renaming
`EditorInlineStyle` and make it have the new mode.
Depends on D162513
Differential Revision: https://phabricator.services.mozilla.com/D162514
`CSSEditUtils::GetCSSEquivalentToHTMLInlineStyleSetInternal` may return error
which is unexpected. And the methods changed by this patch may cause destroying
editor if and only if they treat computed style. Therefore, they should be
non-static members and they should return error to make each caller avoid the
unexpected cases if necessary.
Differential Revision: https://phabricator.services.mozilla.com/D145303
This lifts a bunch of string conversions higher up the stack, but allows
us to make the servo code use utf-8 unconditionally, and seemed faster
in my benchmarking (see comment 0).
It should also make a bunch of attribute setters faster too (like
setting .cssText), now that we use UTF8String for them (we couldn't
because we couldn't specify different string types for the getter and
setters).
Differential Revision: https://phabricator.services.mozilla.com/D99590
Turns out this causes a bit of overhead when appending to an AutoString,
because Truncate() calls SetToEmptyBuffer(), which makes it go from
inline-string to buffer string, and next time we append we need to turn
the string from a buffer-based string to an inline string again, which
is some minor, but measurable, work, while profiling some
micro-benchmarks.
Probably we should make Truncate() a no-op for a zero-length string, but
I'll send that separately.
Differential Revision: https://phabricator.services.mozilla.com/D99493
Better field packing reduces it from 48 bytes to 40 bytes on 64-bit.
This reduces the memory used by each process by 336 bytes on 64-bit.
Differential Revision: https://phabricator.services.mozilla.com/D90344
Although we use CSS property for Inline table editing UI, we use edit
transaction for it unfortunately. When hiding this UI, since removing
element doesn't use edit transaction, transaction will be canceled before
showing this UI.
It is unnecessary to use edit transaction for UI, so we shouldn't use it.
Differential Revision: https://phabricator.services.mozilla.com/D90056
It should take `nsStyledElement&` instead of `const Element&`. Then, it won't
fail and will just return the result of `nsStyleElement::Style()`. Therefore,
we can get rid of it.
Note that this patch makes all its callers keep using strong pointer because
I'm not sure whether the layout APIs which are called with them are safe or
not.
Differential Revision: https://phabricator.services.mozilla.com/D87982
I realized that there is no word "whitespace" in formal English. This patch
replaces it with "white-space" in comments, and change method names to use
"WhiteSpace".
Depends on D78654
Differential Revision: https://phabricator.services.mozilla.com/D78655
Emilio Cobos Álvarez