This was done automatically replacing:
s/mozilla::Move/std::move/
s/ Move(/ std::move(/
s/(Move(/(std::move(/
Removing the 'using mozilla::Move;' lines.
And then with a few manual fixups, see the bug for the split series..
MozReview-Commit-ID: Jxze3adipUh
Categories are useful to indicate: This much % of time was spent in this category.
The EVENTS category isn't a very good match for this. This category is currently
only set on labels of functions that handle the processing of an event. But
those functions are usually closer to the base of the stack, and the actual CPU
work during the processing of an event is usually in another category closer to
the top of the stack, e.g. in JS if we're running an event handler, or in LAYOUT
if we're hit testing the position of the event.
This changeset removes the EVENTS category and replaces all uses of it with the
OTHER category.
MozReview-Commit-ID: JPm5hQiBkvp
--HG--
extra : rebase_source : 66f8ee003d2f70111f4cff16d6e2d906ef4bf10b
Categories are useful to indicate: This much % of time was spent in this category.
The EVENTS category isn't a very good match for this. This category is currently
only set on labels of functions that handle the processing of an event. But
those functions are usually closer to the base of the stack, and the actual CPU
work during the processing of an event is usually in another category closer to
the top of the stack, e.g. in JS if we're running an event handler, or in LAYOUT
if we're hit testing the position of the event.
This changeset removes the EVENTS category and replaces all uses of it with the
OTHER category.
MozReview-Commit-ID: JPm5hQiBkvp
--HG--
extra : rebase_source : fb1ff20aeebb7ac494227e62ba2101039578808c
Deleted the old Chrome DataTransfer constructor because it was only used
for some tests which can be easily changed. Added a new constructor that
is not Chrome Only.
MozReview-Commit-ID: HjcgafSiWfM
--HG--
extra : rebase_source : 987afee2b6568bcf15c2ad99e715e6e0a112e3ed
Categories are useful to indicate: This much % of time was spent in this category.
The EVENTS category isn't a very good match for this. This category is currently
only set on labels of functions that handle the processing of an event. But
those functions are usually closer to the base of the stack, and the actual CPU
work during the processing of an event is usually in another category closer to
the top of the stack, e.g. in JS if we're running an event handler, or in LAYOUT
if we're hit testing the position of the event.
This changeset removes the EVENTS category and replaces all uses of it with the
OTHER category.
MozReview-Commit-ID: JPm5hQiBkvp
--HG--
extra : rebase_source : 34fb2ca94151403a6d7ffd5a8b840f00a8bb4afb
When we implement InputEvent.inputType, we need to set a stack class to record
which edit action is currently handled. However, currently, we call smaller
jobs as edit action. For example, when user types a character at selecting
some characters, then, EditAction::deleteSelection is performed first, then,
EditAction::insertText is performed. However, for the InputEvent.inputType,
we need inserText information. So, for making new enum EditAction, we need
to rename current EditAction to EditSubAction.
And also this renames related stuff:
EditorBase::mIsInEditAction -> EditorBase::mIsInEditSubAction
EditorBase::IsInEditAction() -> EditorBase::IsInEditSubAction()
EditorBase::mAction -> EditorBase::mTopLevelEditSubAction
TextEditRules::mTheAction -> TextEditRules::mTopLevelEditSubAction
EditorBase::StartOperation() ->
EditorBase::OnStartToHandleTopLevelEditSubAction()
EditorBase::EndOperation() ->
EditorBase::OnEndHandlingTopLevelEditSubAction()
AutoRules -> AutoTopLevelEditSubActionNotifier
RulesInfo -> EditSubActionInfo
MozReview-Commit-ID: cvSkPUjFm1
--HG--
extra : rebase_source : baf527a3e353b7a8ebe9a46be2243b059c500234
Changed DOMEventMarkerPayload to use tracing markers to be able to see unfinished
DOMEvents in the profiler. DOMEventMarkerPayload was containing both start and
end timestamps and we were adding it once DOMEvent finishes. Now, we are adding
two tracing markers. Once the event starts and once the event ends. That makes the
start of the event visible on the profiler.
MozReview-Commit-ID: Gak6dGsgMDt
--HG--
extra : rebase_source : 6d2c9930964503a4865b92d85a0437e33acf8dc7
Now that BeginUpdate is useless for the UPDATE_STYLE case, we don't need the
update mechanism at all. Just ensure that ApplicableStylesChanged is called on
the pres shell via the relevant RuleChanged, etc. notifications.
There's a big hidden gotcha here. nsIDocument::BeginUpdate does put a script
blocker on the stack for these updates. However it's not needed, since no script
can run during these notifications (only the stylesheet events we post for
devtools, but those use AsyncEventDispatcher and PostDOMEvents, so they don't
try to run immediately).
nsIDocument::BeginUpdate also does XBL binding attached queue stuff, but we
can't change bindings during these notifications anyway, so it also doesn't
matter.
MozReview-Commit-ID: HJvK6zQfloh
This fixes a bounds check assertion on the array access into the touch event's
touch list.
I don't know why we have a touch event with no touches. Maybe it's an internal
touch event?
MozReview-Commit-ID: 8MWF1SMAfor
--HG--
extra : rebase_source : 1b2477d5679d9f1a1adef680911263ff49a89da9
We don't want to gesture activate for key and mouse/pointer events sent to
editable elements, as that would mean user interaction intended as text input
could start media playback, which would not likely be the user's intention.
MozReview-Commit-ID: VemPfpuziz
--HG--
extra : rebase_source : b2267f5ae2c9f0f6626f622bc98e3c5f18faf8bb
We don't want key presses of keys which are likely to be intended to be
interaction with the browser or OS to gesture activate documents and unblock
autoplay videos. So don't gesture activate for key events which are modifier
keys, or which don't have a pseudo char code.
MozReview-Commit-ID: 6uyPmlzbAvg
--HG--
extra : rebase_source : 8be949228b666a2ff54385f14b38b8f89459b1e2
extra : source : 59979388ba67d5fbfa8f3801bb65ac0fd2a49408
