433959 - Page Info: "View Cookies" search also lists cookies with domain name in content

Status: RESOLVED WONTFIX

(Firefox :: Page Info Window, defect)

Description

[Marcia Knous [:marcia]]

Seen using Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.5; en-US; rv:1.9) Gecko/2008051202 Firefox/3.0

STR:
1. Run https://litmus.mozilla.org/show_test.cgi?id=5085

Expected: I would see only mozilla cookies
Actual: I see a cnn.com cookie mixed in.

See attached screenshot

Comment 1

[Dave Garrett]

Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.9pre) Gecko/2008051204 Minefield/3.0pre

Attempted to reproduce.  I see a flash of all cookies, then the list blanks.  (i.e. it works for me, but inelegantly)  Could be that on some systems it's not inputting the mozilla.com search correctly?

BTW, there is no attached screenshot as indicated in comment #0.

Comment 2

[Marcia Knous [:marcia]]

Attachment: Screenshot of issue

Comment 3

[Chris Blore]

WFM on Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.5; en-US; rv:1.9) Gecko/2008051202 Firefox/3.0, although as Dave says it does seem to flash first for me whilst it searches for the mozilla.com cookies. 

Comment 4

[Carsten Book [:Tomcat]]

i think this result is because mozilla.com is (from this screenshot) in the content section of this cookie, maybe the search uses the content string too.

Comment 5

[AndrewM]

Attachment: Screenshot which shows another occurrence, this time with spreadsheets.google.com and blog.mozilla.com

(In reply to comment #4)
> i think this result is because mozilla.com is (from this screenshot) in the
> content section of this cookie, maybe the search uses the content string too.

Yes this seems to be what is happening. Here is an example for Page Info > Security > View Cookies for Bugzilla. Note that in the list of cookies is spreadsheets.google.com which contains this in the Content field:

155071098.1210817108.1.1.utmccn=(referral)|utmcsr=wiki.mozilla.org|utmcct=/index.php|utmcmd=referral

and also blog.mozilla.com (so searching for mozilla.org in just the domain name obviously shouldn't match) contains this in the Content field:

178833399.1210898550.16.9.utmccn=(referral)|utmcsr=wiki.mozilla.org|utmcct=/WeeklyUpdates/2008-05-12|utmcmd=referral

I guess the way to fix this for 3.1 or 4 would be to add some way to search just one field of the cookie database, maybe something like 'domain:mozilla.org'. Because it's obviously very useful to have the default setting search all fields.

Comment 6

[AndrewM]

Also, how about marking as blocking bug 378668 (which added the pre-filter
behavior) and setting Hardware and OS to All? :)

Comment 7

[Dave Garrett]

Steps to reproduce easily:
1) Login to Bugzilla
2) Goto: http://www.javascripter.net/faq/settinga.htm
3) Enter cookie name "test" and value "mozilla.org"
4) Click "set cookie"
5) Go back to Bugzilla and right-click, "page info", "security", "view cookies".
6) Note that the list shows your Bugzilla login cookies AND a cookie from javascripter.net named "test" with content "mozilla.org".

Comment 8

[Dave Garrett]

The flash before search noted in comment #1 and comment #3 seems to be bug 421719.

If we do add a way to fix this by searching just the issuing domain, then for the window here we really should hide the search field in that case.  The "remove all cookies" button really shouldn't be disabled here, either.  (no reason I shouldn't be able to wipe all cookies from the current site with one button)

Comment 9

[AndrewM]

(In reply to comment #8)
> The flash before search noted in comment #1 and comment #3 seems to be bug
> 421719.
> 
> If we do add a way to fix this by searching just the issuing domain, then for
> the window here we really should hide the search field in that case.  The
> "remove all cookies" button really shouldn't be disabled here, either.  (no
> reason I shouldn't be able to wipe all cookies from the current site with one
> button)

Actually, the 'Remove All Cookies' button does just what it says, it removes *all* cookies, not just the ones that are being shown after you've typed something in the search box (or Firefox has pre-filtered the list). I think that's why it gets disabled when you have filtered the list. The dialog works the same way as if you open it via Tools > Options > Privacy > View Cookies...

Maybe the most helpful way to enable what you suggested (wiping all cookies from the current site) is if when searching by domain, Firefox could show cookies grouped by domain in a treeview format (I think that's the right term?); i.e. how they are grouped when you first open the dialog via Tools > Options > Privacy > View Cookies... In this way you could easily select the domains for which you want to delete cookies, and delete all cookies for a certain domain in one click.

Comment 10

[Dave Garrett]

I know that's what the button is for, and why it's disabled there.  I'm just saying that if it shows me a list and a button labeled "remove all" it would makes sense for the button to remove all of the things in the list.  ;)

Comment 11

[u279076]

Testers ran into this using Firefox 3.5 during the Security Testday today.  Adding [securitytestday] to the whiteboard.

Comment 12

[Philip Chee]

This appears to be working as designed. See:
<http://bonsai.mozilla.org/cvsblame.cgi?file=mozilla/browser/components/preferences/cookies.js&rev=1.19&mark=833#833>
and Bug 274712
WONTFIX?

> Adding [securitytestday] to the whiteboard.
Not security sensitive.

Comment 13

[u279076]

 > > Adding [securitytestday] to the whiteboard.
> Not security sensitive.

This does not mean that it is security sensitive.  This is a keyword for tracking bugs filed during the Security Test Day which QA is running today.

Comment 14

[Jared Wein [:jaws] (please needinfo? me)]

This filter is not designed to only filter the domain name. It is meant as a simple searching mechanism.

There could be a use-case that a person wants to remove any cookie that mentions their email address. They could search for their email address and remove all of those cookies. Fixing this bug would remove that ability.

Since the feature has existed with this behavior for so long, changing it could also hurt users who have depended on this workflow.