Right now, nsDOMEvent::InitEvent and nsIEventListenerManager::CreateEvent, and probably a whole host of other places use unicode to define events types. However, most of the event types are actually generated internally (like DOMFrameContentLoaded) and inside of nsDOMEvent, we generally just convert the event into an atom anyway. (like "onDOMFrameContentLoaded") - atoms are now ASCII/UTF8 so this just generates an unnecessary conversion from a string that is almost always static. so we can get rid of all sorts of NS_LITERAL_STRING("foo") and make them NS_LITERAL_CSTRING("foo") I'm putting this on my bug list, but it would be an easy, if tedious, task for anyone to take up.
Whiteboard: [good first bug]
sounds like a way I could dust my c++
As long as we don't change the API nsIDOMEvent (which is the frozen (and standard) interface where nsDOMEvent::InitEvent() comes from) I'm cool with this. Internally we can do whatever we want, but the public API's need to follow the DOM specs, where that applies.
Status: NEW → ASSIGNED
Priority: -- → P3
Target Milestone: --- → mozilla1.5alpha
Created attachment 189666 [details] [diff] [review] small test This is a small test. Please look at it and see if I'm heading in the right direction or not... Changes: - nsEventListenerManager::CreateEvent is not frozen, start here with change in .idl/.h/.cpp to nsACString. - Converted callers as required. Added conversion in nsDocument::CreateEvent - less conversion (?) in nsEventListenerManager::[Add|Remove]EventListenerByType Questions: - Appropriate conversion method nsAString -> nsCAString in this case? - Most other nsAString functions are nsDOM-stuff that are frozen and nsIDOMString per specification. Can I add duplicate functions with nsACString signatures, convert internal callers to these and make the original ones call the new with some conversion?
OS: Linux → All
Hardware: PC → All
Target Milestone: mozilla1.5alpha → ---
Alec, I'm going through old "good first bugs" that have been inactive for a while. Do you think that it's still relevant?
I suspect you're more likely to get an answer from Olli here than from Alec.
These days we use atoms and string when needed and JS needs UTF-16 anyway.
Status: ASSIGNED → RESOLVED
Last Resolved: 5 years ago
Resolution: --- → WONTFIX
You need to log in before you can comment on or make changes to this bug.