Actually, spellchecker always allocates the heap to get text from text node. But it is unnecessary to allocate another heap here since `WordSplitState` walks text only and it is stack class.
If text is in '<textarea>', text node may be too large, so we shouldn't allocate memory to walk character in `WordSplitState` if possible. Because `TextNodeContainsDOMWordSeparator` will be called per input.
And `mWordUtil` is unused, so we should remove it.
Differential Revision: https://phabricator.services.mozilla.com/D42257
--HG--
extra : moz-landing-system : lando
This is now dead code which will be kept alive by the vtable,
and introduces needless overhead inside the permission manager.
Differential Revision: https://phabricator.services.mozilla.com/D42207
--HG--
extra : moz-landing-system : lando
Original regression was by bug 1362858, and bug 1418629 wasn't enough to fix.
By bug 1362858, we use `CHAR_CLASS_SEPARATOR` in additional to DOM word separator. But some characters such as single quote, `@` and etc are `CHAR_CLASS_SEPARATOR`, so we may check spell by incomplete word.
We shouldn't separate word by characters that is email part, URL part or conditional punctuation.
And I also update test cases for this situation. `<textarea>` is better for spell checking since it can has multiple anonymous text nodes.
Differential Revision: https://phabricator.services.mozilla.com/D39829
--HG--
extra : moz-landing-system : lando
My preference was to annotate most of the failing tests with `fail-if` so that
if they start passing, the `fail-if` needs to be removed and they need to keep
passing. That doesn't work for tests that timeout, or which trigger failures
from their cleanup functions, however, so those tests need skip-if. And tests
with fail in their cleanup functions likely leave the browser in an
inconsistent state for subsequent tests, anyway, so really should be skipped
regardless.
There are some remaining tests which still fail because of crashes. I chose
not to skip them here, but to fix the crashes in separate bugs instead.
Differential Revision: https://phabricator.services.mozilla.com/D38247
--HG--
extra : rebase_source : 39ba8fec2e882cfe577c5f2b58ab7e4b461f1178
Some `nsRange` static methods are useful in `StaticRange` and some of them
are used in a lot of places but not related to `nsRange` directly. This
patch moves them into new static method only class, `mozilla::RangeUtils`.
Differential Revision: https://phabricator.services.mozilla.com/D35142
--HG--
extra : moz-landing-system : lando
This patch is based on the patch created by Makoto Kato-san.
`Range` and `StaticRange` have common base interface, `AbstractRange`.
https://dom.spec.whatwg.org/#abstractrange
This interface has simply returns `startContainer`, `endContainer`,
`startOffset`, `endOffset` and `collapsed`.
Different from the original patch's approach, this patch moves related
members in `nsRange` to `AbstractRange` since this approach avoids
virtual call cost. Additionally, this patch makes them not throw as
declared by the spec. As far as I know, the destruction cost of
`ErrorResult` may appear in profile so that we should avoid creating
the instance if we can avoid it.
Unfortunately, the instance size of `nsRange` becomes larger with this
patch. The size is changed from 176 to 184. I.e., now, `nsRange`
requires bigger chunk.
Differential Revision: https://phabricator.services.mozilla.com/D35140
--HG--
extra : moz-landing-system : lando
No one includes `license.hunspell`, so we don't need our custimze block (`#include "config.h"`)
Also, some files isn't updated to 1.6.1, so we should update it.
Depends on D35516
Differential Revision: https://phabricator.services.mozilla.com/D35517
--HG--
extra : moz-landing-system : lando