Closed Bug 62181 Opened 24 years ago Closed 15 years ago

Editor save question doesn't make sense

Categories

(SeaMonkey :: Composer, defect)

Product:
SeaMonkey
Component:
Composer
Type:
defect
Priority:
Not set
Severity:
normal

Tracking

(Not tracked)

Status:
RESOLVED EXPIRED

People

(Reporter: bugzilla, Unassigned)

References

(Depends on 1 open bug)

Details

Build ID: new trunk

Steps to Reproduce:

(1) Open Composer.
(2) Type something.
(3) Press `Browse' on the toolbar (or File > Browse Page)

Result: a message comes up with the text "Save page before viewing in 
navigator?" and OK/Cancel buttons.

This doesn't make much sense.  It seems to suggest that you can view the page 
(why is it called browse?  That seems like bad wording, but that's another bug) 
without saving first, and that saving is just an option.  But it's not -- if 
you press Cancel (which should really be `No'), you can't view the page.
The term 'view' the page was deemed even more confusing, since the user 'views
the source' -- people know what the browser is, consequently 'browse the page
was deemed a better choice.

As for the terminology on the buttons, we use the system dialogs as much as
possible. So, we end up with OK/Cancel.

What text string would you suggest? Knowing that the file MUST BE saved prior to
viewing the document in the browser.
"As for the terminology on the buttons, we use the system dialogs as much as
possible. So, we end up with OK/Cancel."

I think that's just stating the cause of the problem, not justification for the 
problem.  Common dialogs should be more flexible.  But I understand that's not 
editor's area, and a separate bug entirely.

As for better wording/action here, I defer to Matthew...
There is no way to make the dialog understandable, because it shouldn't exist. 
You shouldn't have to save a file before previewing it in Navigator -- that makes 
no sense from the user's point of view.

I suggest that in this situation Composer should create a temporary file, and get 
Navigator to load that.

Mathew, how would you display something that doesn't exist? That is the issue -- 
when a user creates a new document, it is similar to 'vapor' -- it does not exis 
t in the real sense. The document requires a title, and it really requires a 
location (url) for the browser to display it. What url would be used in this 
case? Would you expect a temporary file? But, that has problems -- the user 
would expect to select save after a preview -- so, should we save the temp file? 
Should we save the temp file, or trash the temp file and then save teh data 
under a new document structure?
oh, and I forgot, if the user dropped in images, how would the relative url be 
represented?
If you tried to tell a user that their document `doesn't exist', when they were
*staring right at it* in their Composer window, they'd think you'd gone bananas, 
and they'd be right.

Composer has no problem displaying a document which hasn't been saved yet (and 
neither does Word, or Notepad, or WordPerfect, or Excel ...). Navigator shouldn't 
either. If an URL is required in order for Navigator to display a document in a 
window, that's an unfortunate technical limitation on Navigator's part, but I 
already suggested a way to get around that -- for Composer to save a temporary 
file (in /tmp/, or C:\Windows\Temporary Files\, or wherever) and then to tell 
Navigator to load that file. Yes, the URL would be strange, but the user wouldn't 
care, and probably wouldn't even notice. No, a title would not be required -- 
Navigator quite happily loads Web pages without titles, and local files should be 
no different. Embedded URLs (for images, links, etc) in the temp file would be 
adjusted so that they had exactly the same effect as they would if the user was 
looking at the actual file -- if the document hadn't been saved yet, then 
relative URLs naturally wouldn't work at all.

When the user returned to editing their document in Composer, the document would 
be exactly as it was before the preview. Any further previews would create a new 
temporary file (or overwrite the previous one).

This should go to cmanske@netscape.com. Cc beppe.
Assignee: beppe → cmanske
We can make the text on the dialog buttons anything we want -- they are not
system dialogs. But given what we are doing, Ok and Cancel are correct.
I agree the solution is to save to a temporary file or even better, a memory
stream that can be accessed with a URL, with the Browser *does* need.
I doubt if we will have time for this to be done for mozilla0.9 unless an
external mozilla developer want to do it, so setting milestone to "future".
Status: NEW → ASSIGNED
Target Milestone: --- → Future
At the very least, we should change the wording to suggest that OK and Cancel 
apply to the whole action (e.g. you can't press cancel to view without 
saving)....
Hokay then. As a *temporary* measure, I suggest changing the wording of the 
dialog to:
------
You must save this document before you can preview it in Navigator.

Do you want to save it now?
------

And changing the buttons to `Save ...' and `Cancel'.

We already have a "preview" mode which is distinct, so "browse it in navigator"
would make more sense.

Plus I think "Save & Browse ..." would be a better button title.
Keywords: mozilla0.9
We probably won't have time to do the temporary file saving, which I agree is
the best solution.
The current wording is:
"Save changes to "untitled" before viewing in Navigator?"
The buttons are "Save" and "Cancel".
I think this is ok until we implement the temporary file solution.


spam composer change
Component: Editor: Core → Editor: Composer
Depends on: 95088
removing myself from the cc list
Product: Browser → Seamonkey
Assignee: cmanske → nobody
Status: ASSIGNED → NEW
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
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: 15 years ago
Resolution: --- → EXPIRED
You need to log in before you can comment on or make changes to this bug.