Closed Bug 36681 Opened 26 years ago Closed 16 years ago

document.lastModified date is incorrect for a local file just saved

Categories

(SeaMonkey :: Composer, defect)

Product:
SeaMonkey
Component:
Composer
Platform:
x86
Windows NT
Type:
defect
Priority:
Not set
Severity:
normal

Tracking

(Not tracked)

Status:
RESOLVED EXPIRED

People

(Reporter: Burnsjo, Unassigned)

References

Details

(Keywords: helpwanted, Whiteboard: [nsbeta3-][p:3])

Attachments

(1 file)

TestCase Showing lastModifed - excute it locally - returns time of load - SAVE LOCALLY BEFORE RUNNING
394 bytes, text/html
Details
Bug : The functionality of the "Page Title and Properties" window is not complete. Steps to repro: 1. Launch the Composer component of Netscape 6. 2. Click on "Format" ("Absatz") 3. Click on "Page Title and Properties" ("Seitentitel und Eigenschaften...") 4. Click "More Properties" ("Mehr Eigenschaften") Missing functionality in this part of the window.
confirm and reassign to cmanske; this is the bug for the functionality in the dialog (as opposed to the localization strings). Setting to M16 for now. Charley--do we need this bug fixed for beta2 or can we drop the functionality entirely?
Assignee: laurasl → cmanske
Status: UNCONFIRMED → NEW
Ever confirmed: true
Summary: Composer: DE: Incomplete functionality in the "Page Title and Properties" window. → Incomplete functionality in the "Page Title and Properties" window.
Target Milestone: --- → M16
Yes, this will be finished for beta2
Status: NEW → ASSIGNED
*** Bug 36680 has been marked as a duplicate of this bug. ***
The design for the "advanced" part of the dialog is to let user enter "raw" HTML source for elements and attributes in the <head> region, similar to the Insert HTML Source dialog. To do that, we need to get the contents of the <head> as a HTML-formated string. nsIDocumentEncoder::EncodeToString needs to be enhanced to include contents in the <head> if they are selected. This is the text that will be placed in the multiline textfield for user editing.
Depends on: 37029
Dialg is mostly done. Only need to get file date. Changing summary for that task.
Summary: Incomplete functionality in the "Page Title and Properties" window. → Get file date for URL in the "Page Title and Properties" dialog.
Checked in 4/28
Status: ASSIGNED → RESOLVED
Closed: 26 years ago
Resolution: --- → FIXED
sure it gives a date....the wrong date though....Jan 1st, 1970 ???? are we grabbing the right date?
Status: RESOLVED → REOPENED
Resolution: FIXED → ---
Hmmm. I thought this looked ok when I first implemented it, but it doesn't look good now! I'm simply getting the document.lastModified via JavaScript. Brendan: Any idea what the problem is?
Status: REOPENED → ASSIGNED
Target Milestone: M16 → M17
Maybe the DOM level 0 property document.lastModified is busted? Or maybe the server send a bogus timestamp for that document? Oh, what server? It's a local file, you say? I blame something to do with local file last-modified httpheader emulation. Cc'ing likely helpers. /be
I am sure y'all know this already but I thought I would chip in: from the Netscape JS referance: If the server does not return the last modified information, JavaScript receives a 0, which it displays as January 1, 1970 GMT. The following code checks the date returned by lastModified and prints out a value that corresponds to unknown. lastmod = document.lastModified // get string of last modified date lastmoddate = Date.parse(lastmod) // convert modified string to date if(lastmoddate == 0){ // unknown date (or January 1, 1970 GMT) document.writeln("Lastmodified: Unknown") } else { document.writeln("LastModified: " + lastmod) }
Thanks, Daniel, that was useful. The case I tested was a local file, so using your code, we do get a non-zero "lastmoddate", but "lastmode" is wrong. Testing on a remote URL, the date seems to be correct, so this error would seem to be in the nsIFile system, as Brendan suggested. Who should get this bug now?
Status: ASSIGNED → NEW
Keywords: nsbeta2
Changing summary to reflect the real problem.
Summary: Get file date for URL in the "Page Title and Properties" dialog. → document.lastModidied date is incorrect for a local file
Depends on: 38553
Putting on [nsbeta2-] radar. dougt - who will handle NSI file menu whilst your out?
Whiteboard: [nsbeta2-]
nsIFile returns milliseconds from midnight, January 1, 1970 GMT. do you have to preform some type of conversion before passing this date?
fixing spelling in summary
Summary: document.lastModidied date is incorrect for a local file → document.lastModified date is incorrect for a local file
Doug: I assume you have to convert it so the date is in a "current" GMT format. Why was this assigned back to me? This used to work -- before converting to using nsIFile? Brendan -- do you know how it was done before?
Assignee: cmanske → dougt
This patch should fix this problem. Index: html/document/src/nsHTMLDocument.cpp =================================================================== RCS file: /cvsroot/mozilla/layout/html/document/src/nsHTMLDocument.cpp,v retrieving revision 3.234 diff -u -r3.234 nsHTMLDocument.cpp --- nsHTMLDocument.cpp 2000/05/22 22:16:56 3.234 +++ nsHTMLDocument.cpp 2000/05/24 23:56:28 @@ -504,7 +504,7 @@ nsCOMPtr<nsIFileChannel> fileChannel = do_QueryInterface(aChannel); if (fileChannel) { - PRTime modDate; + PRTime modDate, usecs; nsCOMPtr<nsIFile> file; rv = fileChannel->GetFile(getter_AddRefs(file)); @@ -514,7 +514,8 @@ PRExplodedTime prtime; char buf[100]; - PR_ExplodeTime(modDate, PR_LocalTimeParameters, &prtime); + LL_MUL(usecs, modDate, PR_USEC_PER_MSEC); + PR_ExplodeTime(usecs, PR_LocalTimeParameters, &prtime); // Use '%#c' for windows, because '%c' is backward-compatible and // non-y2k with msvc; '%#c' requests that a full year be used in the
oh, this was probably my bustage when I change nsIFile to return milliseconds. It looks good to me. r=dougt.
I checked in the above patch. Marking FIXED.
Status: NEW → RESOLVED
Closed: 26 years ago → 26 years ago
Resolution: --- → FIXED
still not fixed in 5/26 build....reopening..
Status: RESOLVED → REOPENED
Resolution: FIXED → ---
What? It surely works for me, both on linux and windows, at least I do get the correct date in the property dialog in the editor when editing a local file, and that's what this is all about, right? I did screw up when I checked in the patch, it didn't compile on the mac, so brade helped me out and fixed it just in time to get the verification builds successfully done yesterday morning, and in that stressful process a typo slipped in and it was broken yet again, but later yesterday when the tree opened I checked in a fix for the typo, and things work. Please retest with a build from today, and if it doesn't work, then I have no clue as to what's wrong here.
I'm using today's commercial windows build... 1) open new blank doc 2) add text 3) save 4) Format | Page Title and Props I see a date stamp of "January 1, 1970 GMT" what am I doing wrong??? lets wrap this up before long weekend.. please call me at x3014...I tried looking you up in the NSCP database couldn't find you... thanks.
Aha! If you load an existing file and check in the dialog, you get the correct time, but if you create a new file from scratch, it never sets the lastModified property! That's the difference. Reassigning to cmanske, I don't know if that's correct, but this is something for the editor people IMO, SetLastModified() needs to be called on the nsIHTMLDocument when the document is saved. document. (PS. I still work from home (in finland) so I'm not listed in the Netscape phone book, once I get my visa I'll come over to the US)
Assignee: dougt → cmanske
Status: REOPENED → NEW
Ok! Will do -- very easy.
Status: NEW → ASSIGNED
*** Bug 34727 has been marked as a duplicate of this bug. ***
setting to m18
Keywords: nsbeta2 → correctness, nsbeta3
Whiteboard: [nsbeta2-]
Target Milestone: M17 → M18
adding nsbeta3+
Whiteboard: [nsbeta3+]
After saving a new page to a file, it seems the document should now know the last-modified date, but it doesn't. It was suggested to use SetLastModified(), but I can't set that from withing JS, and I don't know what date string to use -- it seems the file system should do that when it saves a file.
Keywords: helpwanted
Whiteboard: [nsbeta3+] → [nsbeta3+][p:3]
Charley, I thought it was decided in the UI meeting that the modify date was to be dropped for release 1 and we were going to future that -- is that how you remember it?
While that was essentially the decision, that seems "overkill" when it mostly works (like after loading an existing file), and that seems real useful information to me. We no longer display an incorrect date, but rather something like "[unknown]" if we don't know the date, so I'm opposed to removing it altogether.
if it works correctly 100% of the time, then yes it should stay in, if it works incorrectly at any time, then we pull it.
moving this to future and adding helpwanted Need to triage to get on the appropriate glidepath for pr3
Whiteboard: [nsbeta3+][p:3] → [nsbeta3-][p:3]
Target Milestone: M18 → Future
Target Milestone: Future → mozilla0.9
The remaining problem is that when we save a file, the date/time is not updated for the document so document.lastModified is not correct. I looked into how to do this, but with further thought and discussion, it seems this needs to be updated by the file-saving code. I'm sure Doug can reroute to appropriate engineer.
Assignee: cmanske → dougt
Status: ASSIGNED → NEW
Summary: document.lastModified date is incorrect for a local file → document.lastModified date is incorrect for a local file just saved
I am not sure that I understand. Do you want to be able to set the last modification date of a file on disk? Doesn't nsIFile: http://lxr.mozilla.org/seamonkey/source/xpcom/io/nsIFile.idl#185 work?
Assignee: dougt → cmanske
No, the editor code should not have to do that. When a file is saved, the time set by OS should be read by file-saving code and that should be used to update the document's timestamp so editor can use "document.lastModified" in JS and have it return the file creation time. I looked into setting the date from editor, but I don't have required helpers to get date into the proper format to use. Anyway, it seems logic that file code should do this, no?
nsIFile has the ablity to do this. This bug needs to find the owner of the save-as code. Best guess I have is law.
Assignee: cmanske → law
I really don't want this bug. It happens that Composer does not use the "save-as" code that I might own. Anyway, I'm still not sure why the client code is responsible for making sure the nsIFile properly manages its lastModified timestamp. I glanced at the code and it seems to want to refresh that attribute if the mDirty flag is set. There must be more to it. Who shall I reassign to?
law, point me at the code that editor is using to save files.
Seems to be nsEditorShell::SaveDocument->nsEditor::SaveFile->nsDocument::SaveFile.
Bumping off the mozilla0.9 train because Law doesn't have time to fix this.
Target Milestone: mozilla0.9 → ---
cant see any reason this is netscape confidential. fixing
Group: netscapeconfidential?
Resetting component. See my comment about updating the "last modified" attribute needing to be reset when mDirty is set. I think the file code should be relied on to return the accurate information. Alternatively, the *composer* "save as" code should take care of it.
Assignee: law → dougt
Component: Editor: Core → Networking: File
QA Contact: sujay → benc
Does this mean you are going to hack out the feature now?
No...I'm just setting the component to better match where the bug/fix belong (I think).
Bill: I mean, are the composer people going to decide to not expose this info in the next release? They discussed this above.
Target Milestone: --- → Future
It is desirable for Composer to be able to display the last modified date. Currently it is not showing valid data if the file is saved. The file system should provide accurate (up-to-date) information about the file.
Okay... that's a "no" to my question... So, does anyone know if this would happen elsewhere, besides composer?
Presumably, the browser would also have invalid info if the file was changed while being browsed. I'm not sure if the browser can easily access this data though.
Just thought I'd mention that when I ran the following Front-end testhttp://www.mozilla.org/quality/browser/front- end/testcases/composer/composer-dialogs.html I see this problem for "Page Title and Properties|last Modified" section. The date I see is: 1008623477000 I assume this is millisecond from Jan 1, 1970; but I didn't do the math. I saw this problem while runing on OpenVMS (20011205) as well as on a Linux system I have.
Test Case : http://careerlink.cdc.uwm.edu/lastmodjstest.php Server: Apache 1.3.22 (win32) PHP: PHP 4.1.1 Mozilla Version: Mozilla (0.9.7 (2001122106)) OS: Windows2000 Previous comments seem to suggest Platform and OS for this bug should be changed to All All. Also, this is NOT JUST COMPOSER BUG like people are assuming. Bug summary needs to be changed to reflect this or a new bug needs to be assigned. Just stumbled across this issue myself and it seems to me to be an issue in the way Mozilla (browser) evaluates javascript. Before anybody brings this up, yes I know I could create this exact same function with php and !js. As PHP generates a new file everytime you call the page, it seems to be effected in the exact same way as described earlier with newly created files in composer. A newly created file doesn't have / seem to have a correct last modified date. NS4.x returns 6 hours before 01JAN70 (or 1800 31DEC69) Mozilla (0.9.7 (2001122106)) returns 01JAN70 IE6 (6.0.2600) returns correct time. I am guessing that the Microsoft ppl noticed this same issue and maybe did a checksum in IE like <pseudo> if ($file_lastmod<$file_created){return $file_created for lastModified date;} </pseudo> OR even something like <pseudo>if ($file_lastmod<01JAN1985(arbitrary number)){return $file_created for lastModifieddate;)</pseudo> . While this has the *potential* to be wrong, how often are you actually going to stumble across a file that was created once and never modified again since 1985 (or arbitrary number). Common sense dictates we could easily check against a common lower bound. As for the vein of thought about composer and save as, I think this is moving in the wrong direction. Wouldn't it to just be easier to build in the code that evaluates javascript a checksum like above? This would provide a fix not only for dynamic pages (i am guessing ASP/SSI) but newly created pages created by other editors (vi new.html for example).
This should have been a new bug from #7. This bug has too much drift. Two entirely unrelated code changes have already occurred in this bug, and we are still at the state we were in in comment #7. I think this needs to revert back to a composer bug, and depend on fixing this javascript problem (lets reopen bug 34727 for that). If there are specific file problems that dougt needs to fix, create another bug that blocks bug 34727 and assign it to file). If this cannot be working, then composer can have the conversation here about masking or hiding the incorrect date information. I will do this at some point unless someone convinces me the status quo is better.
-> composer part of big "file:" compontent cleanup for nsbeta 1. If dougt needs to fix something, please file a new bug and have it block this one.
Assignee: dougt → syd
Component: Networking: File → Editor: Composer
QA Contact: benc → sujay
removing myself from the cc list
Status: NEW → ASSIGNED
reassign to new placeholder
Assignee: syd → composer
Status: ASSIGNED → NEW
Can we get this reassigned. It is NOT a composer bug and as long as it is marked so, feel it will continue to be backburnered. See Comment #51.
Peter, what you're describing in comment #51 is unrelated to this bug, that problem is coverd by bug 116598. This bug is specifcally about the problem with the date not being updated when saving a file in the editor.
from the mozilla menu File - Open File - GaryTest.html hit the button - see date == date of load hit button again, date says same hit reload button - date changes
Comment on attachment 155315 [details] TestCase Showing lastModifed - excute it locally - returns time of load - SAVE LOCALLY BEFORE RUNNING SAVE LOCALLY BEFORE RUNNING
Attachment #155315 - Attachment description: TestCase Showing lastModifed - excute it locally - returns time of load → TestCase Showing lastModifed - excute it locally - returns time of load - SAVE LOCALLY BEFORE RUNNING
Product: Browser → Seamonkey
Assignee: composer → nobody
Priority: P3 → --
QA Contact: sujay → composer
Target Milestone: Future → ---
This bug report is registered in the SeaMonkey product, but has been without a comment since the inception of the SeaMonkey project. This means that it was logged against the old Mozilla suite and we cannot determine that it's still valid for the current SeaMonkey suite. Because of this, we are setting it to an UNCONFIRMED state. If you can confirm that this report still applies to current SeaMonkey 2.x nightly builds, please set it back to the NEW state along with a comment on how you reproduced it on what Build ID, or if it's an enhancement request, why it's still worth implementing and in what way. If you can confirm that the report doesn't apply to current SeaMonkey 2.x nightly builds, please set it to the appropriate RESOLVED state (WORKSFORME, INVALID, WONTFIX, or similar). If no action happens within the next few months, we move this bug report to an EXPIRED state. Query tag for this change: mass-UNCONFIRM-20090614
Status: NEW → UNCONFIRMED
This bug report is registered in the SeaMonkey product, but has been without a comment since the inception of the SeaMonkey project. This means that it was logged against the old Mozilla suite and we cannot determine that it's still valid for the current SeaMonkey suite. Because of this, we are setting it to an UNCONFIRMED state. If you can confirm that this report still applies to current SeaMonkey 2.x nightly builds, please set it back to the NEW state along with a comment on how you reproduced it on what Build ID, or if it's an enhancement request, why it's still worth implementing and in what way. If you can confirm that the report doesn't apply to current SeaMonkey 2.x nightly builds, please set it to the appropriate RESOLVED state (WORKSFORME, INVALID, WONTFIX, or similar). If no action happens within the next few months, we move this bug report to an EXPIRED state. Query tag for this change: mass-UNCONFIRM-20090614
This bug report is registered in the SeaMonkey product, but has been without a comment since the inception of the SeaMonkey project. This means that it was logged against the old Mozilla suite and we cannot determine that it's still valid for the current SeaMonkey suite. Because of this, we are setting it to an UNCONFIRMED state. If you can confirm that this report still applies to current SeaMonkey 2.x nightly builds, please set it back to the NEW state along with a comment on how you reproduced it on what Build ID, or if it's an enhancement request, why it's still worth implementing and in what way. If you can confirm that the report doesn't apply to current SeaMonkey 2.x nightly builds, please set it to the appropriate RESOLVED state (WORKSFORME, INVALID, WONTFIX, or similar). If no action happens within the next few months, we move this bug report to an EXPIRED state. Query tag for this change: mass-UNCONFIRM-20090614
This bug report is registered in the SeaMonkey product, but has been without a comment since the inception of the SeaMonkey project. This means that it was logged against the old Mozilla suite and we cannot determine that it's still valid for the current SeaMonkey suite. Because of this, we are setting it to an UNCONFIRMED state. If you can confirm that this report still applies to current SeaMonkey 2.x nightly builds, please set it back to the NEW state along with a comment on how you reproduced it on what Build ID, or if it's an enhancement request, why it's still worth implementing and in what way. If you can confirm that the report doesn't apply to current SeaMonkey 2.x nightly builds, please set it to the appropriate RESOLVED state (WORKSFORME, INVALID, WONTFIX, or similar). If no action happens within the next few months, we move this bug report to an EXPIRED state. Query tag for this change: mass-UNCONFIRM-20090614
This bug report is registered in the SeaMonkey product, but has been without a comment since the inception of the SeaMonkey project. This means that it was logged against the old Mozilla suite and we cannot determine that it's still valid for the current SeaMonkey suite. Because of this, we are setting it to an UNCONFIRMED state. If you can confirm that this report still applies to current SeaMonkey 2.x nightly builds, please set it back to the NEW state along with a comment on how you reproduced it on what Build ID, or if it's an enhancement request, why it's still worth implementing and in what way. If you can confirm that the report doesn't apply to current SeaMonkey 2.x nightly builds, please set it to the appropriate RESOLVED state (WORKSFORME, INVALID, WONTFIX, or similar). If no action happens within the next few months, we move this bug report to an EXPIRED state. Query tag for this change: mass-UNCONFIRM-20090614
This bug report is registered in the SeaMonkey product, but has been without a comment since the inception of the SeaMonkey project. This means that it was logged against the old Mozilla suite and we cannot determine that it's still valid for the current SeaMonkey suite. Because of this, we are setting it to an UNCONFIRMED state. If you can confirm that this report still applies to current SeaMonkey 2.x nightly builds, please set it back to the NEW state along with a comment on how you reproduced it on what Build ID, or if it's an enhancement request, why it's still worth implementing and in what way. If you can confirm that the report doesn't apply to current SeaMonkey 2.x nightly builds, please set it to the appropriate RESOLVED state (WORKSFORME, INVALID, WONTFIX, or similar). If no action happens within the next few months, we move this bug report to an EXPIRED state. Query tag for this change: mass-UNCONFIRM-20090614
This bug report is registered in the SeaMonkey product, but has been without a comment since the inception of the SeaMonkey project. This means that it was logged against the old Mozilla suite and we cannot determine that it's still valid for the current SeaMonkey suite. Because of this, we are setting it to an UNCONFIRMED state. If you can confirm that this report still applies to current SeaMonkey 2.x nightly builds, please set it back to the NEW state along with a comment on how you reproduced it on what Build ID, or if it's an enhancement request, why it's still worth implementing and in what way. If you can confirm that the report doesn't apply to current SeaMonkey 2.x nightly builds, please set it to the appropriate RESOLVED state (WORKSFORME, INVALID, WONTFIX, or similar). If no action happens within the next few months, we move this bug report to an EXPIRED state. Query tag for this change: mass-UNCONFIRM-20090614
MASS-CHANGE: This bug report is registered in the SeaMonkey product, but still has no comment since the inception of the SeaMonkey project 5 years ago. Because of this, we're resolving the bug as EXPIRED. If you still can reproduce the bug on SeaMonkey 2 or otherwise think it's still valid, please REOPEN it and if it is a platform or toolkit issue, move it to the according component. Query tag for this change: EXPIRED-20100420
Status: UNCONFIRMED → RESOLVED
Closed: 26 years ago → 16 years ago
Resolution: --- → EXPIRED
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Creator:
Created:
Updated:
Size: