This change cleans up a lot of the getCurrentDisplay's logic which was unnecessarily
complex, it seems.
It also extracts the logic to walk up the DOM to find flex/grid containers to a
reusable functions.
Finally, this new extracted function is now used in the walker to determine if a text
node can be inlined in its parent element or not.
Differential Revision: https://phabricator.services.mozilla.com/D13677
--HG--
extra : moz-landing-system : lando
When a declaration is disabled, it is tracked as removed in the Changes panel.
When deleting a disabled declaration, we take care not track it as removed again.
Includes stricter checks when matching previously tracked added and removed declarations.
Differential Revision: https://phabricator.services.mozilla.com/D13616
--HG--
extra : moz-landing-system : lando
This removes the instrumentation to test the basic telemetry for the Changes panel (open count, time opened).
Differential Revision: https://phabricator.services.mozilla.com/D13691
--HG--
extra : moz-landing-system : lando
This means that for the File URI content process, we end up closing RDM if the page
navigates. This appears to be an acceptable trade-off, as this is the behaviour we've
been shipping since bug 1453519 landed (Firefox 61).
Differential Revision: https://phabricator.services.mozilla.com/D13331
--HG--
extra : moz-landing-system : lando
Until we implement intentional persistence of changes between page refreshes, the Changes actor should clear its stack of changes to avoid polluting the next DevTools session.
Differential Revision: https://phabricator.services.mozilla.com/D13618
--HG--
extra : moz-landing-system : lando
Flex elements can be both containers and items at the same time. When they get selected in the inspector
the sidebar shows both the container accordion and the item accordion.
This changeset makes sure the container accordion is displayed before the item accordion only when
the element is selected from the markup-view.
Differential Revision: https://phabricator.services.mozilla.com/D13416
--HG--
extra : moz-landing-system : lando
Depends on D13257
I think webextensions + console is already thoroughly tested in
devtools/client/aboutdebugging/test/browser_addons_debug_webextension_*.js
Luca, are there features that we might be missing after removing this?
Differential Revision: https://phabricator.services.mozilla.com/D13258
--HG--
extra : moz-landing-system : lando
Adds entries to Histograms.json, Scalars.yaml and Events.yaml to
account for the Changes panel when measuring time spent with the panel
in view and opening count. This leverages pre-existing instrumentation
used for other Inspector sidebar panels.
Differential Revision: https://phabricator.services.mozilla.com/D13085
--HG--
extra : moz-landing-system : lando
The browser_addons_debug_bootstrapped addon is completely removed because it is already
covered for webextensions with browser_addons_debug_webextensions.js
Other have either been migrated to use webextensions.
Differential Revision: https://phabricator.services.mozilla.com/D13255
--HG--
extra : moz-landing-system : lando
This is all the style-system work needed for this.
This implements the concept of legacy shorthands, teaches tests to understand
it, and adds a few more tests for these properties in particular.
The WPT even caught a few WebKit / Blink bugs:
https://bugs.chromium.org/p/chromium/issues/detail?id=906336https://bugs.webkit.org/show_bug.cgi?id=191803
This doesn't change the layout behavior for page-break-before: always, since
it'd stop breaking in multicol and such. Similarly, break-before / break-after:
column and page still behave the same, I'll file followups for those given
comment 22.
Differential Revision: https://phabricator.services.mozilla.com/D12211
--HG--
extra : moz-landing-system : lando
This also adds a telemetry count for the grid highlighter being turned on by the
markup view, which was not in place when we added the telemetry for the grid
highlighter.
Storage events are fired either directly after getting response from synchronous SetItem call or through observers. When a new onstorage event listener is added, we sycnhronously register an observer in the parent process. There's always only one observer actor per content process.
PBackgroundLSDatabase is now managed by a new PBackgroundLSObject protocol. PBackgroundLSObject is needed to eliminate the need to pass the principal info and document URI everytime a write operation occurs.
Preparation of an observer shares some states with preparation of a datastore, so common stuff now lives in LSRequestBase and preparation of a datastore now implements a nested state machine.
This patch was enhanced by asuth to drop observers only when the last storage listener is removed.
EventListenerRemoved is invoked on any removal, not just the final removal, so we need to make sure it's the final removal before dropping observer.
The implementation is based on a cache (datastore) living in the parent process and sync IPC calls initiated from content processes.
IPC communication is done using per principal/origin database actors which connect to the datastore.
The synchronous blocking of the main thread is done by creating a nested event target and spinning the event loop.
In Bug 1462394, we moved the autocomplete data handling
out of the JsTerm to the Redux store. In the process, we
regress some cases like `await n`, which should display
`navigator`, but isn't anymore when the user types the
whole sequence. Ctrl+Space would still show the popup,
which indicates that the issue is not on the server-side.
This issue is caused because our new code decides that
we should hit the cache when typing the `n`, and there's
nothing in the cache.
Previously, we were clearing the cache as soon as the input
last string wasn't alphanumeric, which we don't anymore.
To fix that, instead of relying on the last string of the
input (which could be wrong in cases like `x.["hello `), we
clear the cache when the autocomplete service returns a null
`matches` property.
In the JsPropertyProvider, we use to return null whenever
there isn't any search done (incorrect input, empty match prop, …).
So it seems like a good idea to bust the cache when the
server returns null.
This requires some changes to the autocomplete service, as well
as some in jsPropertyProvider (e.g. to handle `await `).
Tests are added both on the client and the frontend to make sure
we don't regress this (those tests fail without the actual fix).
Differential Revision: https://phabricator.services.mozilla.com/D13231
--HG--
extra : moz-landing-system : lando
For now, even when close the background/lazy tabs, could not reflect to
`about:debugging` page. In this patch, notify to DevTools clients when close
any tabs.
Differential Revision: https://phabricator.services.mozilla.com/D12873
--HG--
extra : moz-landing-system : lando
Ideally, it would use TargetFactory. But as that's mochitest chrome,
we don't have natural access to gBrowser/firefox tab.
MozReview-Commit-ID: 4nrfFZu6jAU
Depends on D12734
Differential Revision: https://phabricator.services.mozilla.com/D12735
--HG--
extra : moz-landing-system : lando
These tests are calling listTabs, but that is no longer necessary thanks to rootForm
being automatically managed within RootFront.
MozReview-Commit-ID: AmC6dTIJjiY
Depends on D12732
Differential Revision: https://phabricator.services.mozilla.com/D12733
--HG--
extra : moz-landing-system : lando
I also removed the get root form leftover.
MozReview-Commit-ID: DxPwG9a5YAG
Depends on D12731
Differential Revision: https://phabricator.services.mozilla.com/D12732
--HG--
extra : moz-landing-system : lando
There is 4 patterns here:
* Tests using attachThreadActorForUrl like event-listeners ones. I augmented this helper method to call TargetFactory.
* Tests using attachTargetActorForUrl like debugger-statement, dbg-navigation and target-scoped-actor. Uses TargetFactory directly.
* Tests using connectDebuggerClient like navigateEvents and spaw_actor_in_parent. Uses TargetFactory directly.
* All the others, where creating DebuggerClient on their own, and calling listTabs+attachTarget. They now use TargetFactory directly.
A note about webconsole-helpers, only consoleClient attribute was used from tests using this helper.
Also, in various tests I remove the call to client.destroy, that's because shared-head will
close all the tabs/toolboxes and it should lead to target/client destruction.
Finally, debugger-statement now request the thread actor via the client instead of manual request,
it should help the refactoring to a front!
MozReview-Commit-ID: 2ah4UmSjuoi
Depends on D12730
Differential Revision: https://phabricator.services.mozilla.com/D12731
--HG--
extra : moz-landing-system : lando
For now, we only pass { actor } for all tab target fronts created via DebuggerClient.attachTarget,
whereas parent process target fronts were passing the full form from RootFront.getProcess.
MozReview-Commit-ID: 1H2NxFv8glY
Differential Revision: https://phabricator.services.mozilla.com/D12730
--HG--
extra : moz-landing-system : lando
Depends on D13137. I could use help to write the test in a better.
I believe there is a cleaner way to create the front here?
I also had other suggestions for making the fronts more robust in the bug.
Let me know if you think I should try to investigate them more.
Differential Revision: https://phabricator.services.mozilla.com/D13138
--HG--
extra : moz-landing-system : lando
We were dipatching the "connect" request manually, whereas we should be using
protocol.js specifications. It also help getting rid of another use of "form"
instead of "front"/activeTab in Target class.
MozReview-Commit-ID: IOH4mDprAVL
Depends on D12577
Differential Revision: https://phabricator.services.mozilla.com/D12578
--HG--
extra : moz-landing-system : lando
I did a dedicated patch for converting both about:debuggings as it is slightly more
complex as we have to tweak redux data, wrappers, mocks.
This patch also convert a manual "reload" request being done by about:debugging
and instead use protocol.js front to do it.
Also, I moved isLegacyTemporaryExtension to the front as it depends on accessing the form
and it should be better to keep form processing to the fronts, if possible.
MozReview-Commit-ID: 16qZkuCBp9b
Depends on D12576
Differential Revision: https://phabricator.services.mozilla.com/D12577
--HG--
extra : moz-landing-system : lando
Adapt to the new returned value of listAddons
and also always call it from RootFront instead of DebuggerClient.
Fix the spec in order to expose reload on the front (it was a miss from a previous patch).
MozReview-Commit-ID: AQ5EOQEqnxX
Depends on D12575
Differential Revision: https://phabricator.services.mozilla.com/D12576
--HG--
extra : moz-landing-system : lando
I'm sorry this is just one commit, I should have split it :( I will submit tests in another patch.
- Vendored [react-router-dom](https://www.npmjs.com/package/react-router-dom) library.
- Removed `getSelectedPageComponent` from `App` component and changed it to use React Router's `Route` components.
- Made the sidebar links to point to proper URL's. Thanks to this we don't need a lot of code/props we were passing to these items to select the proper page.
Some considerations over the implementation:
- React Router's `Switch` is used to wrap our routes, to ensure only one is rendered. Right now is not strictly necessary, but I think it helps to clarify that the routes are _not_ nested.
- We need to pass a `key` prop to the `RuntimePage` rendered in the route, so when we change the actual runtime shown, the page gets updated.
- The action `selectPage` gets called on `componentWillMount`, so it doesn't change state while rendering.
- When we reload the page and a device runtime is selected, we redirect to "This Firefox" page.
(Click on this GIF to see navigation 👇)
{F1100903}
I'm sorry this has taken this long, it has been a bit of a headache 🙏
Differential Revision: https://phabricator.services.mozilla.com/D12147
--HG--
extra : moz-landing-system : lando
We were dipatching the "connect" request manually, whereas we should be using
protocol.js specifications. It also help getting rid of another use of "form"
instead of "front"/activeTab in Target class.
MozReview-Commit-ID: IOH4mDprAVL
Depends on D12577
Differential Revision: https://phabricator.services.mozilla.com/D12578
--HG--
extra : moz-landing-system : lando
I did a dedicated patch for converting both about:debuggings as it is slightly more
complex as we have to tweak redux data, wrappers, mocks.
This patch also convert a manual "reload" request being done by about:debugging
and instead use protocol.js front to do it.
Also, I moved isLegacyTemporaryExtension to the front as it depends on accessing the form
and it should be better to keep form processing to the fronts, if possible.
MozReview-Commit-ID: 16qZkuCBp9b
Depends on D12576
Differential Revision: https://phabricator.services.mozilla.com/D12577
--HG--
extra : moz-landing-system : lando
Adapt to the new returned value of listAddons
and also always call it from RootFront instead of DebuggerClient.
Fix the spec in order to expose reload on the front (it was a miss from a previous patch).
MozReview-Commit-ID: AQ5EOQEqnxX
Depends on D12575
Differential Revision: https://phabricator.services.mozilla.com/D12576
--HG--
extra : moz-landing-system : lando
Depends on D12095. Now that we pass a remoteId to open about:devtools-toolbox, we actually don't need transportDetails
Differential Revision: https://phabricator.services.mozilla.com/D12097
--HG--
extra : moz-landing-system : lando
Depends on D12040. If we don't cleanup the clients after the test, some tests may leak.
Differential Revision: https://phabricator.services.mozilla.com/D12095
--HG--
extra : moz-landing-system : lando
This is a best effort attempt at ensuring that the adverse impact of
reformatting the entire tree over the comments would be minimal. I've used a
combination of strategies including disabling of formatting, some manual
formatting and some changes to formatting to work around some clang-format
limitations.
Differential Revision: https://phabricator.services.mozilla.com/D13046
--HG--
extra : moz-landing-system : lando
Depends on D12095. Now that we pass a remoteId to open about:devtools-toolbox, we actually don't need transportDetails
Differential Revision: https://phabricator.services.mozilla.com/D12097
--HG--
extra : moz-landing-system : lando
Depends on D12040. If we don't cleanup the clients after the test, some tests may leak.
Differential Revision: https://phabricator.services.mozilla.com/D12095
--HG--
extra : moz-landing-system : lando
Sorry but 65 is coming to an end, we really need to address this before the
release is closed.
Differential Revision: https://phabricator.services.mozilla.com/D12869
--HG--
extra : moz-landing-system : lando
This will enable connecting to Firefox 63 (and 64? not sure in which release the changes actor
was introduced) from Nightly. Pinging yulia for review to check if there is a better way to handle such
backward compatible code when using the getFront API.
Differential Revision: https://phabricator.services.mozilla.com/D12872
--HG--
extra : moz-landing-system : lando
There's a few subtle behavior changes here, which I'll try to break down in the
commit message.
The biggest one is the EditableDescendantCount stuff going away. This
was added in bug 1181130, to prevent clicking on the non-editable div from
selecting the editable div inside. This is problematic for multiple reasons:
* First, I don't think non-editable regions of an editable element should
be user-select: all.
* Second, it just doesn't work in Shadow DOM (the editable descendant count is
not kept up-to-date when not in the uncomposed doc), so nested
contenteditables behave differently inside vs. outside a Shadow Tree.
* Third, I think it's user hostile to just entirely disable selection if you
have a contenteditable descendant as a child of a user-select: all thing.
WebKit behaves like this patch in the following test-case (though not Blink):
https://crisal.io/tmp/user-select-all-contenteditable-descendant.html
Edge doesn't seem to support user-select: all at all (no pun intended).
But we don't allow to select anything at all which looks wrong.
* Fourth, it's not tested at all (which explains how we broke it in Shadow DOM
and not even notice...).
In any case I've verified that this doesn't regress the editor from that bug. If
this regresses anything we can fix it as outlined in the first bullet point
above, which should also make us more compatible with other UAs in that
test-case.
The other change is `all` not overriding everything else. So, something like:
<div style="-webkit-user-select: all">All <div style="-webkit-user-select: none">None</div></div>
Totally ignores the -webkit-user-select: none declaration in Firefox before this
change. This doesn't match any other UA nor the spec, and this patch aligns us
with WebKit / Blink.
This in turn makes us not need -moz-text anymore, whose only purpose was to
avoid this.
This also fixes a variety of bugs uncovered by the previous changes, like the
SetIgnoreUserModify(false) call in editor being completely useless, since
presShell->SetCaretEnabled ended in nsCaret::SetVisible, which overrode it.
This in turn uncovered even more bugs, from bugs in the caret painting code,
like not checking -moz-user-modify on the right frame if you're the last frame
of a line, to even funnier bits where before this patch you show the caret but
can't write at all...
In any case, the new setup I came up with is that when you're editing (the
selection is focused on an editable node) moving the caret forces it to end up
in an editable node, thus jumping over non-editable ones.
This has the nice effect of not completely disabling selection of
-moz-user-select: all elements that have editable descendants (which was a very
ad-hoc hack for bug 1181130, and somewhat broken per the above), and also
not needing the -moz-user-select: all for non-editable bits in contenteditable.css
at all.
This also fixes issues with br-skipping like not being able to insert content in
the following test-case:
<div contenteditable="true"><span contenteditable="false">xyz </span><br>editable</div>
If you start moving to the left from the second line, for example.
I think this yields way better behavior in all the relevant test-cases from bug
1181130 / bug 1109968 / bug 1132768, shouldn't cause any regression, and the
complexity is significantly reduced in some places.
There's still some other broken bits that this patch doesn't fix, but I'll file
follow-ups for those.
Differential Revision: https://phabricator.services.mozilla.com/D12687
--HG--
extra : moz-landing-system : lando
There's a few subtle behavior changes here, which I'll try to break down in the
commit message.
The biggest one is the EditableDescendantCount stuff going away. This
was added in bug 1181130, to prevent clicking on the non-editable div from
selecting the editable div inside. This is problematic for multiple reasons:
* First, I don't think non-editable regions of an editable element should
be user-select: all.
* Second, it just doesn't work in Shadow DOM (the editable descendant count is
not kept up-to-date when not in the uncomposed doc), so nested
contenteditables behave differently inside vs. outside a Shadow Tree.
* Third, I think it's user hostile to just entirely disable selection if you
have a contenteditable descendant as a child of a user-select: all thing.
WebKit behaves like this patch in the following test-case (though not Blink):
https://crisal.io/tmp/user-select-all-contenteditable-descendant.html
Edge doesn't seem to support user-select: all at all (no pun intended).
But we don't allow to select anything at all which looks wrong.
* Fourth, it's not tested at all (which explains how we broke it in Shadow DOM
and not even notice...).
In any case I've verified that this doesn't regress the editor from that bug. If
this regresses anything we can fix it as outlined in the first bullet point
above, which should also make us more compatible with other UAs in that
test-case.
The other change is `all` not overriding everything else. So, something like:
<div style="-webkit-user-select: all">All <div style="-webkit-user-select: none">None</div></div>
Totally ignores the -webkit-user-select: none declaration in Firefox before this
change. This doesn't match any other UA nor the spec, and this patch aligns us
with WebKit / Blink.
This in turn makes us not need -moz-text anymore, whose only purpose was to
avoid this.
This also fixes a variety of bugs uncovered by the previous changes, like the
SetIgnoreUserModify(false) call in editor being completely useless, since
presShell->SetCaretEnabled ended in nsCaret::SetVisible, which overrode it.
This in turn uncovered even more bugs, from bugs in the caret painting code,
like not checking -moz-user-modify on the right frame if you're the last frame
of a line, to even funnier bits where before this patch you show the caret but
can't write at all...
In any case, the new setup I came up with is that when you're editing (the
selection is focused on an editable node) moving the caret forces it to end up
in an editable node, thus jumping over non-editable ones.
This has the nice effect of not completely disabling selection of
-moz-user-select: all elements that have editable descendants (which was a very
ad-hoc hack for bug 1181130, and somewhat broken per the above), and also
not needing the -moz-user-select: all for non-editable bits in contenteditable.css
at all.
This also fixes issues with br-skipping like not being able to insert content in
the following test-case:
<div contenteditable="true"><span contenteditable="false">xyz </span><br>editable</div>
If you start moving to the left from the second line, for example.
I think this yields way better behavior in all the relevant test-cases from bug
1181130 / bug 1109968 / bug 1132768, shouldn't cause any regression, and the
complexity is significantly reduced in some places.
There's still some other broken bits that this patch doesn't fix, but I'll file
follow-ups for those.
Differential Revision: https://phabricator.services.mozilla.com/D12687
--HG--
extra : moz-landing-system : lando
Updated to the new path and found a filter that gives us the exact colours we had previously in both light and dark mode.
Differential Revision: https://phabricator.services.mozilla.com/D12660
--HG--
extra : moz-landing-system : lando
Changed my mind about getDeviceDescription :)
I think it is better to remain explicit and to always say which properties we are exporting.
I also added a small test for the this-firefox mock to avoid future regressions.
Differential Revision: https://phabricator.services.mozilla.com/D12318
--HG--
extra : moz-landing-system : lando
There is a lot of code being copy paste in all these tests
and as I'm most likely going to change things around them in the near future
regarding fission, it would be better if we start sharing more code.
After this there is still a couple of copy paste code (but way less!):
* breakpoints: wait a paused event and eval a custom script in a sandbox
* object grips: set the security.allow_eval_with_system_principal pref, eval stopMe and wait for paused
* stepping: use executeOnNextTickAndWaitForPause to eval a custom script and wait for pause while doing this only on next tick
There is most likely more to share, but at least this isn't framework code, but now only code specific to the debugger.
MozReview-Commit-ID: JgD389cas2j
Depends on D12309
Differential Revision: https://phabricator.services.mozilla.com/D12310
--HG--
extra : moz-landing-system : lando
Without this devtools/server/tests/unit/test_breakpoint-22.js fails in protocol.js
writeError function when trying to use console object.
MozReview-Commit-ID: JFhFboHugUh
Differential Revision: https://phabricator.services.mozilla.com/D12309
--HG--
extra : moz-landing-system : lando
Ensure the exact declaration is matched when aggregating changes and attempting to remove declarations which cancel each other out.
Without checking both the index and the property name, we used to lose tracked declarations that were renamed.
The test checks for the expected rename behaviour and that renaming the declaration to its original clears any tracked changes.
Differential Revision: https://phabricator.services.mozilla.com/D12434
--HG--
extra : moz-landing-system : lando
Note that I fixed the worker bug at the same time. We can keep your other bug to add a test.
Differential Revision: https://phabricator.services.mozilla.com/D12007
--HG--
extra : moz-landing-system : lando
Animations panel also had a sync getTarget location. Unfortunately this animation front was used in
a number of locations. In this case, I used getFront in each call location, as these were always
async. I am not sure if this was the best way
Depends on D11887
Differential Revision: https://phabricator.services.mozilla.com/D11888
--HG--
extra : moz-landing-system : lando
ChangesView was challenging because the async call was in the constructor. I moved it out of the
constructor to the init method, and do a check to see if its been initialized in the destroy method.
Depends on D11886
Differential Revision: https://phabricator.services.mozilla.com/D11887
--HG--
extra : moz-landing-system : lando
Still not sure what is the root issue here, but none of the regular connect tests are failing so I think the issue occurs when we remove tabs in the second step.
Differential Revision: https://phabricator.services.mozilla.com/D12332
--HG--
extra : moz-landing-system : lando
The patch for https://bugzilla.mozilla.org/show_bug.cgi?id=1467076 discards previous TextProperty instances for the element's inline style when the inline style is updated.
On start, the Shape Path Editor kept a reference to the original TextProperty instance. This outdated instance caused the update mechanism of the Shape Path Editor to fail.
This patch fixes the issue by keeping metadata (index and property name) about the TextProperty to re-identify the correct one when needed instead of relying on a potentially outdated reference.
Differential Revision: https://phabricator.services.mozilla.com/D12157
--HG--
extra : moz-landing-system : lando
Depends on D12588
Support indefinite nesting by declaring the --diff-level CSS custom property as an inline style on the element at its level of nesting.
This custom property will be used in the stylesheet to compute the appropriate padding-left to create the indentation necessary.
A minumum offset is used, --diff-level-min-offset, to account for the first level (zero-indexed) and to allow additional padding on added/removed lines to clear the +/- icons.
Differential Revision: https://phabricator.services.mozilla.com/D12590
--HG--
extra : moz-landing-system : lando
In JsPropertyProvider, if doing a property access (with a dot),
check that the results are suited for a dot notation (e.g. `data`
is, while `data-test` is not).
In case, of an element access, we can return everything.
This implies making some changes to some tests which were using
invalid dot notation access in some case, which revealed a
bug with bracket autocomplete and spaces.
So the bracket autocomplete with spaces is now also fixed, and
a test case was added for that as well.
Differential Revision: https://phabricator.services.mozilla.com/D12726
--HG--
extra : moz-landing-system : lando
- Add a new 12px round icon for Console errors.
- Update the warning (triangle) icon to use the same 12px size.
- Update the info icon to use the same 12px size,
and differentiate its design from the error icon.
- Tweak the Console's input and return icons to be a tiny bit
bigger (for better overall visual balance) and crisper @1x.
Differential Revision: https://phabricator.services.mozilla.com/D12250
--HG--
rename : devtools/client/themes/images/devtools-components/checkbox.svg => devtools/client/themes/images/checkbox.svg
extra : moz-landing-system : lando
As we were using the browserWindow to start the
parser worker, this was causing an exception
when evaluation from the browser toolbox.
Using chromUtilsWindow fixes the issue.
There is no tests yet as I'm not sure there's
an easy way to test things in the browser toolbox.
Differential Revision: https://phabricator.services.mozilla.com/D12101
--HG--
extra : moz-landing-system : lando
This pleases clang-format and makes many of these behave better when
auto formatted. Special cases may still be marked |clang-format off| in
later commits.
Differential Revision: https://phabricator.services.mozilla.com/D12231
--HG--
extra : moz-landing-system : lando
String.fromCharCode(...charCodes) is limited by the maximum number of arguments that SpiderMonkey
can pass on the stack, if the screenshot gets to large this can easily fail.
Differential Revision: https://phabricator.services.mozilla.com/D12218
--HG--
extra : moz-landing-system : lando
Add a new class to extract tracelogger data using chunked buffers and use this to write the data out to the profiler JSON output. Copying the data in chunks lets us minimize our memory overhead when writing out to the profiler so a large array of millions of elements does not need to be allocated ahead of time.
Differential Revision: https://phabricator.services.mozilla.com/D11791
--HG--
extra : moz-landing-system : lando
