Need to tidy up the extensions/cookie side of things, including: * Moving pref-popups.xul and pref-images.xul from cookie into xpfe * Finding a better home for the popup/image/install JS code currently in cookieOverlay.js * Looking at the various cookie*Overlay.xul/js bits that should be sitting elsewhere now * Other bits which I discover whilst sorting the above.

This is spun off from bug 270170

also see bug 252554 which has discussion on this

Looking at the discussions in bug 252554 the choices to put the UI bits was: a) browser/components/permissions b) xpfe/components/permissions though in either case the prefs bits would be going into: xpfe/components/prefwindow if option a) I'm assuming the js/xul files would sit in: browser/components/permissions/content and the locale files would sit in: browser/locale/en-US/chrome/browser/permissions if option b) I'm assuming the js/xul files would sit in: xpfe/components/permissions/resources or: xpfe/components/permissions/resources/content and the locale files would sit in: xpfe/components/permissions/resources/locale/en-US The popups js/xul would then presumably be moved into the permissions directory too along with renamed cookie*Overlay js/xul files. Any thoughts on the above?

Of course I also meant to say that for the suite side I'd be using the xpfe option.

Below is a list of files I'm proposing are moved and name changes where appropiate - constructive comments welcome: Currently in extensions/coookie/resources/content ================================================= cookieAcceptDialog - brought up when pref is set to ask for every cookie cookieContextOverlay - context overlay for image blocking cookieNavigatorOverlay - overlay for adding cookie, image and popup management menus to browser's Tools menu cookieOverlay - JS overlay for adding functions for opening cookieviewer and popupmanager dialogs cookiePrefsOverlay - prefs overlay for adding cookie, image and popup management prefs to the prefs tree cookieTasksOverlay - statusbar overlay for cookies when using privacy settings flag option p3p - cookie privacy settings dialog p3pDialog - cookie notification dialog brought up when clicking on statusbar cookie icon pref-cookies - cookie preferences page pref-images - image preferences page pref-popups - popup preferences page status.jpg - not used anymore taskbar-cookie.gif - currently used by p3pDialog and help viewer Currently in xpfe/communicator/resources/content ================================================ popupManager - manages site permissions for popups, images, cookies and installs aboutPopups - popups dialog brought up when clicking on statusbar popup icon Movements to xpfe/components/permissions/content ================================================ From extensions/coookie/resources/content cookieAcceptDialog cookieContextOverlay -> imageContextOverlay cookieOverlay -> permissionsOverlay cookiePrefsOverlay -> permissionsPrefsOverlay cookieTasksOverlay p3p -> cookieP3P p3pDialog -> cookieP3PNotification pref-cookies pref-images pref-popups From xpfe/communicator/resources/content popupManager -> permissionsManager aboutPopups

Don't forget the files in extensions/wallet/cookieviewer/. The seamonkey cookie manager lives there. (don't ask me why) Also, why is this discussion here, and not in bug 252554, where it already was started?

Moving to XP Apps component

Basically because the discussion there seems to be concentrating on the backend cpp stuff and I didn't want to dilute it with discussions about frontend/UI movements. I originally wasn't 100% sure that cookieviewer sat comfortably in the permissions directory but if cookieAcceptDialog is going to sit there, so should cookieviewer I suppose.

