Use plain object for lazy getter in services/
Categories
(Cloud Services :: General, task)
Tracking
(firefox103 fixed)
| Tracking | Status | |
|---|---|---|
| firefox103 | --- | fixed |
People
(Reporter: arai, Assigned: arai)
References
Details
Attachments
(7 files)
|
48 bytes,
text/x-phabricator-request
|
Details | Review | |
|
48 bytes,
text/x-phabricator-request
|
Details | Review | |
|
48 bytes,
text/x-phabricator-request
|
Details | Review | |
|
48 bytes,
text/x-phabricator-request
|
Details | Review | |
|
48 bytes,
text/x-phabricator-request
|
Details | Review | |
|
48 bytes,
text/x-phabricator-request
|
Details | Review | |
|
48 bytes,
text/x-phabricator-request
|
Details | Review |
+++ This bug was initially created as a clone of Bug #1772007 +++
Many JSM files define lazy getters on the per-JSM global this object.
The global this object doesn't exist in ES module, and those lazy getters need to be moved to a plain object const lazy = {};, and each consumer needs to be rewritten to refer the lazy getter with lazy.foo.
This migration is done by automated script in bug 1608279.
| Assignee | ||
Comment 1•4 years ago
|
||
| Assignee | ||
Comment 2•4 years ago
|
||
Depends on D147916
| Assignee | ||
Comment 3•4 years ago
|
||
Depends on D147917
| Assignee | ||
Comment 4•4 years ago
|
||
Depends on D147918
| Assignee | ||
Comment 5•4 years ago
|
||
Depends on D147919
| Assignee | ||
Comment 6•4 years ago
|
||
Depends on D147920
| Assignee | ||
Comment 7•4 years ago
|
||
Depends on D147921
Comment 9•4 years ago
|
||
| bugherder | ||
https://hg.mozilla.org/mozilla-central/rev/f1ce0ff966d2
https://hg.mozilla.org/mozilla-central/rev/fc2209504c63
https://hg.mozilla.org/mozilla-central/rev/9078d3c250cb
https://hg.mozilla.org/mozilla-central/rev/b6ecac27ebce
https://hg.mozilla.org/mozilla-central/rev/3c525187fcf9
https://hg.mozilla.org/mozilla-central/rev/ec1e4198a03c
https://hg.mozilla.org/mozilla-central/rev/20b091190754
Comment 10•3 years ago
|
||
This change is already causing a lot of pain on uplifts to ESR102 due to all the changes in context throughout the codebase. How practical would it be to make this (and related) changes to that branch as well given that ESR102 has over a year of support ahead of it still?
| Assignee | ||
Comment 11•3 years ago
|
||
most parts can be done mostly automatically, by the rule in bug 1608279 attachment.
I'll look into making esr102 uplift patches this and next weeks.
where should I put those patches?
| Assignee | ||
Comment 12•3 years ago
|
||
actually, there are several preparation patches, and it will be 200+ patches in total, including both preparation and rewrite.
Comment 13•3 years ago
|
||
Let's file a new bug to track everything that would have to go into ESR102 for it. Thanks!
| Assignee | ||
Updated•3 years ago
|
| Assignee | ||
Comment 14•3 years ago
|
||
filed bug 1782973
Description
•