Now that all frames store the caller's frame pointer, we can add it to `CommonFrameLayout`
and get rid of `FramePointerOffset`.
This also removes `JitFrameLayout::unused_`. This has to happen at the same time so that
`sizeof(JitFrameLayout)` doesn't change (a lot of code depends on that for alignment).
`JitFrameLayout` is now aligned on the frame pointer instead of the return address.
This lets us simplify some of the Wasm stubs code (especially for ARM64) where we had
to workaround the old aligned-after-return-address invariant.
Differential Revision: https://phabricator.services.mozilla.com/D149760
This renames the `numActualArgs_` field to `unused_` and stores a constant there
for now. The next patch will remove this field and simultaneously add the frame
pointer to `CommonFrameLayout`, preserving the current `JitFrameLayout` size.
Differential Revision: https://phabricator.services.mozilla.com/D149759
Pending further changes iff we want to do them (like comment 5), this is the
right thing to do.
I'm not a fan of comment 5 since in the past I've been bitten by Wayland
compositors not comparing stuff case-insensitively, so making everything
lowercase is probably simpler.
Differential Revision: https://phabricator.services.mozilla.com/D149911
I could reproduce the intermittent locally and when it occurs, the initial editor actually didn't have focus.
I think that what happens is that we hit a race condition where the focus is stolen by the initial editor after we clicked on a new stylesheet
and switched to a new editor.
Differential Revision: https://phabricator.services.mozilla.com/D149952
Actually, GeckoView registers both desktop and mobile actor for `<select>`
element. It is unnecessary to use desktop's `<select>` actor.
But, if GeckoView doesn't register desktop's `<select>` actor,
`layout/forms/test/test_select_reframe.html` will be failure since GV doesn't
handle `mozhidedropdown` that is a event when the control is unbinded from
layout tree.
So we need to handle this for this situation that is one of dismissed cases.
Differential Revision: https://phabricator.services.mozilla.com/D149526
gcc -std=c++20 (but not clang -std=c++20) complains about template class definitions that specify the template parameter on the class constructor.
In file included from /builds/worker/workspace/obj-build/dist/include/nsDisplayList.h:43,
from /builds/worker/workspace/obj-build/dist/include/mozilla/layout/RemoteLayerTreeOwner.h:17,
from /builds/worker/workspace/obj-build/dist/include/mozilla/dom/BrowserParent.h:23,
from /builds/worker/checkouts/gecko/accessible/ipc/other/RemoteAccessible.cpp:13:
/builds/worker/workspace/obj-build/dist/include/mozilla/layers/BSPTree.h:30:18: error: expected ')' before '*' token
| BSPPolygon<T>(T* aData, gfx::Polygon&& aGeometry)
| ~ ^
Differential Revision: https://phabricator.services.mozilla.com/D149813
For `--backgroundtask ... --jsdebugger` invocations, the devtools
profile is kept inside the ephemeral background profile. This means
that breakpoints, etc are not preserved across repeated debugging
invocations. This change eases the debugging process.
Differential Revision: https://phabricator.services.mozilla.com/D145893
The preceding call of `InsertBRElement` may collapse selection at the inserted
padding `<br>` element. Only when calling `HandleInsertParagraphInParagraph`,
`InsertParagraphSeparatorAsSubAction` uses `Selection`. So, only in this case,
we need to recompute the point to split for keeping current (odd) behavior.
Note that in normal cases, using `atStartOfSelection` gets same result.
However, if there are some invisible nodes such as comment nodes, doing it
may change the behavior. For now, we should keep the current behavior. It
should be sorted out when we make it stop inserting `<br>` elements for the
preparation of split without checking whether it's actually necessary.
Differential Revision: https://phabricator.services.mozilla.com/D149101
The expectations are exactly same as Chrome's behavior. And checked by my
hands briefly, Safari also behaves as same as Chrome.
Differential Revision: https://phabricator.services.mozilla.com/D149100
It touches `Selection` redundantly (i.e., immediately after that, it or its
caller collapse `Selection`). So we can just stop it because we can ignore
the cases when the handling fails after the redundant `Selection` update and
it can be caused by tricky things with the mutation event listeners.
Note that without changing `SplitNodeResult` a lot, we cannot make it return
`SplitNodeResult`, and currently there is no motivation to do it because the
only caller does not need the detail of the split. Therefore, I give up doing
it.
Differential Revision: https://phabricator.services.mozilla.com/D149099
In Linux TV test, as thare is case that the input filed lost the focus until
showing popup, timeout failure happens since the expected poup never be shown.
To avoid this, if losing the focus, retry setup to open popup.
Differential Revision: https://phabricator.services.mozilla.com/D149713
I tried to make the latter half preparation to call
`HTMLEditor::SplitParagraphWithTransaction`, but I cannot make it cleaner
because it needs to return `HTMLBRElement*` and `EditorDOMPoint` with maybe
modifying the DOM tree. So, I keep it as-is, but I make replace the unnecessary
duplicated `EditorDOMPoint` with the original one which is adjusted to avoid
to create new empty link in the right paragraph.
Differential Revision: https://phabricator.services.mozilla.com/D149096
Using the wide scope `EditorDOMPoint pointToInsertBR` makes it harder to read.
Although this duplicates a call of `HTMLEditor::InsertBRElement` and a couple of
post processing, but I think that it's easier to read/understand.
Differential Revision: https://phabricator.services.mozilla.com/D149094
moz_inputhistory can accept empty string as its input column.
WHERE Clause of SQL getting Adaptive History has
`:searchString BETWEEN i.input AND i.input || X'FFFF'`
condition, but it will be true even if the input is empty string.
This is the cause of this bug.
So, we add one more condition checking whether the input is empty string to
resolve this problem.
Differential Revision: https://phabricator.services.mozilla.com/D149933
If it needs to insert a `<br>` but the editor does not want to create new
paragraph, its caller should be default to insert a `<br>` element. Rather
than checking this at inserting `<br>` element, it should do it at considering
the place to insert the new `<br>`.
Differential Revision: https://phabricator.services.mozilla.com/D149093
Right now we rely on the menulist to be injected by hand in all the
relevant windows. Instead create it lazily, making the select code more
standalone.
The DevTools window was missing it, for example.
Differential Revision: https://phabricator.services.mozilla.com/D149620
It is difficult for linters to analyse loops around functions which get symbols. Instead, use
the symbols directly from the imported module.
Differential Revision: https://phabricator.services.mozilla.com/D149717
This rewrites the lazy getters, so that the lazy getter is defined at the call point, which makes it
easier for linters to understand what is being defined.
In some cases, the log is not being used, so the definition code is removed.
Differential Revision: https://phabricator.services.mozilla.com/D149716