The cross-compartment case is still buggy but this at least ensures we don't
regress the correct same-compartment behavior.
Differential Revision: https://phabricator.services.mozilla.com/D36740
--HG--
extra : moz-landing-system : lando
While I worked on this patch series these assertions where helpful to detect
problems.
Differential Revision: https://phabricator.services.mozilla.com/D43004
--HG--
extra : moz-landing-system : lando
Implement this as a linked list so that it cannot leak memory (unless it
also leaks locks) and the Mutex::ShutDown() function can be removed.
Differential Revision: https://phabricator.services.mozilla.com/D40985
--HG--
extra : moz-landing-system : lando
Condition variables lock and unlock mutexes. The code in the next patch
would find assertion failures because this case wasn't handled.
Differential Revision: https://phabricator.services.mozilla.com/D43002
--HG--
extra : moz-landing-system : lando
Factor the common parts of the DEBUG and non-DEBUG Mutex class together to
make it easier to see what the common and different parts of this class are.
Differential Revision: https://phabricator.services.mozilla.com/D40984
--HG--
extra : moz-landing-system : lando
Most of things will likely be no real change because they ask for the exact frame they want immediately before.
Differential Revision: https://phabricator.services.mozilla.com/D44359
--HG--
extra : moz-landing-system : lando
We're re-using the test we already have for invoking getters
in the webconsole as it is checking a lot of different cases.
Differential Revision: https://phabricator.services.mozilla.com/D44628
--HG--
rename : devtools/client/webconsole/test/browser/browser_webconsole_object_inspector_getters.js => devtools/client/webconsole/test/browser/browser_console_content_getters.js
extra : moz-landing-system : lando
Additionally, this patch makes it use early-return style with `continue` as
far as making number of changing line minimized.
Differential Revision: https://phabricator.services.mozilla.com/D44194
--HG--
extra : moz-landing-system : lando
When we wanted to insert a string in the webconsole input,
we were setting the input value, and setting the cursor
manually. But since the editor setCursor function is calling
alignLine, there could be cases where the editor scroll position
would jump, feeling awkward for the user.
It turns out we can simplify this code a lot since codeMirror
provides a replaceRange function, which is a perfect replacement
for what we were using, without having to manage the cursor position.
The only downside to that is that inserting characters this
way *does* fire a `changes` event, that we are listening to
in the JsTerm to request autocompletion (which we don't need
as we only insert characters when accepting a completion or
adding a tab).
To mitigate that, we pass a specific jsterm origin string to
replaceRange, which let's us discriminate in the changes event
listener if those changes originate from jsterm only actions.
A test is added to ensure this works as expected (the test was
failing without the fix).
Differential Revision: https://phabricator.services.mozilla.com/D44466
--HG--
extra : moz-landing-system : lando
Meaningful job of `HTMLEditor::InsertParagraphSeparatorAsSubAction()` is only
calling `HTMLEditRules::WillInsertParagraph()` via
`HTMLEditRules::WillDoAction()`. Therefore, we can move all jobs in them
into `HTMLEditRules::WillInsertParagraph()` and rename it to
`HTMLEditor::InsertParagraphSeparatorAsSubAction()`.
Differential Revision: https://phabricator.services.mozilla.com/D44190
--HG--
extra : moz-landing-system : lando
This was fixed upstream, so we can eventually remove this.
Having the issue number makes it much nicer to figure out when is the right time
to remove it.
Differential Revision: https://phabricator.services.mozilla.com/D44624
--HG--
extra : moz-landing-system : lando
Whitespace triming was used by only one caller, so it deserves to live
outside. Additionally, this defines the method name more precisely.
Depends on D44347
Differential Revision: https://phabricator.services.mozilla.com/D44348
--HG--
extra : moz-landing-system : lando
Gather stats for most calls to `profiler_add_marker()`, including the time to
allocate payloads if any.
Differential Revision: https://phabricator.services.mozilla.com/D43420
--HG--
extra : moz-landing-system : lando
All calls to `profiler_add_marker()` (outside of the profilers code) are
now replaced by either:
- `PROFILER_ADD_MARKER(name, categoryPair)`
- `PROFILER_ADD_MARKER_WITH_PAYLOAD(name, categoryPair, TypeOfMarkerPayload,
(payload, ..., arguments))`
This makes all calls consistent, and they won't need to prefix the category pair
with `JS::ProfilingCategoryPair::`.
Also it will make it easier to add (and later remove) internal-profiling
instrumentation (bug 1576550), and to replace heap-allocated payloads with
stack-allocated ones (bug 1576555).
Differential Revision: https://phabricator.services.mozilla.com/D43588
--HG--
extra : moz-landing-system : lando
Razvan Maries
Jan de Mooij
Paul Bone
Bogdan Tara
Andrew Halberstadt
Itiel
Emilio Cobos Álvarez
Andreea Pavel
Masayuki Nakano
David Walsh
sviho
Julian Descottes
hb
Vlad Baicu
Timothy Nikkel
Nicolas Chevobbe
Tom Schuster
Paul Zuehlcke
Dão Gottwald
lloan
Andreas Pehrson
Johann Hofmann
Mirko Brodesser
Gerald Squelart