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.)
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.9a1? → blocking1.9-
Depends on: 1442039
nsDOMClassInfoID is gone as of bug 1442039, so I claim this is sorted out.
Status: NEW → RESOLVED
Last Resolved: 3 months ago
Resolution: --- → FIXED
You need to log in before you can comment on or make changes to this bug.