Closed
Bug 195391
Opened 22 years ago
Closed 22 years ago
cookies for background color and font size are not being set properly
Categories
(Core :: Networking: Cookies, defect)
Core
Networking: Cookies
Tracking
()
RESOLVED
FIXED
People
(Reporter: brant, Assigned: dwitte)
References
()
Details
Attachments
(1 file)
(deleted),
patch
|
dwitte
:
review+
darin.moz
:
superreview+
|
Details | Diff | Splinter Review |
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.3b) Gecko/20030226
Build Identifier: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.3b) Gecko/20030226
In a recent build of Mozilla including this current build, Mozilla seems to have
quit accepting the cookies I have set for background color and font size. These
are being set properly in Internet Explorer, however. I think I read that there
have been some recent cookie code changes so I though this might be related.
Reproducible: Always
Steps to Reproduce:
1. Set Headlines. (works)
2. Set Columns. (works)
3. Set Font Size. (does not work)
4. Set Background Color. (does not work)
Actual Results:
The Font Size and Backgroudn Color are stuck at their default values.
Expected Results:
It should set the appropriate cookies.
More details of this problem may be found in the message thread at
<http://www.shellcity.net/phpBB/viewtopic.php?topic=2363&forum=5&start=0>.
*** Bug 195392 has been marked as a duplicate of this bug. ***
OS: All - seeing this on Linux to.
OS: Windows XP → All
Hardware: PC → All
Comment 3•22 years ago
|
||
I looked at this with ethereal, and this is what I guess is the problem:
Cookies are not send when requesting http://domain/path when the path that the
cookie has is /path (In this case, path is the complete filename, /blah/style.cgi)
From an old build:
[michiel@epsilon bin]$ ./run-mozilla.sh ./TestCookie
setting cookie for "http://blah/path/file" : "aaa=bbb; path=/path" was set.
retrieving cookie(s) for "http://blah/path" : FOUND: aaa=bbb
retrieving cookie(s) for "http://blah/2path2" : NOT-FOUND
A recent build:
[michiel@epsilon bin]$ ./run-mozilla.sh ./TestCookie
setting cookie for "http://blah/path/file" : "aaa=bbb; path=/path" was set.
retrieving cookie(s) for "http://blah/path" : FOUND:
retrieving cookie(s) for "http://blah/2path2" : FOUND:
retrieving cookie(s) for "http://blah/path/" : FOUND: aaa=bbb
From rfc 2109: "The Path attribute of the cookie must match a prefix of the
request-URI."
So the first test in the new build should return the cookie.
I guess this comes from dwitte's first part of the cookie rewrite (bug 177698)
Comment 4•22 years ago
|
||
-> dwitte
increasing severity. we are likely to see this problem on many other sites.
Assignee: darin → dwitte
Severity: major → critical
Updated•22 years ago
|
Flags: blocking1.4a?
Comment 5•22 years ago
|
||
The test for the length of the path was too early.
I'm not sure what happens when cookiePathLen > path.Length(). Will substring
break then?
Leaving this patch to dwitte to take care of, and to figure the above out :)
Assignee | ||
Comment 6•22 years ago
|
||
Comment on attachment 115998 [details] [diff] [review]
Move the test for pathlength
sorry for the regression :)
Substring behaves fine if you ask for more length than the string has, so
that's fine.
mvl also fixed another 'bug' - ToNewCString will return a valid ptr if the
string is empty, but previously we return nsnull. Best to keep behavior
consistent until we can get a proper return code out of GetCookie (new API)...
r=dwitte.
Attachment #115998 -
Flags: superreview?(darin)
Attachment #115998 -
Flags: review+
Comment 7•22 years ago
|
||
Comment on attachment 115998 [details] [diff] [review]
Move the test for pathlength
sr=darin
Attachment #115998 -
Flags: superreview?(darin) → superreview+
Assignee | ||
Comment 8•22 years ago
|
||
thx timeless
Status: NEW → RESOLVED
Closed: 22 years ago
Resolution: --- → FIXED
Updated•22 years ago
|
Flags: blocking1.4a?
You need to log in
before you can comment on or make changes to this bug.
Description
•