Closed
Bug 201422
Opened 22 years ago
Closed 12 years ago
DOM Event types should be UTF8/ASCII
Categories
(Core :: DOM: Events, defect, P3)
Core
DOM: Events
Tracking
()
RESOLVED
WONTFIX
People
(Reporter: alecf, Assigned: alecf)
Details
(Keywords: memory-footprint, Whiteboard: [good first bug])
Attachments
(1 file)
23.40 KB,
patch
|
Details | Diff | Splinter Review |
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.
![]() |
||
Updated•22 years ago
|
Whiteboard: [good first bug]
Comment 1•22 years ago
|
||
sounds like a way I could dust my c++
Comment 2•22 years ago
|
||
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•22 years ago
|
Status: NEW → ASSIGNED
Priority: -- → P3
Target Milestone: --- → mozilla1.5alpha
Comment 3•20 years ago
|
||
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•20 years ago
|
OS: Linux → All
Hardware: PC → All
Target Milestone: mozilla1.5alpha → ---
Updated•15 years ago
|
QA Contact: desale → events
Comment 4•12 years ago
|
||
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)
![]() |
||
Comment 5•12 years ago
|
||
I suspect you're more likely to get an answer from Olli here than from Alec.
Flags: needinfo?(bugs)
Comment 6•12 years ago
|
||
These days we use atoms and string when needed and JS needs UTF-16 anyway.
Status: ASSIGNED → RESOLVED
Closed: 12 years ago
Flags: needinfo?(bugs)
Resolution: --- → WONTFIX
Updated•12 years ago
|
Flags: needinfo?(alecf)
You need to log in
before you can comment on or make changes to this bug.
Description
•