We are updating more things when selecting a thread than when opening the debugger.
Let's use a unique codepath when it comes to handle a new top level target.
Differential Revision: https://phabricator.services.mozilla.com/D151552
Add compositionstart, compositionupdate and compositionend
to keyboard event-listener-breakpoints.
Add mochitests for each.
Add comment to mochitest.
Differential Revision: https://phabricator.services.mozilla.com/D153627
This makes it easier to get parity between legacy and regular flex
without having to either have tons of arbitrary attribute selectors in
the xul sheet, nor adding attribute lookup hacks to the html flexbox
layout.
Also, reimplement the remaining supported flex attribute-values (0 and 1)
purely in terms of CSS rules in xul.css (regardless of whether
emulate-moz-box-with-flex is enabled).
In practice these are pretty uncommon and the style attribute does the
trick in every case I've tried.
Add a debug-only assertion to ensure we preserve behavior for now.
Add a new test with another behavior difference between flexbox
emulation and old xul layout because the old reftest now passes. Use
replaced elements, which in modern flex are treated differently.
Differential Revision: https://phabricator.services.mozilla.com/D154394
This makes it easier to get parity between legacy and regular flex
without having to either have tons of arbitrary attribute selectors in
the xul sheet, nor adding attribute lookup hacks to the html flexbox
layout.
Also, reimplement the remaining supported flex attribute-values (0 and 1)
purely in terms of CSS rules in xul.css (regardless of whether
emulate-moz-box-with-flex is enabled).
In practice these are pretty uncommon and the style attribute does the
trick in every case I've tried.
Add a debug-only assertion to ensure we preserve behavior for now.
Add a new test with another behavior difference between flexbox
emulation and old xul layout because the old reftest now passes. Use
replaced elements, which in modern flex are treated differently.
Differential Revision: https://phabricator.services.mozilla.com/D154394
Since the select node in inspector simply re-use the inspector icon,
we're doing here, using a sized-down version of the a11y panel icon.
Differential Revision: https://phabricator.services.mozilla.com/D154509
This will add proper titles to the icons we display in the accessibility
panel to select a node in the Accessibility Tree or in the inspector (if it's
a dom node).
Assertions are added in tests to ensure we don't regress.
Differential Revision: https://phabricator.services.mozilla.com/D154406
Instead we can fully rely on TargetCommand.
This fixes duplicated calls made to top level thread actor.
This was only happening with toolbox not using the Watcher Actor.
i.e. the non-multiprocess Browser Toolbox, Browser Content Toolbox and may be worker toolboxes from about:debugging.
Differential Revision: https://phabricator.services.mozilla.com/D151643
We used to create the document, then set the text and the mode, which seemed to
trigger unecessary updates in CodeMirror.
Since CodeMirror document can take an initial value and mode, we make this a possibility
in the source editor, and use it from the debugger codebase.
We take this as an opportunity to move the `getMode` function to `source-document.js` as
it's only used from there, and put the logic to not highlight big files there.
The unit test for the function are moved to the same folder the function now lives in,
and are adapted to the new signature.
Differential Revision: https://phabricator.services.mozilla.com/D154096
This is still one blind spot with privileged request done by content processes.
They aren't related to any BrowsingContext/WindowGlobal and there isn't any
attribute on channel/loadInfo which helps knowing they originates from a content process.
Differential Revision: https://phabricator.services.mozilla.com/D150014
We currently support stack walking everywhere, and when it fails, we fall back
to leaf stacks. The leaf option is a bit confusing in how it works, and doesn't
provide much value.
Differential Revision: https://phabricator.services.mozilla.com/D153695
We currently support stack walking everywhere, and when it fails, we fall back
to leaf stacks. The leaf option is a bit confusing in how it works, and doesn't
provide much value.
Differential Revision: https://phabricator.services.mozilla.com/D153695
Tests were using the internal `_dbgProcess` and `_dbgProfilePath` properties, which
we migrate to private properties.
We now pass those properties as part of the `run` event that those tests are
setting up, so we can run assertions on those object.
Finally, we take this as an opportunity to clean `browser_dbg-chrome-create.js`.
Since it was the only callsite using `onClose`, and given that we directly call
the `close` method, we can remove the `onClose` from the signature of `BrowserToolboxLauncher`.
Differential Revision: https://phabricator.services.mozilla.com/D153733
The bulk was removed in bug 1771608, but some vestigial bits were missed.
We cannot yet fix the remaining import in devtools/shared/ until we have a way
to replace osfile.jsm in a content process.
Differential Revision: https://phabricator.services.mozilla.com/D153700
Tests were using the internal `_dbgProcess` and `_dbgProfilePath` properties, which
we migrate to private properties.
We now pass those properties as part of the `run` event that those tests are
setting up, so we can run assertions on those object.
We also emit the event with `emitForTests` to make it clear those properties
are only accessed outside of the class from tests.
Finally, we take this as an opportunity to clean `browser_dbg-chrome-create.js`.
Since it was the only callsite using `onClose`, and given that we directly call
the `close` method, we can remove the `onClose` from the signature of `BrowserToolboxLauncher`.
Differential Revision: https://phabricator.services.mozilla.com/D153733
`Array.from` on an iterable object internally calls
`%ArrayIteratorPrototype%.next`, which is effectful.
The later patches will add more coverage inside for-of loop inside
self-hosted JS, and that will expose the call on `obj[Symbol.iterator]().next`,
which can be `%ArrayIteratorPrototype%.next` or any other function.
Differential Revision: https://phabricator.services.mozilla.com/D153153
When opening the debugger, we do watch worker targets in case we need to honor
some breakpoints.
If you started the console at some point, this will start watching console messages
resources, within the worker thread.
The issue is that if the `dom.worker.console.dispatch_events_to_main_thread` has
its default value, the worker messages are cloned from the worker thread to the
main thread, so when we start the debugger, we get duplicated messages: the cloned
ones, and the ones directly from the worker.
To fix this, we forward the value of the pref to the worker target so we can
bail out when it tries to watch for console messages.
Differential Revision: https://phabricator.services.mozilla.com/D153471
Alexandre Poirot
Cosmin Sabou
Luke Swiderski
Emilio Cobos Álvarez
Marian-Vasile Laza
Nicolas Chevobbe
Hubert Boma Manilla
Cristian Tuns
Julian Descottes
colin_czb
Butkovits Atila
Ben Hearsum
Gerald Squelart
Barret Rennie
Tooru Fujisawa
Sandor Molnar
Mark Banner