Investigate Using LongStringFront instead of LongStringClient
Categories
(DevTools :: Framework, task, P3)
Tracking
(firefox68 fixed)
Tracking | Status | |
---|---|---|
firefox68 | --- | fixed |
People
(Reporter: yulia, Assigned: yulia)
References
Details
(Whiteboard: dt-fission)
Attachments
(1 file, 1 obsolete file)
In the ThreadClient, We are currently using the LongStringClient: https://searchfox.org/mozilla-central/source/devtools/shared/client/thread-client.js#376
It is also used in the webconsole, and some tests: https://searchfox.org/mozilla-central/search?q=longstringclient&path=
LongStringClient has already been converted to a front:
Client code - https://searchfox.org/mozilla-central/source/devtools/shared/client/long-string-client.js
Front: https://searchfox.org/mozilla-central/source/devtools/shared/fronts/string.js
Spec: https://searchfox.org/mozilla-central/source/devtools/shared/specs/string.js
however the front is not used anywhere: https://searchfox.org/mozilla-central/search?q=longstringfront&path=
It looks like this was a partially completed refactor but I cannot find the original bug. This should be completed.
Assignee | ||
Updated•6 years ago
|
Assignee | ||
Comment 1•6 years ago
|
||
we have two longstring actors in the codebase. This switches the source actor from using
devtools/server/actors/object/long-string.js to using devtools/server/actors/string.js. The two are
almost equivalent, but it looks like we should migrate all usages to string.js
Assignee | ||
Comment 2•6 years ago
|
||
I am not sure this is necessary, but this memoizes the response from onSource in a simpler
way. What happened before, is we would memoize the response on the pool object, and make it a weak
reference. However this reference is linked to the source object. We don't have multiple source
texts for a single source. It also appears that we cache the source on the client side.
Updated•6 years ago
|
Comment 4•6 years ago
|
||
bugherder |
Updated•6 years ago
|
Description
•