Closed Bug 1449849 Opened 2 years ago Closed 4 months ago
Add a Latin1-or-UTF-16 Web
IDL string type
See bug 1449659 comment 1. Let's add a WebIDL string type (to be used where specs say DOMString or USVString) that can hold either a Latin1 string or a UTF-16 string. Use cases: * Getting and setting the data of DOM text nodes, which internally store Latin1 or UTF-16, without conversion. * In general, avoiding unnecessary inflation of JS engine Latin1 strings to UTF-16 in performance-sensitive APIs where the C++ side is willing to add a bit of complexity in order to gain performance (e.g. TextEncoder). * In general, avoiding unnecessary inflation to UTF-16 in APIs where the C++ side returns a value it knows to be always ASCII. Details: * When a string is passed from the JS engine to the DOM implementation, the DOM implementation should be able to access the following: - An indication of Latin1 vs. UTF-16 - A read-only view of the string valid during the call from the JS engine to the DOM. Span<const char> for Latin1 or Span<const char16_t> for UTF-16. - An indication of whether the string's storage is nsStringBuffer and if it is, the pointer to the nsStringBuffer. * When a string is passed from the DOM to the JS engine, the DOM should be able to pass an nsStringBuffer, it's filled length and an indication of whether it has Latin1 or UTF-16 semantics.
Summary: Add a Latin1-or-UTF-16 string type → Add a Latin1-or-UTF-16 WebIDL string type
> A read-only view of the string valid during the call from the JS engine to the DOM. In practice, this means the bindings have to make a copy at some point. Ideally we know whether we are OK with Latin1 on the output end before we make that copy, so we don't end up having to make two copies. If we actually add a new IDL type here, that seems doable. If we try to automagically have DOMString mean Latin1 is ok based on characteristics of the callee, that would be somewhat more difficult.
Some implementation thoughts: 1) We may want to do this with an extended attribute, after implementing <https://bugzilla.mozilla.org/show_bug.cgi?id=1359269>. But in the short term just adding a new type might be fine. 2) We may want to restrict this to function arguments and not worry about dictionary members, sequence members, etc. That would allow us to only change FakeString, effectively.
We probably ought to mention this in our MDN WebIDL guide.
Status: NEW → RESOLVED
Closed: 4 months ago
Resolution: --- → WONTFIX
You need to log in before you can comment on or make changes to this bug.