1159616 - [e10s] View Cookies button filters for www.example.com instead of example.com — existing cookies aren't shown

Status: RESOLVED DUPLICATE of bug 1144493

(Firefox :: Page Info Window, defect)

Description

[mdew]

Attachment: cookies.png

User Agent: Mozilla/5.0 (Windows NT 6.3; Win64; x64; rv:40.0) Gecko/20100101 Firefox/40.0
Build ID: 20150424073152

Steps to reproduce:

Not sure if this was intentional or not, but previous Firefox builds would show cookies on the the entire domain and not just www record. 


Actual results:

Visit http://www.engadget.com/
Open Page Info -> More Info -> Security -> View Cookies
Shows only "www.engadget.com" as default

Essentially give the user a false sense of security because nothing shows up by default, no cookies show up as a default. (When there clearly is).

Change to "engadget.com" to actually see the cookies.


Expected results:

It should default to main domain for privacy reasons (as above). If we give the user a sense that there are no/little cookies because of filtering a very specific URL that'd be a bad idea.

Comment 1

[Gingerbread Man]

Mozilla/5.0 (Windows NT 6.1; Win64; x64; rv:40.0) Gecko/20100101 Firefox/40.0
Build ID: 20150428030209

Steps to reproduce:
1. http://www.engadget.com
2. Right-click an empty area of the page and choose View Page Info.
3. Click the Security tab.
4. Click the View Cookies button.

Actual results:
The Cookies window opens, with the search bar containing www.engadget.com — search results show no matching cookies.

Expected results:
The Cookies window should open, with the search bar containing engadget.com — search results in the example given would then show multiple matching cookies. This is what happens in a non-e10s window.

Comment 2

[Tracy Walker [:tracy]]

Interesting, in a new non-e10s window this works as expected; the Search field in cookies window defaults to "engadget.com," which shows expected cookies results.  But from an e10s window the cookie Search field defaults to "www.engadget.com"  

This is not a very recent regression, but it is a regression. I'll dig up the regression range.

Comment 3

[Alice0775 White]

Pushlog:
https://hg.mozilla.org/integration/mozilla-inbound/pushloghtml?fromchange=741a15659b09&tochange=5969eb0fe8b5

Suspect: Bug 1126018

Comment 4

[Alice0775 White]

Via local build
Last Good: 56544ee8b027+5969eb0fe8b5
First Bad: 25ca03634cf5+5969eb0fe8b5

Triggered by 25ca03634cf5	Bill McCloskey — Bug 1072980 - Don't allow CPOWs to be passed to C++ code (r=mrbkap,ally,mconley)

Comment 5

[Mark Hammond [:markh] [:mhammond]]

I can repro this, but can't with the patch from bug 1144493 applied.

GingerbreadMan (or anyone else), are you able to try and reproduce this once that bug makes its way to -central?

Comment 6

[Gingerbread Man]

Mozilla/5.0 (Windows NT 6.1; Win64; x64; rv:40.0) Gecko/20100101 Firefox/40.0
Build ID: 20150505030206

(In reply to Mark Hammond [:markh] from comment #5)
> GingerbreadMan (or anyone else), are you able to try and reproduce this once
> that bug makes its way to -central?

It's fixed now.