161636 - "[Un]Block cookies" for page w/ no hostname -> empty value

Status: VERIFIED FIXED

(Core :: Networking: Cookies, defect)

Description

[Henrik Gemal]

from bug 51266

When at the "about:" page and I select "do not 
allow cookies from this site", I'm getting an empty Site value in the Cookie 
Manager.

Comment 1

[benc]

I think it should say "local filesystem", boring but not easily misinterpreted.

See bug 107153. Global History has the same design quandary, they currenty say
"no host".

I'm going to assume this is done via javascript, which I understand less than
the HTTP version. If someone can make a small test case and attach it, that
would be nice.

Comment 2

[[e-mail]]

mvl: is this still a problem? do we have an !hostPort.IsEmpty() check in the
::Add code somewhere?

Comment 3

[[e-mail]]

this is half-fixed... we won't get an empty entry anymore, but we still throw
the prompt that says the site was successfully added.

the fix is to change nsPermissionManager::Add() to throw a failure returncode if
the host string is empty, and then add an rv exception check to a few places at
http://lxr.mozilla.org/seamonkey/source/extensions/cookie/resources/content/cookieNavigatorOverlay.xul#142

Comment 4

[benc]

For the menu items, shouldn't we be greying out the menu item?

File URL's have several other problems, because of the behavior described in bug
109982 (depending on bug 70871) means that the [un]block menu potentially can be
used to spank existing hostname entries in Cookie Sites, as well as creating
blank entries in "Stored Cookies".

I'll file a bug later (gotta run to the library now), and reference it here.

Comment 5

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

It adds "scheme:about" now. Fixed by bug 209689.

Comment 6

[benc]

depends of bug w/ patch.

VERIFIED: Mozilla 1.6f, Mac OS X

about:
file: -> downloaded version of:
http://www.mozilla.org/quality/networking/testing/cookies/jscookietest.html

Also, this new behavior leads to bug 235170.