On Fri, May 26, 2017 at 1:18 AM, Eric Rahm <er...@mozilla.com> wrote: > Limiting to modifying nsScanner might be an option, but probably not > changing all callers that use the nsAString interface. I guess we can just > UTF-16 => UTF-8 those and file a bunch of follow ups?
Yeah. The main follow-up would be https://bugzilla.mozilla.org/show_bug.cgi?id=1355106 , which would allow the avoidance of UTF-16 expansion in the innerHTML/createContextualFragment/DOMParser cases for strings that the JS engine doesn't store as 16-bit units in the first place. (Performance-wise, I see the network entry point as the main thing for the XML parser and innerHTML/createContextualFragment/DOMParser as secondary.) > One thing we've ignored are all the consumers expect output to be UTF-16, so > there's a fair amount of work on that side as well. I guess we have a viewpoint difference in terms of what the "consumers" are. I think of the DOM as a consumer, and the DOM takes Atoms (which can be looked up from UTF-8). While the callbacks in nsExpatDriver aren't bad code like nsScanner is, I don't think of the exact callback callback code as worth preserving in its precise current state. > Maybe a reasonable approach is to use a UTF-8 interface for the replacement > Rust library and work on a staged rollout: > > Start just converting UTF-16 => UTF-8 for input at the nsExpatDriver level, > UTF-8 => UTF-16 for output > Modify/replace nsScanner with something that works with UTF-8 (and > encoding_rs?), convert UTF-16 => UTF-8 for the nsAString methods > Follow up replacing nsAString methods with UTF-8 versions > Look into whether modifying the consumers of the tokenized data to handle > UTF-8 is reasonable, follow up as necessary > > WDYT? Seems good to me with the note that doing the direct UTF-8 to nsIAtom lookup would probably be a pretty immediate thing rather a true follow-up. -- Henri Sivonen hsivo...@hsivonen.fi https://hsivonen.fi/ _______________________________________________ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
