In this changeset, we add a preference that will simply disable F12 when it is set.
UI and tests are in followup patches
Differential Revision: https://phabricator.services.mozilla.com/D71035
There are many limitations currently, but this prototype should successfully
render most basic AVIF images. Known limitations:
- No support for any derived image items (crop, rotate, etc.)
- No support for alpha planes
- The primary image item must be an av01 (no grid support)
- HDR images aren't tone-mapped
Differential Revision: https://phabricator.services.mozilla.com/D68498
In this changeset, we add a preference that will simply disable F12 when it is set.
UI and tests are in followup patches
Differential Revision: https://phabricator.services.mozilla.com/D71035
The check for generated content in nsTextFrame is to the best of my
knowledge useless: We don't display generated content as selected when
the parent is selected anyhow, and the offsets would be wrong.
We special-case text inputs and textarea because of ::placeholder, see
the comment, but otherwise there's no reason you shouldn't be able to
find-in-page generated content / fallback / etc.
I added ForceBreakBetween so as to not create ranges that span across
shadow / anonymous content boundaries. They don't work anyway (see the
TODO in test_find.html), so it seems better to make that explicit until
we properly handle them (bug 1590379).
I added a pref just to be safe since this is long-standing behavior, but
I think it should be uncontroversial.
Differential Revision: https://phabricator.services.mozilla.com/D72447
Having to think about multiple codepaths adds complexity and it doesn't seem
like we're going to turn this pref back off anytime soon.
Differential Revision: https://phabricator.services.mozilla.com/D72040
Due to the refactored code,
browser/base/content/test/performance/browser_preferences_usage.js started
reporting more accesses to browser.cache.check_doc_frequency preference.
Differential Revision: https://phabricator.services.mozilla.com/D68319
`DeleteSelection*()` are members of `TextEditor`, but they are also used by
`HTMLEditor`. Therefore, they and pref cache members for them should be
in `EditorBase` too.
Depends on D71911
Differential Revision: https://phabricator.services.mozilla.com/D72290
Currently, all input (including user pastes) to an input field is truncated to
`maxlength`. This diff disables truncation for user pastes.
When (1) `GetEditAction` is `ePaste`, `ePasteAsQuotation`, `eDrop`, or
`eReplaceText` (ie we are dealing with a paste) and (2) `GetEditActionPrincipal`
is `nullptr` (ie we are dealing with a user edit and not a JS edit), allow a
paste without truncation. That means that, in this case, we will return
`EditActionIgnored` instead of trying to truncate the string.
This behavior is controlled by a new preference `editor.truncate_user_pastes`
which is `false` by default (set in `StaticPrefList.yaml`).
We also modify `editor/libeditor/tests/test_bug603556.html` which currently
expects the output of a paste longer than maxlength to be truncated.
Testing: Created
`editor/libeditor/tests/test_pasting_text_longer_than_maxlength.html` which
checks if a user can paste a password longer than `maxlength` and if the field
is then marked as `tooLong` (this was the original concern of the reporter of
Bug 1320229), and
`editor/libeditor/tests/test_setting_value_longer_than_maxlength_with_setUserInput.html`
which checks if `eReplaceText` has consistent behavior regardless of whether the
field has an associated editor (this test works by calling `setUserInput()`
before and after the element gets focus.) `./mach test editor/libeditor` tests
pass.
Differential Revision: https://phabricator.services.mozilla.com/D71689
CLOSED TREE
Backed out changeset 939611f65438 (bug 1630655)
Backed out changeset 2e05e81cc858 (bug 1630655)
Backed out changeset bfb074351550 (bug 1630655)
I'm not positive that the intended behavior of PreferencesWriter::Flush
is to ensure that any pending writes to the preferences file are
completed, but that seems like what it ought to be for, and it does
not look water-tight. For one, adding a sync runnable to a thread pool
will not ensure that any previously submitted runnables have completed
by the time it returns. And two, the exchange on sPendingWriteData only
guarantees that the write has started.
This change simply ensures that the write to disk has been completed
before returning.
Differential Revision: https://phabricator.services.mozilla.com/D72016
The preprocessor does not handle "# ifdef" like the C preprocessor,
and I failed to test this appropriately after restructuring the
#if... clauses. This also reverts fastShutdownStage back to 1, so
we can be confident in the data we collect.
Differential Revision: https://phabricator.services.mozilla.com/D71190