277097 - Tidy up cookie js/xul/pref code

Status: RESOLVED FIXED

(SeaMonkey :: UI Design, defect)

Description

[Ian Neal]

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.

Comment 1

[Ian Neal]

This is spun off from bug 270170

Comment 2

[Michiel van Leeuwen (email: mvl+moz@)]

also see bug 252554 which has discussion on this

Comment 3

[Ian Neal]

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?

Comment 4

[Ian Neal]

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

Comment 5

[Ian Neal]

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

Comment 6

[Michiel van Leeuwen (email: mvl+moz@)]

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?

Comment 7

[Ian Neal]

Moving to XP Apps component

Comment 8

[Ian Neal]

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.

Comment 9

[Alfred Kayser]

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?

Comment 10

[[e-mail]]

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 ;)

Comment 11

[Ian Neal]

(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).

Comment 12

[[e-mail]]

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

Comment 13

[Ian Neal]

Attachment: cookieAcceptDialog relocation patch v0.1a

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 14

[[e-mail]]

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.

Comment 15

[Ian Neal]

Attachment: cookieAcceptDialog relocation patch v0.1b

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 16

[Benjamin Smedberg]

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?

Comment 17

[Ian Neal]

Attachment: revised cookieAcceptDialog relocation patch v0.1c

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 18

[Ian Neal]

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 19

[Ian Neal]

Attachment: Unbitrotted version of cookieAcceptDialog relocation patch v0.1d

Comment 20

[Ian Neal]

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

Comment 21

[Ian Neal]

Attachment: extension/cookie pref files relocation patch v0.1

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 22

[Michiel van Leeuwen (email: mvl+moz@)]

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 23

[[e-mail]]

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 24

[[e-mail]]

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.

Comment 25

[Robert Kaiser]

(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...

Comment 26

[Ian Neal]

(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.

Comment 27

[Ian Neal]

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

Comment 28

[Ian Neal]

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

Comment 29

[[e-mail]]

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.

Comment 30

[Robert Kaiser]

(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...

Comment 31

[Ian Neal]

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

Comment 32

[Ian Neal]

Attachment: all of it patch v0.2

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 33

[[e-mail]]

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 :)

Comment 34

[Ian Neal]

(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 35

[[e-mail]]

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 36

[Benjamin Smedberg]

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).

Comment 37

[Ian Neal]

Attachment: Updated complete movement patch v0.2a

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 38

[[e-mail]]

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 39

[Darin Fisher]

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 [e-mail] or [e-mail]
to move the CVS files around to preserve CVS blame as much as
possible.

Comment 40

[Benjamin Smedberg]

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.

Comment 41

[Ian Neal]

Attachment: Diff between files regardless of new name/position

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

Comment 42

[Ian Neal]

Attachment: List of filemoves v0.1d

Updated list of file moves

Comment 43

[[e-mail]]

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?)

Comment 44

[Zibi Braniecki [:zbraniecki][:gandalf]]

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

Comment 45

[Ian Neal]

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.

Comment 46

[Zibi Braniecki [:zbraniecki][:gandalf]]

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?

Comment 47

[Dave Miller [:justdave]]

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.

Comment 48

[Dave Miller [:justdave]]

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.

Comment 49

[Robert Kaiser]

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...

Comment 50

[Ian Neal]

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

Comment 51

[Dave Miller [:justdave]]

(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.

Comment 52

[Ian Neal]

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

Comment 53

[plutot]

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.

Comment 54

[plutot]

(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.