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
Adds IpdlQueue capability to PWebGL actors. The WebGLChild, used in content processes, implements SyncProducerActor and AsyncConsumerActor because it sends (sync and async) messages and receives responses to them that it reads as async messages. The WebGLParent, used in the compositor process, is a SyncConsumerActor and AsyncProducerActor for dual reasons.
Differential Revision: https://phabricator.services.mozilla.com/D68264
NOTE: This commit does not yet include a dump of the RemoteSettings
collection and attachment. This will be added in the near future.
Differential Revision: https://phabricator.services.mozilla.com/D72418
We distinguish between two kinds of pref syntax.
- "Default pref files" are the ones that come with Firefox, constructed from
`all.js` and similar files.
- "User pref files" are the ones that get created in the user's profile.
`prefs.js` is the one that Firefox creates and overwrites every time a pref
changes. `user.js` is the one that users can create themselves.
We also have two basic kinds of pref.
- Default: `pref(...)` and the unfortunate `sticky_pref(...)`.
- User: `user_pref(...)`, which override but don't replace the default.
It only makes sense for user pref files to contain user prefs; users shouldn't
be able to create default prefs or change default pref values.
But it turns out that user pref files have been able to define default prefs
pretty much forever. This appears to be an oversight, and this commit restricts
things so that user pref files cannot contain default prefs.
The commit also fixes an incorrect comment in testParser.js.
Differential Revision: https://phabricator.services.mozilla.com/D73003
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
