Closed Bug 275960 Opened 21 years ago Closed 20 years ago

document.lastModified cannot handle non-ascii characters when the page's HTTP header doesn't have Last-Modified

Categories

(Core :: Internationalization, defect, P1)

defect

Tracking

()

RESOLVED FIXED
mozilla1.8beta4

People

(Reporter: melop_cui, Assigned: masayuki)

Details

(Keywords: intl, regression)

Attachments

(6 files, 3 obsolete files)

USER-AGENT:Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.8a6) Gecko/20041224 Firefox/1.0+ The document.lastModified property is expected to return an localized string for the date. But on my system (Windows XP Pro. Simplified Chinese), the result return by it is unreadable. Reproductivity: Always Step to reproduce: 1.Download the testcase 2.Open it on a non-English windows version.
Attached image Expected result
So... last-modified over HTTP is ascii. Where is the non-ascii coming from in this case? Note that nsDocument::GetLastModified uses CopyASCIItoUCS2, so it's certainly assuming it has an ASCII string. Can PR_FormatTime() give us non-ascii data?
Garbage Characters not always shown. It seems that we will get garbase characters with only page who don't return Last-Modified HTTP header. # It seems that without the header, Firefox will generate garbage. This wasn't happen with aviary builds. For example, with firefox start page, we get garbase with javascript: alert( document.lastModified ); HTTP Header is like this (captured with httpheaders): ---------------------------------------------------------- http://www.google.co.jp/firefox GET /firefox HTTP/1.1 Host: www.google.co.jp User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; ja; rv:1.8b3) Gecko/20050710 Firefox/1.0+ Accept: text/xml,application/xml,application/xhtml+xml,text/html;q=0.9,text/plain;q=0.8,image/png,*/*;q=0.5 Accept-Language: ja,en-us;q=0.7,en;q=0.3 Accept-Encoding: gzip,deflate Accept-Charset: Shift_JIS,utf-8;q=0.7,*;q=0.7 Keep-Alive: 300 Connection: keep-alive Cookie: PREF=ID=87cfcb29483aa85f:LD=ja:TM=1116700911:LM=1116722731:S=wEm9xsFaOCSyIAOF HTTP/1.x 200 OK Cache-Control: private Content-Type: text/html Content-Encoding: gzip Server: GWS/2.1 Content-Length: 1765 Date: Wed, 20 Jul 2005 03:14:12 GMT ----------------------------------------------------------
open the page: http://www.google.co.jp/firefox exec javascript from location bar: javascript: alert( document.lastModified ); and this dialog will be shown.
Same with Aviary Firefox (dialog have correct characters).
Attached patch Patch rv1.0 (obsolete) — Splinter Review
Assignee: general → masayuki
Status: UNCONFIRMED → ASSIGNED
Attachment #189908 - Flags: superreview?(bzbarsky)
Attachment #189908 - Flags: review?(bzbarsky)
This may be regression of bug 116598. We should fix before 1.8b4.
Component: DOM → Internationalization
Flags: blocking1.8b4?
Keywords: intl, regression
Priority: -- → P1
Summary: document.lastModified cannot handle non-ascii characters → document.lastModified cannot handle non-ascii characters when the page's HTTP header doesn't have Last-Modified
Target Milestone: --- → mozilla1.8beta4
Comment on attachment 189908 [details] [diff] [review] Patch rv1.0 This doesn't seem like the right fix, since in general there is no reason this string would be in the native encoding... For cases when we format it from the current date that would be the case, but that's not always happening. Ideally, we would store this string as UTF8, always.
Attachment #189908 - Flags: superreview?(bzbarsky)
Attachment #189908 - Flags: superreview-
Attachment #189908 - Flags: review?(bzbarsky)
Attachment #189908 - Flags: review-
(In reply to comment #10) > Ideally, we would store this string as UTF8, always. Either that or UTF-16. A better fix would be to use a method of nsIDateTimeFormat (http://lxr.mozilla.org/seamonkey/source/intl/locale/public/nsIDateTimeFormat.h ) in nsDocument::RetrieveRelevantHeaders unless using '%c' is absolutely required, which I don't think is the case.
OS: Windows XP → All
Hardware: PC → All
Attached patch Patch rv2.0 (obsolete) — Splinter Review
Attachment #189908 - Attachment is obsolete: true
Attachment #189935 - Flags: review?(jshin1987)
Flags: blocking1.8b4? → blocking1.8b4+
Attachment #189935 - Flags: review?(jshin1987) → review-
Attached patch Patch rv2.1 (obsolete) — Splinter Review
Attachment #189935 - Attachment is obsolete: true
Attachment #190002 - Flags: review?(jshin1987)
Comment on attachment 190002 [details] [diff] [review] Patch rv2.1 >+ CopyASCIItoUCS2(tmp, mLastModified); nit: CopyASCIItoUTF16 > > modDate = PR_Now(); > } > > if (LL_NE(modDate, LL_ZERO)) { >- PRExplodedTime prtime; >- char buf[100]; >- >- PR_ExplodeTime(modDate, PR_LocalTimeParameters, &prtime); I think you'd better keep this so that |mLastModified| is represented in the local time zone.
Attachment #190002 - Flags: review?(jshin1987)
Attachment #190002 - Attachment is obsolete: true
Attachment #190024 - Flags: review?(jshin1987)
Attachment #190024 - Flags: review?(jshin1987) → review+
Attachment #190024 - Flags: superreview?(bzbarsky)
Attachment #190024 - Flags: superreview?(bzbarsky) → superreview+
Comment on attachment 190024 [details] [diff] [review] Patch rv3.0 The risk is low. But this is important for intl.
Attachment #190024 - Flags: approval1.8b4?
Attachment #190024 - Flags: approval1.8b4? → approval1.8b4+
checked-in.
Status: ASSIGNED → RESOLVED
Closed: 20 years ago
Resolution: --- → FIXED
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Creator:
Created:
Updated:
Size: