Use some kind of prefix table to avoid storing redundant string. Also
Avoid storing an array of enum when there's a direct mapping between
enum values and loop index.
This result in a reduction of 352 byte in the resulting binary, so this
may not be worth the effort, but it was great fun to write that patch.
Differential Revision: https://phabricator.services.mozilla.com/D224494
Use some kind of prefix table to avoid storing redundant string. Also
Avoid storing an array of enum when there's a direct mapping between
enum values and loop index.
This result in a reduction of 352 byte in the resulting binary, so this
may not be worth the effort, but it was great fun to write that patch.
Differential Revision: https://phabricator.services.mozilla.com/D224494
Use some kind of prefix table to avoid storing redundant string. Also
Avoid storing an array of enum when there's a direct mapping between
enum values and loop index.
This result in a reduction of 352 byte in the resulting binary, so this
may not be worth the effort, but it was great fun to write that patch.
Differential Revision: https://phabricator.services.mozilla.com/D224494
This doesn't change behavior on its own, but it's likely we want to make
the tab focusability more complicated in bug 1895184, and this will make
changes to this area less painful.
Differential Revision: https://phabricator.services.mozilla.com/D209525
Stop supporting following the system preference, but keep macOS users
able to switch to just text controls (accessibility.tabfocus=1) in the
settings.
Change the meaning of the "Use the tab key to move focus between form
controls and links" checkbox in the Firefox settings, which was
introduced in bug 1628476 to override the system setting.
The intention, I think was that this checkbox being off resulted in
"follow the system" behavior, but that didn't quite happen due to a bug
in the preferences code (this[1] won't unset the pref, because of
this[2], which means we'll just return 0).
This patch changes it so that the checkbox instead always ignores the
system setting. There will no longer be a Firefox setting (neither in
the UI nor on about:config) that means "follow system setting".
This allows us to somewhat simplify the approach compared to the
previous patch in D196110, and keep the accessibility.tabfocus working
as the source of truth without a migration.
In the future, we can think of migrating accessibility.tabfocus to a
boolean pref, which would allow us to do the cleanups to the preferences
code that D196110 did.
[1]: https://searchfox.org/mozilla-central/rev/f1532761de0b60337e42c6c3f525288a523dabef/browser/components/preferences/main.js#2252
[2]: https://searchfox.org/mozilla-central/rev/f1532761de0b60337e42c6c3f525288a523dabef/toolkit/content/preferencesBindings.js#450,483
Differential Revision: https://phabricator.services.mozilla.com/D208602
Stop supporting following the system preference, but keep macOS users
able to switch to just text controls (accessibility.tabfocus=1) in the
settings.
Change the meaning of the "Use the tab key to move focus between form
controls and links" checkbox in the Firefox settings, which was
introduced in bug 1628476 to override the system setting.
The intention, I think was that this checkbox being off resulted in
"follow the system" behavior, but that didn't quite happen due to a bug
in the preferences code (this[1] won't unset the pref, because of
this[2], which means we'll just return 0).
This patch changes it so that the checkbox instead always ignores the
system setting. There will no longer be a Firefox setting (neither in
the UI nor on about:config) that means "follow system setting".
This allows us to somewhat simplify the approach compared to the
previous patch in D196110, and keep the accessibility.tabfocus working
as the source of truth without a migration.
In the future, we can think of migrating accessibility.tabfocus to a
boolean pref, which would allow us to do the cleanups to the preferences
code that D196110 did.
[1]: https://searchfox.org/mozilla-central/rev/f1532761de0b60337e42c6c3f525288a523dabef/browser/components/preferences/main.js#2252
[2]: https://searchfox.org/mozilla-central/rev/f1532761de0b60337e42c6c3f525288a523dabef/toolkit/content/preferencesBindings.js#450,483
Differential Revision: https://phabricator.services.mozilla.com/D208602
Much like BindToTree.
This will be useful because I need to pass more information through
UnbindFromTree() to speed up dir=auto for bug 1874040.
Differential Revision: https://phabricator.services.mozilla.com/D202215
Make it be output-only, not having that confusing in-out tab-index
parameter that is special for XUL to become focusable with
-moz-user-focus: normal. Instead, do that explicitly in
nsIFrame::IsFocusable().
Also, call it IsFocusableWithoutStyle(), since that's what it is.
Differential Revision: https://phabricator.services.mozilla.com/D195644
The warning message for deprecated math space values is tweaked a bit so
that the actual attribute value that triggered it is reported. This
provides correct message for 'negative*mathspace' values.
test_bug1845461.html, test_bug553917.html and test_bug827713-2.html are
rewritten as an internal testharness WPT test, with the following
modifications:
* Preferences are forced in the ini file, avoiding issues that happened
in the past due to inconsistent values for Nightly and Beta.
dom.use_components_shim is set to prevent the deprecation message for
the Components object and confuse the test (bug 1845910).
legacy_mathvariant_attribute and mathspace_names are disabled to
to properly test deprecated mathvariant and math space values.
* Console messages are triggered inside an iframe, allowing to test
multiple source codes for the same deprecation warning. In particular,
all mathvariant and named space values are now tested.
* Helper testMessageForMarkup/testNoMessageForMarkup functions are
introduced to easily test some markup and improve readability.
The expected message is provided as a regexp argument for more
flexibility and severity level (error or warning) is verified.
* It's not clear why the tests for InvalidChild don't test msup or why
they use this specific number of children. Keep them but add new ones
for msub/msub/msubsup with the usual number of children.
Differential Revision: https://phabricator.services.mozilla.com/D185399
The ToInteger function is not very strict, so scriptlevel parsing
currently accepts invalid values like "+-1", "--1", "+z1", "+ 1",
"2.0", "-3\"" or "200px". To fix that, we perform an extra check
during parsing to ensure that the part after the optional leading
sign is really an <unsigned> number (string of digits).
This patch also fixes some issues in attribute-mapping-002.html
(previously attached attribute not removed, not handling
none/mprescripts specially, gather checks in one loop) and add
more test cases such as the ones mentioned above. The situation of
leading/trailing whitespace is unclear, so testing for things like
" +1" and "+1 " is ignored for now.
Differential Revision: https://phabricator.services.mozilla.com/D156160
This commit removes the runtime flags and related code for the
scriptminsize and scriptsizemultiplier, which have been disabled by
default for a while. The hardcoded default values
kMathMLDefaultScriptSizeMultiplier and kMathMLDefaultScriptMinSizePt
are still used in some places and are preserved for now.
Differential Revision: https://phabricator.services.mozilla.com/D157426
In MathML Core, the recommendation is to directly use the proper
character from the Mathematical Alphanumeric Symbols instead of the
mathvariant attribute. The exception is for automatic italicization on
single-char `<mi>` element. This is implemented via a new text-transform
value "math-auto" [1] which is the default on the `<mi>` element. The
mathvariant attribute is now restricted to that element and to value
"normal" in order to force upright text instead [2]. This CL implements
this restriction together with that new text-transform value under the
mathml.legacy_mathvariant_attribute.disabled flag.
Some legacy MathML cases where math-auto alone does not work are
still handled via MathMLTextRunFactory.
[1] https://w3c.github.io/mathml-core/#new-text-transform-values
[2] https://w3c.github.io/mathml-core/#the-mathvariant-attribute
Differential Revision: https://phabricator.services.mozilla.com/D172395
In MathML Core, the recommendation is to directly use the proper
character from the Mathematical Alphanumeric Symbols instead of the
mathvariant attribute. The exception is for automatic italicization on
single-char `<mi>` element. This is implemented via a new text-transform
value "math-auto" [1] which is the default on the `<mi>` element. The
mathvariant attribute is now restricted to that element and to value
"normal" in order to force upright text instead [2]. This CL implements
this restriction together with that new text-transform value under the
mathml.legacy_mathvariant_attribute.disabled flag.
Some legacy MathML cases where math-auto alone does not work are
still handled via MathMLTextRunFactory.
[1] https://w3c.github.io/mathml-core/#new-text-transform-values
[2] https://w3c.github.io/mathml-core/#the-mathvariant-attribute
Differential Revision: https://phabricator.services.mozilla.com/D172395
In MathML Core, the recommendation is to directly use the proper
character from the Mathematical Alphanumeric Symbols instead of the
mathvariant attribute. The exception is for automatic italicization on
single-char `<mi>` element. This is implemented via a new text-transform
value "math-auto" [1] which is the default on the `<mi>` element. The
mathvariant attribute is now restricted to that element and to value
"normal" in order to force upright text instead [2]. This CL implements
this restriction together with that new text-transform value under the
mathml.legacy_mathvariant_attribute.disabled flag.
Some legacy MathML cases where math-auto alone does not work are
still handled via MathMLTextRunFactory.
[1] https://w3c.github.io/mathml-core/#new-text-transform-values
[2] https://w3c.github.io/mathml-core/#the-mathvariant-attribute
Differential Revision: https://phabricator.services.mozilla.com/D172395
Instead, lazily schedule evaluation of them before styling, much like we
were doing for SVG.
A subtle tweak is that we only remain scheduled while in the document.
This allows us to use the "in document" bit plus the "mapped attributes
dirty" bit to know our scheduled status. It also prevents doing silly
work for disconnected elements, and having to do hashmap lookups on
adoption and node destruction.
Differential Revision: https://phabricator.services.mozilla.com/D181549
Instead, lazily schedule evaluation of them before styling, much like we
were doing for SVG.
A subtle tweak is that we only remain scheduled while in the document.
This allows us to use the "in document" bit plus the "mapped attributes
dirty" bit to know our scheduled status. It also prevents doing silly
work for disconnected elements, and having to do hashmap lookups on
adoption and node destruction.
Differential Revision: https://phabricator.services.mozilla.com/D181549
ParseAttribute ideally would be const (see bug 1829138), but the SVG and
SMIL code is rather messy. Still, now that BeforeSetAttr can't really
fail, swapping the order of ParseAttribute and BeforeSetAttr shouldn't
really change behavior.
Sorry for the extra `virtual` keyword removal and such. I had to do this
one by hand unlike the dependent bugs, and I went a bit drive-by, lmk if
you want me to split those changes.
Differential Revision: https://phabricator.services.mozilla.com/D176086
Same rg + sed shenanigans as the first patch.
There were two that could fail, both due to OOM:
* HTMLInputElement::AfterSetAttr: If we fail (only in the type=range
case) we end up with an old value without it being clamped by
min/max/step.
* HTMLBodyElement::AfterSetAttr: If we fail we won't peek up the
DocShell's frame margins and styling could be incorrect.
That seems better than having to deal with broken states after we've
already set the attribute.
Depends on D176069
Differential Revision: https://phabricator.services.mozilla.com/D176070
rg BeforeSetAttr -l | xargs sed -i 's/nsresult BeforeSetAttr/void BeforeSetAttr/g'
rg ::BeforeSetAttr -l | xargs sed -i 's/nsresult \(.*\)::BeforeSetAttr/void \1::BeforeSetAttr/g'
Plus trivial fixes, plus clang-format.
The only meaningful changes are in nsXULElement::BeforeSetAttr. Two
things could fail:
chromemargin: I removed it because we don't use the parsed attribute any
other place than here:
https://searchfox.org/mozilla-central/rev/31f5847a4494b3646edabbdd7ea39cb88509afe2/dom/xul/ChromeObserver.cpp#136
And that deals just fine with it not being parsed.
usercontextid: We have a debug assertion that we don't dynamically change it.
I kept it but I don't think it's worth failing to set the attribute on release for that
Differential Revision: https://phabricator.services.mozilla.com/D176069
