Closed Bug 340901 Opened 18 years ago Closed 7 years ago

sort out enum nsDOMClassInfoID frozenness

Categories

(Core :: DOM: Core & HTML, defect)

1.8 Branch
defect
Not set
normal

Tracking

()

RESOLVED FIXED

People

(Reporter: dbaron, Unassigned)

References

Details

The frozenness of the enum values in enum nsDOMClassInfoID is sort of a mess. A whole bunch changed between 1.7 and 1.8 because stuff got added in the middle. And the branch landings for 1.8.1 are creating a bit of a mess; things are ending up in a different order on branch and trunk. If we want this to be frozen (for whom? It's frozen, but why do we care?), we need to have big comments that say: /******** IDs above this line are frozen as of Mozilla 1.8 ********/ /******** IDs above this line are frozen as of Mozilla 1.8.1 ********/ etc. And there might have been some insertion-in-the-middle between 1.8 and 1.8.1, which we should fix before 1.8.1 ships. (It might also be nice to get rid of the on-by-default ifdefs above those lines, but that's another issue. Sort of.)
Flags: blocking1.9a1?
Flags: blocking1.8.1?
Flags: blocking1.8.1? → blocking1.8.1+
I talked to jst about this on Friday and he thought we should give up on the idea that these IDs are frozen.
Clearing blocking1.8.1 on that basis.
Flags: blocking1.8.1+
Flags: blocking1.9a1? → blocking1.9-
Whiteboard: [wanted-1.9]
Flags: wanted1.9+
Whiteboard: [wanted-1.9]
Assignee: general → nobody
QA Contact: ian → general
Depends on: 1442039
nsDOMClassInfoID is gone as of bug 1442039, so I claim this is sorted out.
Status: NEW → RESOLVED
Closed: 7 years ago
Resolution: --- → FIXED
Component: DOM → DOM: Core & HTML
You need to log in before you can comment on or make changes to this bug.