Closed Bug 93475 Opened 24 years ago Closed 24 years ago

Dead Editor window exists if attempted URL load fails (e.g., file doesn't exist)

Categories

(SeaMonkey :: Composer, defect, P3)

Product:
SeaMonkey
Component:
Composer
Platform:
x86
Windows 2000
Type:
defect

Tracking

(Not tracked)

Status:
VERIFIED FIXED
Milestone:
mozilla0.9.5

People

(Reporter: skasinathan, Assigned: cmanske)

References

Details

(Whiteboard: EDITORBASE)

Attachments

(1 file, 1 obsolete file)

Updated patch: Don't delete item from prefs if URL is not found
2.95 KB, patch
akkzilla
: review+
kinmoz
: superreview+
Details | Diff | Splinter Review
1. Compose a page and save. Close composer. 2. Rename the file. (using Windows explorer in my case) 3. Open composer and select File | Recent Pages | and the page you created in step 1. Notice that nothing happens, though I would expect some kinda dialog saying "The file is not found". 4. Click on Open button and try to open the renamed file or any other file. The composer cannot open any files. Build: 7-27 branch build on Win 2k.
of course it will be in the list, but if we cannot find it, we should display an error dialog stating it cannot be found.
Assignee: beppe → cmanske
Priority: -- → P3
Target Milestone: --- → mozilla1.0
Since the file is renamed outside of our app, I vote that we simply remove any file we fail to load from the "Recent files" list. We should put up a message dialog telling the user that we didn't find the file with something like: "filename.html was found in its previous location. Maybe the file was named or moved. Use Open File to find it again." Robin: Any suggestions for the wording of the message?
Status: NEW → ASSIGNED
Target Milestone: mozilla1.0 → mozilla0.9.5
How about: "The file filename.html could not be found at this location. Perhaps the file was moved, renamed, or deleted. To open the file at its new location, click Open on Composer's toolbar."
Thanks, much better. Perhaps use "To open the file at its new location, use the Open command on the toolbar or in the File menu." ?
How about "...To open the file at its new location, click Open on Composer's toolbar, or choose Open from the File menu."
What if the file is a remote page? I think it would be better to point people to File | Open Web Location rather than the toolbar and File | Open.
My $0.02. Assuming that the file is _deleted_, the phrase "To open the file at its new location" doesn't make sense to me. I think we should have some thing generic to rename, move, delete operations.
Good point! I forgot we saved those as well. Given that we are finally doing publishing, "Open Location" is the better (and simpler) choice.
*** Bug 85198 has been marked as a duplicate of this bug. ***
After attempting to open a previous document that no longer exists (one that has been deleted or renamed) by choosing it from the File | Recent Pages and having nothing happen, besides not only not being able to open anything else after that, a few other things happen: (1) Not only is it that this Composer instance loses its ability to open a document using [Open], for instance, even though the Open HTML files appears to be functional, the Composer loses its ability to have any information typed into its editing area. The cursor disappears and cannot be recovered or to be made to reappear in the editing area. (2) All four of the tabs across the bottom of the editing area (_i.e.,_ Normal, Show All Tags, <HTML> Source, and Preview) all become rendered useless. They are all clickable, but are non-functional now and all remain white. The only solution is to open a new, separate Composer window, and work from there. A new, second Composer window is unaffected by the damaged incidence.
Keywords: nsbeta1
spam composer change
Component: Editor: Core → Editor: Composer
Summary: Cannot open files after selecting "Recent Pages" → Cannot open files after selecting a file from "Recent Pages" that doesn't exist
Whiteboard: EDITORBASE (1 day)
As of 0.9.4 nightly build of September 25, 2001, there is now a pop-up window that says the file in the "recent pages" list cannot be found. After that window is dismissed, there is still no way to open the renamed file or any other file. The cursor still disappears. There is still no way to type in the text editor. Here's a variant. Create a file in composer and save it. Close composer. Rename the file. Re-open composer. Start creating a different new file in the composer window. Try to open the earlier file from the "recent pages" list. It will open a second composer window and a pop-up window saying it can't find the file (it was renamed). The second window's cursor has disappeared. No text can be typed in. No files can be opened from the second window either. Okay, close the second composer window. In the first composer window you can still type in the editing window. You can also open a file, including the renamed file, from that first composer window. Sorry if this isn't much of a variant.
Changed summary to reflect the more general problem.
Summary: Cannot open files after selecting a file from "Recent Pages" that doesn't exist → Dead Editor window exists if attempted URL load fails (e.g., file doesn't exist)
brade: I know you are also working in nsEditorShell::EndPageLoad(), but this seems like a good fix so I'd like you to evaluated its compatability with your work. Hopefully, we can check this in, then let you expand it to not close the file and other publishing-related enhancements.
Keywords: nsbeta1 → patch, review
Whiteboard: EDITORBASE (1 day) → EDITORBASE (1 day) FIX IN HAND need r=, sr=
Are you sure we should remove the recently edited menu item? I've run into "file not found" several times because 1) server wasn't up or 2) I wasn't on the appropriate network so it was accessible. I could also see 3) drive/volume was not mounted (if user has multiple drives or removable media). I'm not sure what the correct behavior should be here.
Yes, I think we should remove not-found items from the menu. 1. There's no other way to remove them, so this is the best way to prevent old files (subsequently moved or deleted) from cluttering up the menu. The menu is just a convenience and I think it's better to err on cleaning it up rather than keeping truely bad entries around. 2. It's not very hard to find the file again to return it to the menu.
see bug #102538 I disagree about the cluttering up of the menu point. The menu isn't so big that it would be cluttered. If the user opens enough documents, old documents get pushed off the list. Personally, I would find it hard to open these urls since I don't remember what they are because I just access them with the recent pages menu. :-/
Attachment #51382 - Attachment is obsolete: true
This fix just closes the window when URL isn't found. Bug 102538 now covers issue of asking user if they want to delete the item from prefs or other actions.
Comment on attachment 51538 [details] [diff] [review] Updated patch: Don't delete item from prefs if URL is not found Looks fine, seems to work. It would be nice if we could keep the editor window up (change to about:blank) so the user could then look for another file. Charley and I are talking about that, but it's a separate issue.
Attachment #51538 - Flags: review+
Whiteboard: EDITORBASE (1 day) FIX IN HAND need r=, sr= → EDITORBASE (1 day) FIX IN HAND need sr=
Comment on attachment 51538 [details] [diff] [review] Updated patch: Don't delete item from prefs if URL is not found sr=kin@netscape.com Just fix the typo ("simply") in the following comment: + //TODO: Would it be possible to simple change channel URL Also if you want to be consistent, perhaps you should add a fall through case for eCantEditFileNotFound in that error switch statement.
Attachment #51538 - Flags: superreview+
Status: ASSIGNED → RESOLVED
Closed: 24 years ago
Resolution: --- → FIXED
Whiteboard: EDITORBASE (1 day) FIX IN HAND need sr= → EDITORBASE
checked in.
Verified on 10-03 Trunk build
Status: RESOLVED → VERIFIED
Product: Browser → Seamonkey
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Creator:
Created:
Updated:
Size: