EventStateManager::PostHandleEvent would do the same thing, but need to handle
the cases that PresShell is destroyed and frame is destroyed in
pointerup/pointercancel event listener.
The former case would be handled in D102403. For the latter case, we allow
EventStateManager::PostHandleEvent to handle pointerup/pointercancel event while
frame is no longer available in this patch.
Differential Revision: https://phabricator.services.mozilla.com/D102404
Found a possible leak from running layout/base/tests/test_bug993936.html after
enable implicit pointer capture for touch event. The test synthesize touchstart
and touchmove event, but no touchend, so we don't run the release steps and the
PointerCaptureInfo still hold a reference to Element which cause the leak.
This could also possible happens in real world, for example, user touch a page
with finger that triggers pointer capture, and then tab get closed before touch
is released.
Differential Revision: https://phabricator.services.mozilla.com/D102403
Geckodriver doesn't support touch input yet, so convert new added the touch tests
into mochitest, these mochitest wpt could be removed once we could pass the
corresponding tests in wpt.
Depends on D101667
Differential Revision: https://phabricator.services.mozilla.com/D102044
Calling setPointerCapture or releasePointerCapture in pointerup event handler would
throw error due to the active pointer is removed in PreHandlerEvent which is too
early. So defer removing active pointer to PostHandeEvent to make the active pointer
available in pointerup or pointercancel event handler.
This patch adds WPTs which has been verified on Chrome. geckodriver doesn't support
touch input yet, so mark tests for touch as expected ERROR for now.
Differential Revision: https://phabricator.services.mozilla.com/D101667
When mouse button is clicked outside a link element but caret is positioned
start or end of the link, our traditional behavior keeps inserting new content
into the link. But this is different from the other browsers, and it does
not make sense to treat such selection change is intended to keep typing in
the link element.
Therefore, this patch makes `TypeInState::OnSelectionChange()` handle
selection change reason is `mousedown` and `mouseup` cases. However,
it cannot know whether the event was fired in the parent link element or
not. Therefore, this patch makes `HTMLEditorEventListener` notifies
`TypeInState` of mouse events via `HTMLEditor`.
Differential Revision: https://phabricator.services.mozilla.com/D101001
We always compute the tabindex value, so just return it to the caller
all the time. This allows us to use early-returns which makes the code a
bit easier to follow.
This patch shouldn't change behavior.
Differential Revision: https://phabricator.services.mozilla.com/D100423
Resetting focus would also clear selection on editable element, so get
current selected text before moving focus to findbar to make
prefill-with-selection work if the content is loaded in chrome process.
Differential Revision: https://phabricator.services.mozilla.com/D89557
Before deleting `IMEState::Enabled::PLUGIN`, let's make it an enum class
for making the change safer. Almost all of this change is done by
"replace" of VSCode.
Differential Revision: https://phabricator.services.mozilla.com/D100100
This patch add a way to track remote target for mouse capturing. The tracking
remote target will be reset when capturing content is changed or
ReleaseCapturingContent() is called.
In order to make `mouseup` would also be dispatched to correct remote target, we
do ReleaseCapturingContent in EventSetateManager::PostHandleEvent, instead of
in nsIFrame::HandleRelease.
Differential Revision: https://phabricator.services.mozilla.com/D98592
This patch add a way to track remote target for mouse capturing. The tracking
remote target will be reset when capturing content is changed or
ReleaseCapturingContent() is called.
In order to make `mouseup` would also be dispatched to correct remote target, we
do ReleaseCapturingContent in EventSetateManager::PostHandleEvent, instead of
in nsIFrame::HandleRelease.
Differential Revision: https://phabricator.services.mozilla.com/D98592
This patch add a way to track remote target for mouse capturing. The tracking
remote target will be reset when capturing content is changed or
ReleaseCapturingContent() is called.
In order to make `mouseup` would also be dispatched to correct remote target, we
do ReleaseCapturingContent in EventSetateManager::PostHandleEvent, instead of
in nsIFrame::HandleRelease.
Differential Revision: https://phabricator.services.mozilla.com/D98592
Resetting focus would also clear selection on editable element, so get
current selected text before moving focus to findbar to make
prefill-with-selection work if the content is loaded in chrome process.
Differential Revision: https://phabricator.services.mozilla.com/D89557
This passes the tests which are in https://github.com/web-platform-tests/wpt/pull/26472
Because of complications in #include handling, AbortFollower needs to be in a different
header file than AbortSignal, yet AbortSignalImpl needs to be available when AbortFollower is used.
Another option would have been to make DOMEventTargetHelper.h a bit different and uninline some hot methods
there or move them to another file, but that would have been equally bad and Abort* is used way less often.
AbortFollower and AbortSignalImpl are thus just moved to a new header.
Memory management is such that Listener in EventListenerManager owns the possible ListenerSignalFollower
instance which follows the relevant signal. In order to be able remove event listener,
ListenerSignalFollower has many similar fields as Listener.
ListenerSignalFollower can't easily have just a pointer to Listener* since Listener isn't stored as a pointer
in EventListenerManager.
ListenerSignalFollower is cycle collectable so that Listener->ListenerSignalFollower can be traversed/unlinked
and also strong pointers in ListenerSignalFollower itself can be traversed/unlinked.
There is an XXX in the .webidl, since nullability of signal is unclear in the spec pr.
Whether or not it ends up being nullable shouldn't change the actual C++ implementation.
Differential Revision: https://phabricator.services.mozilla.com/D97938
And have it mirror in the parent process more automatically.
The docShellIsActive setter in the browser-custom-element side needs to
be there rather than in the usual DidSet() calls because the
AsyncTabSwitcher code relies on getting an exact amount of notifications
as response to that specific setter. Not pretty, but...
BrowserChild no longer sets IsActive() on the docshell itself for OOP
iframes. This fixes bug 1679521. PresShell activeness is used to
throttle rAF as well, which handles OOP iframes nicely as well.
Differential Revision: https://phabricator.services.mozilla.com/D96072
This is another regression by bug 1658948 and Windows only.
When user script calls element.focus() during keyboard event, our TSF client
implementation commits composition string.
It is unnecessary to call SetInputContext when real keybaord event is fired.
Because,
- If keybaord event is fired, virtual keybaord is already shown
- We don't open virtual keyboard when physical keyboard is available on Android
So I shouldn't call SetInputContext on user interaction by keyboard.
Differential Revision: https://phabricator.services.mozilla.com/D98882
mLastOverFrame is a WeakFrame, it could possibly be nulled-out, for example
after restyling, and the sub-document won't be able to be notified the mouse
leaving.
Differential Revision: https://phabricator.services.mozilla.com/D98787
Sorry for this big patch.
This makes `WidgetQueryContentEvent::Reply` is stored with `Maybe` to get
rid of `WidgetQueryContentEvent`. And `Reply` stores offset and string
with `Maybe` and ``OffsetAndData<uint32_t>`, and also tentative caret offset
with `Maybe`. Then, we can get rid of `WidgetQueryContentEvent::NOT_FOUND`.
Note that I tried to make `OffsetAndData` have a method to create `NSRange`
for cocoa widget. However, it causes the column limit`to 100 or longer
and that causes unrelated changes in `TextEvents.h` and `IMEData.h`.
Therefore, I create an inline function in `TextInputHandler.mm` instead.
Differential Revision: https://phabricator.services.mozilla.com/D98264
Usually, IME sets selection and considers candidate list position at starting
new composition. However, Apple Japanese IME sometimes consider the candidate
list position at retrieving the character rects before setting selection.
Therefore, we need to store last commit string's character rects, but don't
need to store it in long time because Kakutei-Undo is supported by Japanese
IMEs and they work only immediately after committing a composition. E.g.,
after moving caret, it won't be available.
Depends on D97838
Differential Revision: https://phabricator.services.mozilla.com/D97839
`IMEStateManager::OnFocusMovedBetweenBrowsers()` is called by
`BrowserParent::UnsetTopLevelWebFocusAll()` from
`nsFocusManager::WindowRaised()` when a window becomes active from the app
itself is deactivated. At this time, `aBlur` is set to the last
`BrowserParent` which had focus before inactivated, and `aFocus` is always
`nullptr` because of assuming the following code in
`nsFocusManager::WindowRised()` will call `OnFocusMovedBetweenBrowsers()` to
set focus to focused browser part at that time. However, the first call of
`OnFocusMovedBetweenBrowsers()` requesting to commit composition if there is
a composition because it believes that the focused process is just blurred and
nobody would take focus.
So, `IMEStateManager::OnFocusMovedBetweenBrowsers()` needs to wait to handle
its jobs until another its call for setting focus to the remote process when
the app is activated.
Therefore, this patch makes `IMEStateManager` manage whether the process is
active or not from the point of view of IME handling. I.e., in the main
process, it can be treated as active when a window is the focused window in
the desktop, and in a content process, it can be treated as active when the
process has focus. So, this is managed by `sIsActive`.
Then, `IMEStateManager` needs information of first blurred `BrowserParent`
and `last focused `BrowserParent` in the case for putting off to handle its
jobs. Therefore, this patch adds
`IMEStateManager::sPendingFocusedBrowserSwitchingData` to manage them.
Finally, this patch makes `IMEStateManager::OnFocusMovedBetweenBrowsers()`
cancel pending handling if first blurred `BrowserParent` and last focused
`RrowserParent`are same. And also making
`IMEStateManager::OnFocusChangeInternal()` call `OnFocusMoveBetweenBrowsers()`
if there is pending jobs of `OnFocusMoveBetweenBrowsers()`.
UThis requires an API to create the case to all windows deactive to test it.
However, there is no way to do that. Therefore, this patch does not have
any tests.
Differential Revision: https://phabricator.services.mozilla.com/D97687
`keyup` event of `Alt` key should be fired in content process even if it'll
activate the menubar, and it should be cancelable as same as before enabling
e10s.
Unfortunately, the new test is complicated even they test simple things.
The reason is, this test requires the window running it is the active window.
However, the window may become inactive on Linux, therefore, this test
needs to manage window state by itself.
And another reason is, after inactivating the menubar, somebody keeps
consuming keyboard events in chrome. Although, popups shouldn't be
opened by this test, but waiting all popups hidden makes the remaining
intermittent failure gone. Therefore, this patch waits all popups become
hidden after inactivating the menubar and before new test.
Differential Revision: https://phabricator.services.mozilla.com/D95984
The browser currently only enables plugin behavior for Flash and our internal test plugins. This patch replaces support for those plugins with a simple fallback that shows a transparent region where the plugin would have been. It removes the file system search(es) for the plugin dynamic libraries and short-circuits the logic to determine if plugins should do something special -- all implementations now behave the same in the presence of plugin elements.
The new behavior is:
1. If the <object> or <embed> element lists a type of something other than "x-shockwave-flash" or "x-test" then the behavior is unchanged. This means that non-plugin types behave properly and unknown types (for example, typos) are also unaffected (they reduce to 0x0 elements).
2. If the <object> element has an HTML fallback in the DOM (see spec for <object> elements) then the fallback is always shown.
3. Otherwise, the element is shown as a transparent region with the size specified in attributes.
Differential Revision: https://phabricator.services.mozilla.com/D95902
The browser currently only enables plugin behavior for Flash and our internal test plugins. This patch replaces support for those plugins with a simple fallback that shows a transparent region where the plugin would have been. It removes the file system search(es) for the plugin dynamic libraries and short-circuits the logic to determine if plugins should do something special -- all implementations now behave the same in the presence of plugin elements.
The new behavior is:
1. If the <object> or <embed> element lists a type of something other than "x-shockwave-flash" or "x-test" then the behavior is unchanged. This means that non-plugin types behave properly and unknown types (for example, typos) are also unaffected (they reduce to 0x0 elements).
2. If the <object> element has an HTML fallback in the DOM (see spec for <object> elements) then the fallback is always shown.
3. Otherwise, the element is shown as a transparent region with the size specified in attributes.
Differential Revision: https://phabricator.services.mozilla.com/D95902
`keyup` event of `Alt` key should be fired in content process even if it'll
activate the menubar, and it should be cancelable as same as before enabling
e10s.
Unfortunately, the new test is complicated even they test simple things.
The reason is, this test requires the window running it is the active window.
However, the window may become inactive on Linux, therefore, this test
needs to manage window state by itself.
And another reason is, after inactivating the menubar, somebody keeps
consuming keyboard events in chrome. Although, popups shouldn't be
opened by this test, but waiting all popups hidden makes the remaining
intermittent failure gone. Therefore, this patch waits all popups become
hidden after inactivating the menubar and before new test.
Differential Revision: https://phabricator.services.mozilla.com/D95984
for consistency with ErrorResult and dom::Promise, which will mean no reverse
conversion is required for rejecting Promises.
Differential Revision: https://phabricator.services.mozilla.com/D95967
The spec text has been improved a while ago, so I think we should do
this. This keeps the current moz-focusring behavior when the pref is
disabled, but when enabled it becomes effectively an alias of
focus-visible.
Differential Revision: https://phabricator.services.mozilla.com/D96697
Software keyboard is shown by user interaction. But `change` event by
`element.click()` becomes user interaction event by bug 1543439 even if
it is called by script.
Since `change` event can be fired by click() method, we shouldn't be
that it is always user interaction.
Also, we have setUserInput that is chrome API to emulate user input. It
should be defined as user interaction.
Differential Revision: https://phabricator.services.mozilla.com/D95818
This change removes docshell's `mTouchEventsOverride` and replaces it
with a new `BrowsingContext` field `TouchEventsOverrideInternal`.
All uses of the old field have been replaced and an override should
now work under fission when there are cross-origin descendent frames.
Differential Revision: https://phabricator.services.mozilla.com/D96414
This is regression by bug 1658948.
We shouldn't update IME state during composition even if element.focus() is
called to current focused element.
Also, although this depends on netive impelentation of IME handling, I would
like to add unit test for this situation since we might add mock tests for
native IME handling.
Differential Revision: https://phabricator.services.mozilla.com/D96308
And use them to disable DOM_DELTA_LINES on Nightly builds, to see the
impact, since this is pretty hard to measure just with telemetry.
Differential Revision: https://phabricator.services.mozilla.com/D95388
Some markers (e.g., GC major/minor/slice) need to splice JSON strings in their data.
So now, instead of JSONWriter, StreamJSONMarkerData functions will be given a mozilla::baseprofiler::SpliceableJSONWriter.
Differential Revision: https://phabricator.services.mozilla.com/D95511
This supports one manifestparser expression per line in the 'skip-if',
'fail-if' and 'run-if' keys. As a side effect the:
skip-if = foo ||
bar
syntax is no longer supported. Instead it can be:
skip-if =
foo # bug 123
bar # bug 456
Differential Revision: https://phabricator.services.mozilla.com/D95927
Allow-list all Python code in tree for use with the black linter, and re-format all code in-tree accordingly.
To produce this patch I did all of the following:
1. Make changes to tools/lint/black.yml to remove include: stanza and update list of source extensions.
2. Run ./mach lint --linter black --fix
3. Make some ad-hoc manual updates to python/mozbuild/mozbuild/test/configure/test_configure.py -- it has some hard-coded line numbers that the reformat breaks.
4. Make some ad-hoc manual updates to `testing/marionette/client/setup.py`, `testing/marionette/harness/setup.py`, and `testing/firefox-ui/harness/setup.py`, which have hard-coded regexes that break after the reformat.
5. Add a set of exclusions to black.yml. These will be deleted in a follow-up bug (1672023).
# ignore-this-changeset
Differential Revision: https://phabricator.services.mozilla.com/D94045
Allow-list all Python code in tree for use with the black linter, and re-format all code in-tree accordingly.
To produce this patch I did all of the following:
1. Make changes to tools/lint/black.yml to remove include: stanza and update list of source extensions.
2. Run ./mach lint --linter black --fix
3. Make some ad-hoc manual updates to python/mozbuild/mozbuild/test/configure/test_configure.py -- it has some hard-coded line numbers that the reformat breaks.
4. Make some ad-hoc manual updates to `testing/marionette/client/setup.py`, `testing/marionette/harness/setup.py`, and `testing/firefox-ui/harness/setup.py`, which have hard-coded regexes that break after the reformat.
5. Add a set of exclusions to black.yml. These will be deleted in a follow-up bug (1672023).
# ignore-this-changeset
Differential Revision: https://phabricator.services.mozilla.com/D94045
This is regression by bug 1672095. `GeckoEditableSupport` expects that
NOTIFY_IME_OF_BLUR is always sent. I would like to allow this even if
IME content observer is being destroyed.
To reproduce this, we have to lost application focus, I cannot write
geckoview-junit test.
Differential Revision: https://phabricator.services.mozilla.com/D94414
Allow-list all Python code in tree for use with the black linter, and re-format all code in-tree accordingly.
To produce this patch I did all of the following:
1. Make changes to tools/lint/black.yml to remove include: stanza and update list of source extensions.
2. Run ./mach lint --linter black --fix
3. Make some ad-hoc manual updates to python/mozbuild/mozbuild/test/configure/test_configure.py -- it has some hard-coded line numbers that the reformat breaks.
4. Add a set of exclusions to black.yml. These will be deleted in a follow-up bug (1672023).
# ignore-this-changeset
Differential Revision: https://phabricator.services.mozilla.com/D94045
Blink and WebKit do not fire `beforeinput` event when user uses build-in
password manager and autocomplete. But the `inputType` value for this case,
`"insertReplacementText"` is defined as cancelable in the spec, and it's
actually cancelable when it's fired for correcting a word with built-in
spellchecker of them.
For making only our users' autocomplete and password manager not blocked by
web apps, we should make them not cancelable by default, but I think that we
should keep dispatching such non-cancelable `beforeinput` for conforming to
the standard unless we'd get a web-compat report for this.
Differential Revision: https://phabricator.services.mozilla.com/D93206
When the grabber to move absolutely positioned element is disabled,
`HTMLEditor::HideGrabberInternal()` is called to delete it. However,
it does not reset dragging state. Therefore, `mousemove` event listener
will try to handle drag even after the grabber is removed.
This patch makes `HideGrabberInternal()` reset the dragging state to
make the event listener stop handling the drag action.
However, I hit a buggy assertion in `EventStateManager`. It tries to
set active state to parent of the grabber (in this case, absolutely positioned
element). However, editable element in `contenteditable` cannot have
active state. Therefore, `leaf` becomes `nullptr`, but `newleaf` is the
absolutely positioned element. Therefore, this patch adds this condition
into the `MOZ_ASSERT`.
Differential Revision: https://phabricator.services.mozilla.com/D93632
Actually software keyboard is opened by the following situations.
- Click event in editor
- Get new focus event.
Ace editor has small <textarea> element to handles some input events.
When clicking editable-like area (but this isn't ediable on Ace editor),
mousedown handler calls `event.preventDefault()` then set focus to
<textarea> element. So editor doesn't get click event and focus is still
keep in <textarea> element. At finally, we cannot open software keyboard
again since focus isn't changed.
So even if focus isn't changed, we should call SetInputContext to open
software keyboard.
Also, actually we doesn't have generic test code for notification of
software keyboard change (bug 1670539). I will add the test by bug 1670539.
Differential Revision: https://phabricator.services.mozilla.com/D93326
Add `static mozilla::MarkerSchemaWriter MarkerTypeDisplay()` for each existing marker type.
Because all markers of a given type now must have the same payload and display schema, the DOM event marker has changed from type=tracing with category=DOMEvent, to its own type=DOMEvent, which is now accepted on the front-end.
Based on c9692715f2/src/profile-logic/marker-schema.js
Differential Revision: https://phabricator.services.mozilla.com/D90658
Full zoom in the child process won't be applied to the cursor rect, so
undo it before checking to consider the actual rect that will be used.
Differential Revision: https://phabricator.services.mozilla.com/D93329
when there is no composition, `IMEStateManager::HandleSelectionEvent()` calls
`TextComposition::HandleSelectionEvent()` with `BrowserParent` which is
retrieved from `aEventTargetContent` which is focused content in the main
process. This means that `eSetSelection` event is handled in root document
of the focused tab when there is no composition. However, following composition
events will go to focused `BrowserParent`, i.e., if an OOP iframe has focus
in the tab, `eSetSelection` event won't be handled in it. Therefore, IME
always fails to replace existing text with new composition.
This patch makes both `IMEStateManager::HandleSelectionEvent()` and
`PresShell::EventHandler::DispatchEventToDOM()` use
`IMEStateManager::GetActiveBrowserParent()` for sending both `eSetSelection`
and composition events to same process. Additionally, this patch make
`IMEStateManager::GetActiveBrowserParent()` returns
`IMEStateManager::sFocusedIMEBrowserParent` when it's set to non-nullptr
because native IME tries to modify the editor which enabled IME context.
On the other hand, for making the behavior safer, we should make
`eCompositionStart` event have replacing range optionally. I filed
bug 1669907 to change the design, but it requires several non-tiny patches.
Once we fix it, we can write automated tests for this simply, but without
the fix, I need to write too many lines with low level API, and it becomes
unnecessary after fixing the bug. Therefore, I give up to write a test
for this for now.
Differential Revision: https://phabricator.services.mozilla.com/D93053
When `HTMLEditor` instances are destroyed, I'd like to collect how much
instances are worked with `beforeinput` event listeners. Before adding such
telemetry probe, this patch adds methods to set/get whether a `beforeinput`
event listener has had added or not to `nsPIDOMWindowInner`.
Differential Revision: https://phabricator.services.mozilla.com/D92546
This patch tries to mark root callers of `nsINode::GetSelectionRootContent()`
which calls `nsINode::GetAnonymousRootElementOfTextEditor()` as far as possible
(and reasonable).
It's used by `ContentEventHandler` so that a lot of methods of
`EventStateManager`, `ContentEventHandler`, `IMEContentObserver` which are main
users of it are also marked as `MOZ_CAN_RUN_SCRIPT`. I think that this is
reasonable.
On the other hand, it might not be reasonable to mark `IMEStateManager` methods
as `MOZ_CAN_RUN_SCRIPT` for initializing `IMEContentObserver` because
`IMEStateManager` may be able to initialize `IMEContentObserver` asynchronously
and its root callers are in XUL layout code. Therefore, this patch uses
`MOZ_CAN_RUN_SCRIPT_BOUNDARY` for `IMEStateManager` at least for now.
Differential Revision: https://phabricator.services.mozilla.com/D92730
This patch tries to mark root callers of `nsINode::GetSelectionRootContent()`
which calls `nsINode::GetAnonymousRootElementOfTextEditor()` as far as possible
(and reasonable).
It's used by `ContentEventHandler` so that a lot of methods of
`EventStateManager`, `ContentEventHandler`, `IMEContentObserver` which are main
users of it are also marked as `MOZ_CAN_RUN_SCRIPT`. I think that this is
reasonable.
On the other hand, it might not be reasonable to mark `IMEStateManager` methods
as `MOZ_CAN_RUN_SCRIPT` for initializing `IMEContentObserver` because
`IMEStateManager` may be able to initialize `IMEContentObserver` asynchronously
and its root callers are in XUL layout code. Therefore, this patch uses
`MOZ_CAN_RUN_SCRIPT_BOUNDARY` for `IMEStateManager` at least for now.
Differential Revision: https://phabricator.services.mozilla.com/D92730
The audio/video controls element has touch listeners on the scrubber, which
steals events when we don't want it to. So let's ignore those listeners.
Ignoring system group listeners for the purposes of event retargeting seems
reasonable in the general case, because those listeners are coming from the
browser itself. If we're relying on the event retargeting to make those browser
elements easy to hit, then we should not be doing that and instead just make
them bigger.
Test coverage for this change is provided by the android-components tests that
failed in bug 1668112. The next patch re-enables touch event retargeting and
exercises this code in the context of those tests.
Depends on D92436
Differential Revision: https://phabricator.services.mozilla.com/D92437
We don't need to flush before dispatching the event because we know that
if the values we cared about changed, then we'd get another event.
Differential Revision: https://phabricator.services.mozilla.com/D92444
This is part of the Markers 2.0 work. This payload proved to be a bit ambiguous
when moving to the new marker schema, so it requires an upgrader.
The test is included as the following commit.
Differential Revision: https://phabricator.services.mozilla.com/D92456
The telemetry probe was added in bug 1506434, and it's not necessary anymore
because of the event in the default group was completely disabled in
bug 1288640 (Gecko 65).
Therefore, we can get rid of the pref, and we can take back a room for a
bool member in `nsPIDOMWindowInner` for new telemetry probes which need
to know whether a specific event listener has been added or not.
Depends on D92395
Differential Revision: https://phabricator.services.mozilla.com/D92397
- onSVGZoom is gone and we no longer dispatch it.
- we've never dispatched SVGUnload or SVGResize events and if we did implement these they would be unload and resize events now.
Differential Revision: https://phabricator.services.mozilla.com/D92381
This makes it clearer where marker-type-specific payload arguments start, just after the marker type object.
Also improved the main API documentation.
Differential Revision: https://phabricator.services.mozilla.com/D91681
The `category.WithOptions(...)` syntax was a bit strange and difficult to explain.
Now the category and options are separate parameters. Default options can be specified with `MarkerOptions{}` or just `{}`.
As a special case, defaulted-NoPayload functions don't need `<>`, and defaulted-NoPayload functions and macros don't even need `{}` for default options, e.g.:
`profiler_add_marker("name", OTHER); PROFILER_MARKER_UNTYPED("name", OTHER);`
Differential Revision: https://phabricator.services.mozilla.com/D91680
This makes it clearer where marker-type-specific payload arguments start, just after the marker type object.
Also improved the main API documentation.
Differential Revision: https://phabricator.services.mozilla.com/D91681
The `category.WithOptions(...)` syntax was a bit strange and difficult to explain.
Now the category and options are separate parameters. Default options can be specified with `MarkerOptions{}` or just `{}`.
As a special case, defaulted-NoPayload functions don't need `<>`, and defaulted-NoPayload functions and macros don't even need `{}` for default options, e.g.:
`profiler_add_marker("name", OTHER); PROFILER_MARKER_UNTYPED("name", OTHER);`
Differential Revision: https://phabricator.services.mozilla.com/D91680
Edgar Chen
Olli Pettay
Mirko Brodesser
Bogdan Tara
Masayuki Nakano
Razvan Maries
Kagami Sascha Rosylight
Masatoshi Kimura
Kartik Gautam
Emilio Cobos Álvarez
Cosmin Sabou
Steven MacLeod
Dorel Luca
Simon Giesecke
Makoto Kato
Henri Sivonen
Tom Schuster
Csoregi Natalia
Markus Stange
David Parks
Sylvestre Ledru
Gerald Squelart
Mihai Alexandru Michis
Karl Tomlinson
Tim Huang
Andrew Halberstadt
Andreas Pehrson
Butkovits Atila
Ricky Stewart
Alaa Emad
Andi-Bogdan Postelnicu
Johann Hofmann
Narcis Beleuzu
Kartikaya Gupta
Greg Tatum
longsonr
Timothy Nikkel
Jonathan Kew