User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:220.127.116.11) Gecko/2008120122 Firefox/3.0.5 XPCOMViewer/1.0a1 Build Identifier: Build Identifier: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9.1b3pre) Gecko/20081210 Thunderbird/3.0b1 new method: void DumpHeap(in string fileName); Reproducible: Always Actual Results: old uuid Expected Results: new uuid
So erm, this happened sometime in 2007. A few days ago, a new change was checked in, and all the UUIDs were updated. I'm fairly sure this is now unfixable - I mean, there are already (many) released binaries in the wild which have the same old UUID for this changed version of the interface. The only thing I can think of is changing it on branch, but I'm not sure what the merits of that are at this point. Igor, opinions?
I am not the right person to ask that question as I I only recently has learned about the need to change ids when changing interfaces.
I do a binnary extension. I want to support with one dll gecko 1.8 and 1.9. For extension developer it is important to distinguish unfrozen interfaces. I want it in Thunderbird b2 if it is possible. I think it is gecko 1.9.1. The best way is put it into all affected branches. Next build from that branch will fix this bug. Is it problem? At least ,if it is possible yet give it into 1.9.1, 1.9.2 and into trunk.
This isn't only uuid interface bug I reported today. I reported (open discussion) it to mozilla.dev.platform Subject "Interface's uuid problem" If you are not shre where to put patch ask there probably someone answers you.
As I said in comment #1, the UUID on trunk has already changed - changing it again won't help. A branch patch for 1.9.1 may be useful. I don't believe there is a 1.9.2 branch - trunk is used for 1.9.2 development. If that is not the case, then that has been poorly communicated - I can't find mentions on planet.m.o or in the m.d.planning newsgroup, or on wiki.m.o .
The problem with patching the stable branch is that that might break existing extensions written for it...
"stable branch" == 1.9.0 here, since that's where the problem the reporter ran into actually exists...
(In reply to comment #7) > "stable branch" == 1.9.0 here, since that's where the problem the reporter ran > into actually exists... Right, but fixing this branch is useless at this point, isn't it? I mean, there are already lots of users which will have a browser with an interface with a UUID that is the same, and somehow (!?) the add-on developer will already have to deal with this. Even if 18.104.22.168 is fixed, 22.214.171.124-5 will still be broken. Presumably there would be a hackaround for the developer for these builds, somehow, which could also be applied for any remaining releases off 1.9.0. I will confess I am unfamiliar with binary add-ons, so I am not sure if there are reasons that make it worthwhile to still do this, impossible to hackaround, etc., so please feel free to enlighten me in this respect...
Given that this is in a prior stable release, I think it should be WONTFIX.
Firefox isn't the only thing we release based on Gecko. There's no shipping 1.9.0-based tbird, for example... Let's sort all of this out in .planning before closing bugs, ok?
I meant .platform.
Created attachment 359539 [details] [diff] [review] Patch for 1.9.1 This is a patch against the 1.9.1 branch. Josh, if you are going to land your Unicode-izations on 1.9.1 (thus rev'ing the ID again), can you please let us know? I assumed you weren't, as it seems like a change that's a bit much to take at this point in the game for 1.9.1...
Created attachment 359641 [details] [diff] [review] proper style the patch that added this function wasn't given sr. and should never have been given sr. It violates a number of rules. interCaps method naming, adding methods at the end. Since we're reving the interface anyway, i'd like to fix the name and location. We're breaking any consumer anyway, and the js ones can handle function case naming if they care (we did it for nsIRunnable years ago).
Comment on attachment 359641 [details] [diff] [review] proper style I can't review js/jsd patches, only Vnk internals. Leaving it to you to pick someone else. Sorry!
Comment on attachment 359641 [details] [diff] [review] proper style as for the l10n stuff, it makes the api usable, who would we want to discuss with about making that change? i generally don't care about branches, if you're my consumer and want the stuff to work and are willing to ask for it to go back to 1.9.1, i'm fine w/ working or supporting the backport.
Comment on attachment 359641 [details] [diff] [review] proper style This looks ok if you keep the AUTF8String thing.
This is a change we're making on 1.9.1? We'd need to document it with late-compat, although it's unlikely very many extension authors are using this API. Is firebug?
(In reply to comment #13) > Created an attachment (id=359641) [details] > proper style > > the patch that added this function wasn't given sr. and should never have been > given sr. It violates a number of rules. interCaps method naming, adding > methods at the end. You're so right -- how did I miss all that? I re-read the patch just a few minutes ago and still missed the IDL. Read the raw diff and saw it. Sorry, > Since we're reving the interface anyway, i'd like to fix the name and location. > We're breaking any consumer anyway, and the js ones can handle function case > naming if they care (we did it for nsIRunnable years ago). Please fix up the name and location. Thanks, /be
(In reply to comment #17) > This is a change we're making on 1.9.1? We'd need to document it with > late-compat, although it's unlikely very many extension authors are using this > API. Is firebug? Yes this API is the basis for firebug js debugging (and venkman). A few others use it for odd purposes. Other than disagreeing with the design decision to add a method like dumpHeap() to this API, the change would not seem to affect Firebug in any way.
johnjbarton: I can't tell from comment 19 whether you are or aren't using the dumpHeap API...
Oh, sorry I didn't understand the scope of your first question. We don't use dumpHeap, don't even know what it does.
We could take dumpHeap out. Wouldn't that be better? Igor, why did you add it? I completely missed it, so never asked. /be
(In reply to comment #22) > We could take dumpHeap out. Wouldn't that be better? > > Igor, why did you add it? I completely missed it, so never asked. Before the patch for the bug 378261 jsdService::GC (implementing jsdIDebuggerService::GC) was printing the GC heap if GC_MARK_DEBUG was defined using js_DumpGCHeap variable. Since the patch replaced that by a separated function, I added DumpHeap to the interface so the users of the interface can still get heap dumping functionality.
As per today's meeting, want to get all the UUID revs in for b3 ...
Comment on attachment 359641 [details] [diff] [review] proper style r=bzbarsky too, for what it's worth. Please land on m-c and 1.9.1?
Created attachment 360667 [details] [diff] [review] for checkin I know I'm supposed to be a better checkin slave than this, but the constant tinderbox failures are defeating my every attempt to push anything.
Pushed http://hg.mozilla.org/mozilla-central/rev/8c55fb9f075b and http://hg.mozilla.org/releases/mozilla-1.9.1/rev/fb4b5058c2fb