Open Bug 651810 Opened 13 years ago Updated 3 years ago

Character corruption in cookies

Categories

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

defect

Tracking

()

Tracking Status
firefox5 --- affected
firefox6 --- affected
firefox7 --- affected

People

(Reporter: christianhberg, Unassigned)

References

()

Details

(Keywords: regression, Whiteboard: [necko-backlog])

User-Agent:       Mozilla/5.0 (Windows NT 6.1; WOW64; rv:2.0) Gecko/20100101 Firefox/4.0
Build Identifier: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:2.0) Gecko/20100101 Firefox/4.0

Firefox forgets the login details every time a completely new session is started. I am using a login name which contains Swedish characters or a extended character set.


Reproducible: Always

Steps to Reproduce:
1. Save the login details on the site
2. Close the session
3. Open a new session
Actual Results:  
Warning: Selector expected.  Ruleset ignored due to bad selector.
Source File: http://www.tbg.nu/cgi-bin/login.cgi
Line: 65

Warning: Unexpected end of file while searching for closing } of invalid rule set.
Source File: http://www.tbg.nu/cgi-bin/login.cgi
Line: 65 


The site only accepts Swedish ip-numbers range and will therefore not accept international ip-numbers.
Is your Issue reproducible without Extensions in Safe-Mode and/or using a new Profile?
https://support.mozilla.com/en-US/kb/Safe+Mode
https://support.mozilla.com/en-US/kb/Managing+profiles#Creating_a_profile
Version: unspecified → 4.0 Branch
(In reply to comment #1)
> Is your Issue reproducible without Extensions in Safe-Mode and/or using a new
> Profile?
> https://support.mozilla.com/en-US/kb/Safe+Mode
> https://support.mozilla.com/en-US/kb/Managing+profiles#Creating_a_profile

Hello! 

It didn't eradicate the problem. It still persist.
I think i found out the problem. As soon as a changed the homepage to let's say google.se (Swedish Google) it would brake the autologin on www.tbg.nu. If i switched back to the default Firefox homepage and started a completely fresh session it would work again apparently.
Ooh i forgot..

It doesn't matter which homepage you start Firefox in. If you start Firefox in any other homepage or following a link that will open a new Firefox session it will break the autologin for that particular site. There could be other as well which wouldn't work and if you are using any non English characters as your login name.
Component: Bookmarks & History → Form Manager
Product: Firefox → Toolkit
QA Contact: bookmarks → form.manager
Version: 4.0 Branch → 2.0 Branch
Does this work with a Nightly?
(In reply to comment #5)
> Does this work with a Nightly?

Nope it's the same thing with the Nightfly version 6.0a1. 

If i start a new firefox session and quickly switch to another random page without letting the default firefox homepage finish loading it will break the login. The login also breaks when following links from e-mails in from example Thunderbird if i am opening them with Firefox as the default browser.
OS: Windows 7 → All
Hardware: x86 → All
Version: 2.0 Branch → Trunk
Any updates? Still not working with either 4.0.1 or 5.0 beta 3. Tried with other browsers, IE9, Chrome etc. and the login seems to be working just fine with them.

As i said FF 3.6 this login cookie on this particular site haven't been working at all ever since i upgraded to FF 4.0.

Hopes the developers takes notice!
Just made an typing error. 

What i meant it's been working with every versions prior to 4.0 and all of a sudden this irritating nuisance showed up from nowhere. 

Except 3.6.12 i believe which the developers quickly fixed. Due some bad character set.
Christian, I can't create an account on this website so if you don't mind, in order to reproduce this bug and find the origin, could you send me your login information by email (my bugzilla email account or the same one with @mozilla.com instead of @gmail.com).
Sent.

I've replaced @gmail.com with mozilla.com. Hope it's the right one?

Cheers
So I tried to reproduce the issue you described but I'm not sure I understood it correctly so here is what I did:
- Open the website;
- Log in;
- Save log in information;
- Close Firefox;
- Open Firefox again;
- Go to the website;

Actual and expected result:
Login information are shown in the login form.

Is there something I didn't do like you?
(In reply to comment #11)
> So I tried to reproduce the issue you described but I'm not sure I
> understood it correctly so here is what I did:
> - Open the website;
> - Log in;
> - Save log in information;
> - Close Firefox;
> - Open Firefox again;
> - Go to the website;
> 
> Actual and expected result:
> Login information are shown in the login form.
> 
> Is there something I didn't do like you?

First did you changed the Start Page? That's the only way to reproduce the problem as far as i know. 

Yes the login information is shown in the login form that's the problem right there. It shouldn't do that, it should autologin without having to press the login button. 

Once you saved the logininformation in Firefox it should remember it in the next visit to that site and redirect you to the News page instead of redirecting you to the login page.
I forgot. Once you saved the login form close firefox completely and open a new session. Don't forget to look in the Error Console once you visit that site.

I can't decrypt it since i don't have enough knowledge of webdesign.

Thanks!
I have been able to reproduce that. The website saves a few information inside cookies like the username and when we go back to the website, these cookies are read. But it seems that some access to the cookies corrupt the saved ones and the "ä" character in the username becomes "�". I believe that loading google.se is triggering that. Loading the extension "Cookies Manager" too.

I don't know enough how cookies work to explain that better. Though, I will try to do a regression range check later.
Status: UNCONFIRMED → NEW
Component: Form Manager → Networking: Cookies
Ever confirmed: true
Product: Toolkit → Core
QA Contact: form.manager → networking.cookies
Summary: Login fails due to bad character set using Swedish characters → Character corruption in cookies
dwitte?
Is this going through sessionstore? (Are they session cookies?)

If they are, it could be a bug there in the serialization/deserialization.
It seems to be a regression from bug 572223. According to my bisect, it is somewhere between part 2 and 3.
(In reply to comment #16)
> Is this going through sessionstore? (Are they session cookies?)
> 
> If they are, it could be a bug there in the serialization/deserialization.

If I understand it correctly, session cookies are deleted when closing the browser but I guess these cookies are here to auto-login so they might not be session cookies. Though, I have no knowledge in cookies.
Any update on this? Seems to be down prioritized by the Mozilla staff unfortunately.

Still not working in Firefox 5.xx.
Component: Networking: Cookies → General
Product: Core → Firefox
Version: Trunk → 5 Branch
OS: All → Windows 7
Hardware: All → x86
Component: General → Networking: Cookies
OS: Windows 7 → All
Product: Firefox → Core
Hardware: x86 → All
Version: 5 Branch → Trunk
Severity: normal → major
Blocks: 642945
No longer blocks: 572223
Christian, I can understand this bug might be annoying but randomly changing fields isn't going to help...
Blocks: 572223
No longer blocks: 642945
Severity: major → normal
(In reply to comment #20)
> Christian, I can understand this bug might be annoying but randomly changing
> fields isn't going to help...

I am sorry. But if you guys need my password to login, otherwise it's impossible to test the scenario. Feel free to send a pm. Thanks!
I found out that it all worked fine until just after FF 4 Beta 1. I even tried FF 4 Beta 9 which it does occur. But this bug is not prioritized at all by the Mozilla team. I feel it never will, unfortunately.

I could just as well change to a new browser. Bye bye! Firefox, you have been a great companion since all those years since you were 1.xx. 

Welcome Chrome!
Ok after going through numerous nightly builds i found the faulty build it's the 

20100730 Minefield/4.0b3pre

The one before worked but this isn't... Hope i did some help here
The one which worked for me is Minefield/4.0b3pre 20100729073046
web compat should be the primary goal here
Whiteboard: [necko-backlog]
Bulk change to priority: https://bugzilla.mozilla.org/show_bug.cgi?id=1399258
Priority: -- → P1
Bulk change to priority: https://bugzilla.mozilla.org/show_bug.cgi?id=1399258
Priority: P1 → P3

Bulk-downgrade of unassigned, >=3 years untouched DOM/Storage bug's priority.

If you have reason to believe this is wrong, please write a comment and ni :jstutte.

Severity: normal → S4
Priority: P3 → P5
You need to log in before you can comment on or make changes to this bug.