Figure out how source hooks are supposed to work when compilation can be either UTF-8 *or* UTF-16
Categories
(Core :: JavaScript Engine, task, P1)
Tracking
()
| Tracking | Status | |
|---|---|---|
| firefox68 | --- | affected |
People
(Reporter: Waldo, Assigned: Waldo)
References
Details
If you compile source text directly from UTF-8, but that source is registered as not needing to be saved because it's retrievable using the source hook, coordinates in the source will be in UTF-8 terms but the source hook will return source in UTF-16 format and accordingly index into it, in at least some places. As a consequence, code that does terrible stuff like performing content tasks -- where a function is executed in a content process by providing a function expression whose toString representation is sent over IPC and reconstituted in the content process to run -- will not work right because coordinates won't line up.
The source hook -- well, the definition of one in Gecko -- already assumes the source it loads is UTF-8, so in principle source hooks could just be changed to deal with UTF-8. But that has certain ramifications if the entire world isn't converted to direct UTF-8 compilation all at once, and it's fragile in case we need to back things out (...or restrict implementation to nightly/beta for the short term). Still not sure what to do here, but I only discovered this a dozen hours ago, so...
|
Assignee | |
Updated•5 years ago
|
Description
•