The issue in the bug is that we were returning a `DebugEnvironmentProxy` to JS
through `findPath`/`UbiNode`, and this object isn't safe to use from arbitrary JS.
This patch also changes `findPath` to not define the `node` property with `--fuzzing-safe`,
to fix similar issues elsewhere. This `DebugEnvironmentProxy` case is easy to fix, but
the engine also uses plain objects and arrays internally in some places and the `JSClass`
checks won't be sufficient for that.
Differential Revision: https://phabricator.services.mozilla.com/D169912
And also this changes `HTMLEditor::ReplaceTextWithTransaction` which is the only
user of `ReplaceTextTransaction`.
Depends on D169745
Differential Revision: https://phabricator.services.mozilla.com/D169746
This pref has been false since forever, completely untested, and I see
no references to it anywhere. I'm pretty sure having a loading image
placeholder wouldn't be web compatible, particularly in the current days
with all the lazy-loading shenanigans etc.
I propose just removing this code, and simplifying surrounding code for
clarity.
Differential Revision: https://phabricator.services.mozilla.com/D170158
* Use static prefs.
* Move IconLoad to the cpp file since it's only used in one translation
unit.
This is in preparation to make the image loads lazy.
Differential Revision: https://phabricator.services.mozilla.com/D170157
And also this patch makes its only user,
`EditorBase::InsertTextIntoTextNodeWithTransaction`, and its only caller,
`EditorBase::InsertTextWithTransaction`, return `InsertTextResult` for
returning both end of inserted text and caret point suggestion. Note that
if it's for IME composition, `CompositionTransaction` needs to update
`Selection` directly. Therefore, caret point may be unset under composition
to updating `Selection` to wrong point (it seems that
`TextEditor::HandleInsertText` can be simplified later because of this change).
Depends on D169044
Differential Revision: https://phabricator.services.mozilla.com/D169744
We're soon going to introduce a new way to distinguish between the two
windows ABIs, so we factor out compiler checks that will need to be
adjusted to limit the amount of changes down the line.
Differential Revision: https://phabricator.services.mozilla.com/D170167
The system calls of releasing a chunk of memory can be costly and should be
done outside the arena lock's critical section so that other threads aren't
blocked waiting for the lock.
Differential Revision: https://phabricator.services.mozilla.com/D166775
As expected, the try job flagged a bunch of test failures when flipping the default `delayedApply` pref to `true`. Some of these failures are legitimate issues:
- When creating a new folder in the tree under "Location", renaming the folder doesn't update its name in the Location field.
- When right clicking a bookmark in the sidebar, and creating a new folder, the folder doesn't get placed before the bookmark, i.e. the insertion point is ignored.
And as you pointed out, tags were being wiped out on blur in the Star/Toolbar panels. These issues have been fixed. The rest of the failures have been fixed in one of these ways:
- Update the test to pass regardless of `delayedApply` setting. This was the preferred method.
- Force the test to use instant apply. This was only done for tests that have an existing delayed apply counterpart.
- Force the entire test suite to use instant apply. This was only done for one file, namely `browser_bookmark_popup.js`. I'll file a bug to spin off a delayed apply version of this suite.
try job with `delayedApply` enabled: https://treeherder.mozilla.org/jobs?repo=try&revision=50e9cdb65feaec07c9519e928caf62042c3df9a4
try job with `delayedApply` disabled: https://treeherder.mozilla.org/jobs?repo=try&revision=1102b5076a79bf08a0e4b073fdf369af97a16ef7
Differential Revision: https://phabricator.services.mozilla.com/D168690
