211330 - Cookie Manager: chrome: URL does not work w/o parameters

Status: RESOLVED WONTFIX

(Core :: Networking: Cookies, enhancement, P5)

Description

[Josue Aron]

User-Agent:       Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.5a) Gecko/20030701 Mozilla Firebird/0.6
Build Identifier: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.5a) Gecko/20030701 Mozilla Firebird/0.6

When viewing the Cookie Manager by going through the preferences, the sites and associated cookies are (correctly) listed.  However, when calling the UI directly by going to chrome://communicator/content/wallet/CookieViewer.xul , the list which should have the sites and the associated cookies is empty.  I'm not sure if this is by design, but it seems that if the UI is supposed to be accessible, the actual cookies should be as well.

Reproducible: Always

Steps to Reproduce:
1.  Go to the cookie manager like you normall would.
2.  Witness all the existing cookies.
3.  In the address bar (or in a bookmark, or whatever) use the URL chrome://communicator/content/wallet/CookieViewer.xul

Actual Results:  
The Cookie Manager window opens like expected, but none of the sites that were listed when going to the cookie manager normally are listed.

Expected Results:  
It should have listed the sites, along with the associated cookies, as if the window were opened via the normal preferences.

Exists in both Mozilla 1.4 and Firebird version listed above.  Happens in default theme for both of them.

Comment 1

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

And why should that work? There is a button in prefs for opening the manager, no
need for hackish other ways.
hint: you need to pass some arguments to the .js script.

Comment 2

[Josue Aron]

Why should it work?  Why shouldn't it?  What's the good of having the UI accessible if it's empty when you get to it?

As for the button in prefs, yes, there is a button in prefs...and it only takes five clicks to get there in Firebird.  It might as well be inaccessible, as far as I'm concerned.

As for your hint, I'm assuming you mean

javascript:window.open("chrome://communicator/content/wallet/CookieViewer.xul","_blank","chrome,resizable=yes");

which still brings up a window with no entries.

Unless you have a better suggestion, in which case how about sharing instead of hinting?

Comment 3

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

No, I mean what
http://lxr.mozilla.org/seamonkey/source/extensions/cookie/resources/content/cookieOverlay.js#29
does.

 29 function viewCookies() {
 30  
window.openDialog("chrome://communicator/content/wallet/CookieViewer.xul","_blank",
 31                     "chrome,resizable=yes", "cookieManager");
 32 }  

I don't think that all the internal mozilla windows need to be accesible by just
opening an url in the browser. It is nice if it doesn,t but if an extra param or
something, let it be.

Comment 4

[[e-mail]]

confirming and futuring enhancement request.

Comment 5

[benc]

If cookie manager is hard to get to in Firebird, that should be a separate UI bug.

I think this bug is invalid because when you called the chrome URL, you got what
you asked for.

Comment 6

[Mike Connor [:mconnor]]

Between the button in prefs and the options in Tools->Cookie Manager, this is
easily accessible as-is.  I don't think that the (questionable) benefits of
being able to open the chrome URL directly is worth the increased code
maintenance required.  This would require splitting the image manager into its
own file and modifying all of the callers throughout the UI, along with
maintaining both files and making changes to both files if/when enhancements land.

Also, since this is falling into my lap as the guy doing cookies UI, I don't
intend to split these files up unless someone gives me an extremely good reason
to do so.  Taking to evaluate further, as this might happen as a byproduct of
future changes to cookiemgr, but on its own there is no compelling reason to
change this.

Comment 7

[Mike Connor [:mconnor]]

if this happens, it'll be incidental to other work.

Comment 8

[Mike Connor [:mconnor]]

marking WONTFIX.  The benefit of this is trivial compared to the detrimental
effect on code maintenance that splitting the two managers would create.