User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9.0.5) Gecko/2008120122 Firefox/3.0.5 XPCOMViewer/1.0a1 Build Identifier: nsIAccessibleValue readonly atribute removed: attribute double removed method: boolean setCurrentValue (in double value); Reproducible: Always Actual Results: old uuid Expected Results: new uuid

Do we actually want to make a change like that on the stable branch?

(In reply to comment #2) > Do we actually want to make a change like that on the stable branch? Can it prevent the work of 3d party XPCOM components?

3rd-party components are already screwed, because they can't tell the difference between the old version and the new version. Changing the UUID now, after we have a release which is "broken", doesn't seem like it would help much.

Should we fix this at all?

"good question". Revving the iid for 1.9.1 might be a good idea. It'll cause a bit more hassle for someone trying to support 1.9.1 and 1.9.0, but make it easier to support both 1.9.0 and 1.8.x....

I don't think it'll help with 1.9.0 and 1.8.x, since those version have different interfaces with the same UUID. I think this should be WONTFIX.

er, I meant 1.9.1 and 1.8.x.

As reporter points out in the newsgroup, for tbird this would in fact help with 1.9.0 vs 1.8. What a mess. :(

I wonder if we can catch these bugs earlier, perhaps with some source code analyzer that checks for stale uuids?

See discussion in .platform.

tbird is shipping off 1.9.1, not 1.9.0. Clearing flag because I think the 1.9.0 nomination was based on that mistaken idea. In any case it's not going to make 1.9.0.7

Pushed http://hg.mozilla.org/mozilla-central/rev/e2a835161553 and http://hg.mozilla.org/releases/mozilla-1.9.1/rev/870c4fe1e755

Seeing as there hasn't been any discussions about this bug for 2 months, I'm guessing there aren't any residual issues. I'm moving this to verified as a result. If anyone has any qualms, feel free to bring them up.