Do something about status-cookie.gif and taskbar-cookie.gif. They are directly reference from /content/*.xul to /skin/*.gif instead of using style rules (.class or #id). This creates an unwanted dependency between /content/ and /skin/, and makes it impossible to use for example an composite image for these images. status-cookie.gif: /extensions/cookie/jar.mn, line 18 -- skin/modern/communicator/cookie/status-cookie.gif (resources/skin/modern/status-cookie.gif) /extensions/cookie/jar.mn, line 22 -- skin/classic/communicator/cookie/status-cookie.gif (resources/skin/classic/status-cookie.gif) /extensions/cookie/resources/content/p3pDialog.xul, line 114 -- <image src="chrome://communicator/skin/cookie/status-cookie.gif"/> taskbar-cookie.gif /extensions/cookie/jar.mn, line 17 -- skin/modern/communicator/cookie/taskbar-cookie.gif (resources/skin/modern/taskbar-cookie.gif) /extensions/cookie/jar.mn, line 21 -- skin/classic/communicator/cookie/taskbar-cookie.gif (resources/skin/classic/taskbar-cookie.gif) /extensions/help/resources/locale/en-US/customize_help.xhtml, line 696 -- <img src="chrome://cookie/content/taskbar-cookie.gif" /extensions/help/resources/locale/en-US/using_priv_help.xhtml, line 213 -- src="chrome://cookie/content/taskbar-cookie.gif"/>) /extensions/help/resources/locale/en-US/using_priv_help.xhtml, line 522 -- src="chrome://cookie/content/taskbar-cookie.gif"/>) near the /extensions/help/resources/locale/en-US/using_priv_help.xhtml, line 572 -- src="chrome://cookie/content/taskbar-cookie.gif"/>) appears near the /extensions/help/resources/locale/en-US/using_priv_help.xhtml, line 598 -- src="chrome://cookie/content/taskbar-cookie.gif"/>) is displayed in the /themes/classic/navigator/navigator.css, line 336 -- list-style-image: url("chrome://communicator/skin/cookie/taskbar-cookie.gif"); /themes/modern/navigator/navigator.css, line 579 -- list-style-image: url("chrome://communicator/skin/cookie/taskbar-cookie.gif"); Also check out bug 226339, especially comment #2: It this also an opportunity to remove some overlays? For example, removing the cookieTaskbarOverlay.xul by moving this statusbar icon thing to the corresponding navigator.xul resp. browser.xul?

in reply to comment 5, the proposal looks generally nice. a few things: a) extensions/cookie/resources/content/cookieAcceptDialog.* (and the few related files in locale) is shared between seamonkey and firebird. all the other files can move to xpfe, but this one must remain here or be forked... since the cookie prompting cpp files live in extensions/cookie, we should probably just keep them together. b) xpfe/components/permissions/content is a tad misleading... maybe "cookies" or "privacy", instead of "permissions"? c) why the "popupManager -> permissionsManager" change? that file is about popups, not permissions, no? thanks for doing this. would you like to make those changes locally and test it out to make sure it all still works? mvl might also have some suggestions ;)

(In reply to comment #10) > in reply to comment 5, the proposal looks generally nice. a few things: > > a) extensions/cookie/resources/content/cookieAcceptDialog.* (and the few related > files in locale) is shared between seamonkey and firebird. all the other files > can move to xpfe, but this one must remain here or be forked... since the cookie > prompting cpp files live in extensions/cookie, we should probably just keep them > together. I can leave those there until the cpp files are moved to their new home (bug 252554). > b) xpfe/components/permissions/content is a tad misleading... maybe "cookies" or > "privacy", instead of "permissions"? > > c) why the "popupManager -> permissionsManager" change? that file is about > popups, not permissions, no? Once bug 270170 lands popupManager will be being used for not just popups but also images and installing updates and in the future perhaps for cookies (bug 278221). Privacy is a possible option but cookies is probably not for the directory name. For the popupManager perhaps siteManager is a better name than permissionsManager? > > thanks for doing this. would you like to make those changes locally and test it > out to make sure it all still works? mvl might also have some suggestions ;) I'm having great fun with looking at these changes locally (worms and either woodwork or can comes to mind).

hmm... it turns out there is a forked copy of cookieAcceptDialog locale files in browser/locales/en-US/chrome/cookie/. after talking to bsmedberg, i think we should move that copy to toolkit/locales/en-US/chrome/cookie/ so that seamonkey can use it, and then make extensions/cookie/jar.mn point to those files. this will have to be #ifdef'ed so that only seamonkey adds them, since toolkit has its own jar.mn. bsmedberg suggested this, for extensions/cookie/jar.mn: #ifndef MOZ_XUL_APP en-US.jar: locale/en-US/cookie/cookieAcceptDialog.dtd (/toolkit/locales/en-US/chrome/cookie/cookieAcceptDialog.dtd) locale/en-US/cookie/cookieAcceptDialog.properties (/toolkit/locales/en-US/chrome/cookie/cookieAcceptDialog.properties) #endif

This patch v0.1a does the following: * Unforks the cookieAcceptDialog locale files and moves them into toolkit/locales for both suite and firefox to use as suggested above. * Moves the cookieAcceptDialog js/xul files into toolkit/components/cookie

Comment on attachment 171877 [details] [diff] [review] cookieAcceptDialog relocation patch v0.1a r=me, though i'm torn on moving the js and xul into toolkit/components/cookie. those two files were fine where they were in extensions/cookie, but i'm ok with it because they're small and it doesn't really matter. if you just get r=bsmedberg you're probably good to land this patch.

Changes since v0.1a * js/xul files in comm.jar points to the right subfolder of toolkit now Assuming r= carried forward from dwitte and asking for r= from bsmedberg

Comment on attachment 171992 [details] [diff] [review] cookieAcceptDialog relocation patch v0.1b In toolkit/locales/jar.mn, please don't put the cookie files at the top of the list, they're not that important ;) Somewhere logical after the "global" package is a good place. I also think you're missing changes to toolkit/components/cookie/jar.mn or something similar?

Changes since v0.1b * Moved position of cookieAcceptDialog locale files in toolkit/locales/jar.mn to after global and mozapps files * #ifndef out cookieAcceptDialog content files in extensions/cookie/jar.mn and made necessary changes to add them via toolkit/components/cookie/jar.mn Carrying forward r= Once rest of files in content/cookie are relocated to new homes then cookieAcceptDialog content files could move from comm.jar to toolkit.jar

Comment on attachment 172114 [details] [diff] [review] revised cookieAcceptDialog relocation patch v0.1c For the cvs history moves: cookieAcceptDialog.dtd and cookieAcceptDialog.properties are moving from extensions/cookie/resources/locale/en-US to toolkit/locales/en-US/chrome/cookie cookieAcceptDialog.js and cookieAcceptDialog.xul are moving from extensions/cookie/resources/content to toolkit/components/cookie/content Requesting sr=

Comment on attachment 172617 [details] [diff] [review] Unbitrotted version of cookieAcceptDialog relocation patch v0.1d Changes since v0.1c * Unbitrotted browser and toolkit locales' jar.mn files r= carried forward again

This patch: * moves pref-cookies, pref-images and pref-popups from extension/cookie to xpfe/components/prefwindow * moves xul/dtd from cookiePrefsOverlay into preftree * updates chrome references to reflect prefs new location

Comment on attachment 172623 [details] [diff] [review] extension/cookie pref files relocation patch v0.1 moving request to dwitte. He has spend more thoughts on this.

Comment on attachment 172623 [details] [diff] [review] extension/cookie pref files relocation patch v0.1 Ian, are we ready to do the movements you suggested in comment 5 (excepting the acceptdialog fu you've patched separately)? If so, it'd be nice to do them all in one patch so we get it out of the way. Localization changes can't go in after beta, so the easier we get this in the better :)

Comment on attachment 172623 [details] [diff] [review] extension/cookie pref files relocation patch v0.1 >Index: extensions/wallet/resources/content/walletPrefsOverlay.xul this change shouldn't be here, right? >Index: xpfe/components/prefwindow/resources/content/preftree.xul >- <treechildren id="securityChildren"/> >+ <treechildren id="securityChildren"> howcome we need to add the three items explicitly here? i thought we were just shifting stuff, not changing implementation, but i might be missing something. >Index: xpfe/components/prefwindow/resources/locale/en-US/preftree.dtd same here.

(In reply to comment #23) > Localization changes can't go in > after beta, so the easier we get this in the better :) I'm not completely sure of how we handle this when actually doing two betas... Probably the L10n freeze is getting pushed out to beta2 as well...

(In reply to comment #24) > (From update of attachment 172623 [details] [diff] [review] [edit]) > >Index: extensions/wallet/resources/content/walletPrefsOverlay.xul > > this change shouldn't be here, right? > > >Index: xpfe/components/prefwindow/resources/content/preftree.xul > >- <treechildren id="securityChildren"/> > >+ <treechildren id="securityChildren"> > > howcome we need to add the three items explicitly here? i thought we were just > shifting stuff, not changing implementation, but i might be missing something. > > >Index: xpfe/components/prefwindow/resources/locale/en-US/preftree.dtd > > same here. > Once I started looking at the pref pages and how it is done for all other items under xpfe/components, it took me down the route of merging the "extensions/cookie" prefs into the existing pref code as none of the components have any overlays. I should probably split the merging part off into another bug once I have moved stuff round.

Updated file movement list below - main changes are: * Code shared between seamonkey and toolkit now in toolkit part of tree * Pref related code now being moved to xpfe/components/prefwindow as per other xpfe/components code * cookieviewer now included with code being moved to xpfe/components/permissions Movements to toolkit/components/cookie/content ================================================ From extensions/coookie/resources/content cookieAcceptDialog Movements to xpfe/components/prefwindow/content =============================================== From extensions/coookie/resources/content cookiePrefsOverlay pref-cookies pref-images pref-popups Movements to xpfe/components/permissions/content ================================================ From extensions/coookie/resources/content cookieContextOverlay -> imageContextOverlay cookieOverlay -> permissionsOverlay cookieTasksOverlay p3p -> cookieP3P p3pDialog -> cookieP3PDialog From extensions/cookie/resources/content CookieViewer -> cookieViewer nsWalletTreeUtils -> treeUtils From xpfe/communicator/resources/content popupManager -> permissionsManager aboutPopups

Does anyone know if cookie.properties is still actually used by embedding or is it just left over? Which bits of the Wallet stuff are still being used? Esp wrt to bug 234109 From embed-jar.mn: # Wallet and Cookie stuff locale/XXXX/communicator/wallet, XXXX/locale/XXXX/communicator/wallet content/cookie/contents.rdf, comm/content/cookie/contents.rdf locale/XXXX/cookie/contents.rdf, XXXX/locale/XXXX/cookie/contents.rdf locale/XXXX/cookie/cookie.properties, XXXX/locale/XXXX/cookie/cookie.properties

I couldn't find any use for cookie.properties in extensions/cookie or browser/components/cookieviewer code. (I removed it and nothing broke). I can't speak for seamonkey's wallet, but I'd suspect the same story.

(In reply to comment #29) > I couldn't find any use for cookie.properties in extensions/cookie or > browser/components/cookieviewer code. (I removed it and nothing broke). I can't > speak for seamonkey's wallet, but I'd suspect the same story. SeaMonkey's wallet is still in use in SeaMonkey, I'd think...

Yes, wallet is still in use in Seamonkey, I was just trying to find out if wallet/cookie stuff was still inuse for embedded.

This patch does: * All the movement and name changes as below: Movements to themes/classic/communicator/permissions ==================================================== From extensions/cookie/resources/skin/classic status-cookie.gif taskbar-cookie.gif Movements to themes/modern/communicator/permissions ==================================================== From extensions/cookie/resources/skin/modern status-cookie.gif taskbar-cookie.gif Movements to toolkit/components/cookie/content ============================================== From extensions/cookie/resources/content cookieAcceptDialog.xul cookieAcceptDialog.js Movements to toolkit/locales/en-US/chrome/cookie ================================================ From extensions/cookie/resources/locale/en-US contents.rdf cookie.properties cookieAcceptDialog.dtd cookieAcceptDialog.properties Movements to toolkit/locales/generic/chrome/cookie ================================================ From browser/locales/generic/chrome/cookie contents.rdf Movements to xpfe/components/prefwindow/resources/content ========================================================= From extensions/coookie/resources/content cookiePrefsOverlay.xul pref-cookies.xul pref-images.xul pref-popups.xul Movements to xpfe/components/prefwindow/resources/locale/en-US ============================================================== From extensions/coookie/resources/locale/en-US cookiePrefsOverlay.dtd pref-cookies.dtd pref-images.dtd pref-popups.dtd Movements to xpfe/components/permissions/content ================================================ From extensions/coookie/resources/content cookieContextOverlay.xul -> imageContextOverlay.xul cookieNavigatorOverlay.xul -> permissionsNavigatorOverlay.xul cookieOverlay.js -> permissionsOverlay.js cookieTasksOverlay.xul p3p.xul -> cookieP3P.xul p3pDialog.xul -> cookieP3PDialog.xul From extensions/wallet/cookieviewer/resources/content CookieViewer.js -> cookieViewer.js CookieViewer.xul -> cookieViewer.xul nsWalletTreeUtils.js -> treeUtils.js From xpfe/communicator/resources/content popupManager.js -> permissionsManager.js popupManager.xul -> permissionsManager.xul aboutPopups.xul Movements to xpfe/components/permissions/locale/en-US ===================================================== From extensions/coookie/resources/locale/en-US cookieContextOverlay.dtd -> imageContextOverlay.dtd cookieNavigatorOverlay.dtd -> permissionsNavigatorOverlay.dtd cookieTasksOverlay.dtd p3p.dtd -> cookieP3P.dtd From extensions/wallet/cookieviewer/resources/locale/en-US CookieViewer.dtd -> cookieViewer.dtd CookieViewer.properties -> cookieViewer.properties From xpfe/communicator/resources/locale/en-US popupManager.dtd -> permissionsManager.dtd popupManager.properties -> permissionsManager.properties aboutPopups.dtd I've not touched the help pages as bug 249744 will deal with this. There is also the cookie.properties issue but, again, this could probably be dealt with outside of this bug.

Comment on attachment 173389 [details] [diff] [review] all of it patch v0.2 config/make-chromelist.pl this looks unrelated. toolkit/locales/en-US/chrome/cookie/contents.rdf toolkit/locales/generic/chrome/cookie/contents.rdf you have these two files, but only the locales/generic one listed in toolkit/locales/jar.mn. (the old case with browser/locales/jar.mn had only the locales/generic one too). i don't know much about how the contents.rdf system works - can you explain what the second one is for? xpfe/components/prefwindow/resources/content/pref-help.js you have some unrelated changes in here too. since we're not using the #ifndef MOZ_XUL_APP way of jarring cookieviewer correctly for both seamonkey and the toolkit apps happy anymore, can you explain how your current patch works? looks good (and big, phew!), can you tidy up those bits and repost? also, how much have you tested this with firefox and seamonkey? if we land this during beta, we want to do it early and be fairly sure it'll work :)

(In reply to comment #33) > (From update of attachment 173389 [details] [diff] [review] [edit]) The easy bit first: > > xpfe/components/prefwindow/resources/content/pref-help.js > > you have some unrelated changes in here too. Yes I do, missed that update when checking. Now the hard bit: > config/make-chromelist.pl > > this looks unrelated. > > toolkit/locales/en-US/chrome/cookie/contents.rdf > toolkit/locales/generic/chrome/cookie/contents.rdf > > you have these two files, but only the locales/generic one listed in > toolkit/locales/jar.mn. (the old case with browser/locales/jar.mn had only the > locales/generic one too). i don't know much about how the contents.rdf system > works - can you explain what the second one is for? > > since we're not using the #ifndef MOZ_XUL_APP way of jarring cookieviewer > correctly for both seamonkey and the toolkit apps happy anymore, can you > explain how your current patch works? All this is related to how the current patch works. The cookieAcceptDialog is jarred via xpfe/components/jar for seamonkey (using toolkit/locales/en-US/chrome/cookie/contents.rdf) and toolkit/components/cookie/jar.mn and toolkit/locales/jar.mn (using toolkit/locales/generic/chrome/cookie/contents.rdf) for firefox. The changes to make-chromelist.pl are so that the /toolkit entries in xpfe/components/jar.mn do not appear as xpfe/components//toolkit in chromelist.txt > > looks good (and big, phew!), can you tidy up those bits and repost? also, how > much have you tested this with firefox and seamonkey? if we land this during > beta, we want to do it early and be fairly sure it'll work :) > I've tested building and using this patch on firefox and seamonkey on win32, making sure I can get into all the preference/options and cookie/image/popup managers, bringing up the about popups dialog, the p3p dialog and the cookieAcceptDialog.

Comment on attachment 173389 [details] [diff] [review] all of it patch v0.2 > The changes to make-chromelist.pl are so that the /toolkit entries in > xpfe/components/jar.mn do not appear as xpfe/components//toolkit in chromelist.txt I'll have to defer to bsmedberg on that one. Ben, can you please take a look at just the changes to make-chromelist.pl in this enormous patch, with Ian's comment above in mind? See comment 32 if you want to know vaguely what's going on.

Comment on attachment 173389 [details] [diff] [review] all of it patch v0.2 toolkit/locales/en-US/chrome/cookie/contents.rdf This file should not be there, you want toolkit/locales/generic/chrome/cookie/contents.rdf If you need something like it for xpfe/components/jar.mn, you should put another copy of that contents.rdf under xpfe/components somewhere. As for the changes to make-chromelist, it looks fine (though I suspect it is totally broken for the toolkit apps).

Changes since v0.2 * contents.rdf now moves from extensions/cookie/resources/locale/en-US to xpfe/components/cookie/locale/en-US instead of toolkit/locales/en-US/chrome/cookie * pref-cookies.xul/.dtd is updated to version from patch v0.1c of bug 239557 Tested everything works on both mozilla and firefox win32 builds

Comment on attachment 174107 [details] [diff] [review] Updated complete movement patch v0.2a looks good, r=me. (i haven't read through it again, it sounds good based on what you said)

Comment on attachment 174107 [details] [diff] [review] Updated complete movement patch v0.2a >Index: config/make-chromelist.pl >- $cvsfile = File::Spec::Unix->catfile($stub, $cvsfile); >+ if ($cvsfile =~ m|^/|) { >+ $cvsfile =~ s/^\///; >+ $cvsfile = File::Spec::Unix->catfile($cvsfile); >+ } else { >+ $cvsfile = File::Spec::Unix->catfile($stub, $cvsfile); >+ } can you explain what this is all about? should there be a comment explaining why you are doing this? I'd like to see a patch for any actual changes to the files if possible. Please work with justdave@mozilla.org or myk@mozilla.org to move the CVS files around to preserve CVS blame as much as possible.

darin, the make-chromelist changes are good, it is adding support for the "file (/absolute/path)" syntax that I added to the make-jars.pl scripts.

This should be a diff of files regardless of new name/position within the tree. If it is not listed then is no difference. Addtional changes compared to patch v0.2a * I've added a comment to make-chromelist.pl * Unbitrotted a couple of files

Updated list of file moves

Ian, how're things coming? I hope we can get this in for 1.8b2 ;) (If justdave/myk aren't responsive, we'll have to go ahead and land anyway, and soon - have you tried both of them?)

For my work it has to be fixed for 1.8b2.

I spoke to justdave on IRC today and he said he'd got the script for doing the moves, de-tagging, etc and was hoping to do the work today. Once he has done that work I can then land all the updates.

Ian: no matter of justdave's work, those patches need to be updated. And we're running out of time (1.8b2 is sheduled on 16th of march). Can I help you somehow to make this checkin sooner?

OK, in doing the pre-flight checks in prep for this cvs copy, the following problems were encountered: xpfe/components/prefwindow/resources/content/Attic/pref-cookies.xul,v already exists xpfe/components/prefwindow/resources/content/Attic/pref-images.xul,v already exists xpfe/components/prefwindow/resources/locale/en-US/Attic/pref-cookies.dtd,v already exists xpfe/components/prefwindow/resources/locale/en-US/Attic/pref-images.dtd,v already exists This is a showstopper to doing a cvs copy for these 4 files. It can be dealt with, but someone needs to make a decision on which version's history is going to get kept. I can either nuke the ones in the Attic when I copy the new ones in, or someone can resurrect the dead files as part of your patch instead of having the files copied.

Those files are still live on other branches, too, so destroying the existing ones in the Attic would cause problems. Your best bets are either to resurrect the ones from the Attic and forgo having the recent history from the source location of this move, or to alter the destination filenames slightly so they don't conflict with the existing files.

I'd propose to go for resurrecting those files from Attic, as it's basically the same files going back to where they belong... And they locale files might have to move again elsewhere with source L10n work anyways...

The recent history should still be available from the attic of extensions/cookies... shouldn't it? So we should forgo the recent history for those 4 items. Basically what Robert said. P.S. Sorry about too many Os

(In reply to comment #50) > The recent history should still be available from the attic of > extensions/cookies... shouldn't it? So we should forgo the recent history for > those 4 items. Right, you'll still have the history of the files where they are now, the history just doesn't move with them. OK, the cvs copy is completed. You should be able to cvs update and have all the files at the new locations now, with the exception of those four. Those four someone will need to manually copy, then "cvs add", which will resurrect the files in the Attic on commit. The files at the old locations will need to be cvs deleted as part of your checkin.

I think I've caught all the outstanding removals, marking fixed. Spun removal of cookie.properties off into Bug 285683

Was this improvement included in Firefox trunk builds? I'm having cookie problems with builds released after the official 20050310 build; see https://bugzilla.mozilla.org/show_bug.cgi?id=285709 for more info.

(In reply to comment #53) > Was this improvement included in Firefox trunk builds? > I'm having cookie problems with builds released after the official 20050310 > build; see https://bugzilla.mozilla.org/show_bug.cgi?id=285709 for more info. My bad, it is included in latest trunk builds.