DOM Event types should be UTF8/ASCII

RESOLVED WONTFIX

Status

()

Core
DOM: Events
P3
normal
RESOLVED WONTFIX
15 years ago
4 years ago

People

(Reporter: Alec Flett, Assigned: Alec Flett)

Tracking

({memory-footprint})

Trunk
memory-footprint
Points:
---

Firefox Tracking Flags

(Not tracked)

Details

(Whiteboard: [good first bug])

Attachments

(1 attachment)

(Assignee)

Description

15 years ago
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.

Comment 1

15 years ago
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.
(Assignee)

Updated

15 years ago
Status: NEW → ASSIGNED
Priority: -- → P3
Target Milestone: --- → mozilla1.5alpha

Comment 3

13 years ago
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?

Updated

13 years ago
OS: Linux → All
Hardware: PC → All
Target Milestone: mozilla1.5alpha → ---
QA Contact: desale → events
Alec, I'm going through old "good first bugs" that have been inactive for a while. 
Do you think that it's still relevant?
Flags: needinfo?(alecf)
I suspect you're more likely to get an answer from Olli here than from Alec.
Flags: needinfo?(bugs)

Comment 6

5 years ago
These days we use atoms and string when needed and JS needs UTF-16 anyway.
Status: ASSIGNED → RESOLVED
Last Resolved: 5 years ago
Flags: needinfo?(bugs)
Resolution: --- → WONTFIX

Updated

5 years ago
Flags: needinfo?(alecf)
You need to log in before you can comment on or make changes to this bug.