Closed
Bug 148425
Opened 22 years ago
Closed 22 years ago
Improve error status reporting and helping user to fix failures with publishing in Publish Progress dialog
Categories
(SeaMonkey :: Composer, defect)
SeaMonkey
Composer
Tracking
(Not tracked)
VERIFIED
FIXED
mozilla1.0.1
People
(Reporter: robinf, Assigned: cmanske)
References
Details
(Whiteboard: publish[adt2 rtm][fixed in trunk and branch],custrtm-)
Attachments
(2 files, 3 obsolete files)
36.76 KB,
patch
|
Brade
:
review+
hewitt
:
superreview+
chofmann
:
approval+
|
Details | Diff | Splinter Review |
24.20 KB,
image/gif
|
Details |
We'd like to add a button labeled "Troubleshooting" to the Publish Progress
dialog. This button will only appear if one or more of the user's files fail to
publish. The button will point to a new section (not yet written) called
"Troubleshooting" in the Composer section of the help system.
The context ID for the button should be: comp-doc-publish-troubleshooting.
Assignee | ||
Comment 1•22 years ago
|
||
I'm going to expand this bug to cover all the closely-related UI improvements in
the Publish Progress Dialog:
1. Only show the "key" that explains file success/failure:
[checkmark]Succeeded X Failed
when there are failures.
2. Add the "Troubleshooting" button as Robin suggested. A good place for this
is just to the right of the "X Failed" string. It will display only if there is
a failure.
3. Use two status lines above the list of files being transferred. The first
has the bold string "Publishing..." during upload, and then changes to
"Publishing Completed" if publishing succeeds, or "Publishing Failed"
if we aborted publishing. Note that if the only error we get is failure to
find one or more image files, we *don't* fail completely (see bug 137641).
In all other cases, an error results in aborting publishing (i.e., we don't
switch the document URL to the remote URL and we restore original image
URLs. See bug 134883 for fix to restore image URLs.)
Severity: normal → major
Status: NEW → ASSIGNED
Keywords: nsbeta1+
Summary: add Troubleshooting button to Publish Progress dialog when there's a publishing problem → Improve error status reporting and helping user to fix problems in Publish Progress dialog
Whiteboard: publish[adt2]
Target Milestone: --- → mozilla1.0.1
Assignee | ||
Comment 2•22 years ago
|
||
Assignee | ||
Comment 3•22 years ago
|
||
Note that the second status line shows a specific, user-friendly message that
describes the cause of any failure. The need for these strings was already
reported in bug 136432, but we need to do more than simplys add new strings,
thus this bug better covers the complete issue of improving the UI. I'll
dup that bug to this one.
Summary: Improve error status reporting and helping user to fix problems in Publish Progress dialog → Improve error status reporting and helping user to fix failures with publishing in Publish Progress dialog
Assignee | ||
Comment 4•22 years ago
|
||
*** Bug 136432 has been marked as a duplicate of this bug. ***
Assignee | ||
Comment 5•22 years ago
|
||
As noted in bug 136432, we should help the user solve the error as well as
simply giving an error message. Putting all of this in the same string will be
very difficult and wordy, so the above suggestion to have a "Troubleshooting"
section in the help accessible via a new button seems like a much better
solution.
Assignee | ||
Updated•22 years ago
|
Whiteboard: publish[adt2] → publish[adt2 rtm],custrtm-
Assignee | ||
Comment 6•22 years ago
|
||
Assignee | ||
Updated•22 years ago
|
Comment 7•22 years ago
|
||
Comment on attachment 86118 [details] [diff] [review]
patch v1
this patch is pretty close; just a few things for Charley to clean up
(discussed via aim)
Charley is going to have robin give r= to the strings (especially regarding use
of punctuation or lack there of) and then put up a final patch.
Attachment #86118 -
Flags: needs-work+
+SubdirDoesNotExist=The subdirectory "%dir%" doesn't exist at this site or
filename is a subdirectory.
I don't understand the second part of this message "...or filename is a
subdirectory." Suggested text: "The subdirectory "%dir%" doesn't exist at this
site."
+FilenameIsSubdir=Filename %file% is a subdirectory name. Please use a different
filename.
I don't understand how a file name can be the same as a subdirectory name.
Doesn't the file name have to end in with an extension (.html, .jpg, etc.)?
+Offline=You are currently offline. Click on icon in lower-right corner to go
online.
"You are currently offline. Click the icon in the lower-right corner of any
Composer window to go online."
+DiskFull=There is not enough disk space available to write file %file%
"There is not enough disk space available to save the file %file%."
+FileTooBig=File %file% is to big to upload
What is the maximum file size? Is this determined by the server, so can be
different for different servers?
"The file %file% is too large to upload."
+NameTooLong=File or subdirectory name is too long
What is the maximum number of chars for the file or subdirectory name? Is this
determined by the server, so can be different for different servers?
"The file name or subdirectory name is too long."
Assignee | ||
Comment 9•22 years ago
|
||
First, a general question: Should all these messages be sentences and end with
a period?
re: "SubdirDoesNotExist" and "FilenameIsSubdir"
Unfortunately, I found another case in which we get this error code: when subdir
is correctly, but user's filename is same as an existing directory. I can't tell
the difference between those 2 cases. We don't force ".html" extension for
user's filename (they may be saving text and brade doesn't want to do this) and
technically "foo.html" is a legal subdirectory name.
So if we don't say something like " or filename is a subdirectory.", we will be
showing an incorrect message. If user didn't enter a subdir, then we know the
real error and can use the "FilenameIsSubdir" message.
Yes, I agree this is messy and sucks! I wish we got 2 different error codes.
re: "offline" I was trying to keep message as short as possible! Let's use:
"You are currently offline. Click the icon in the lower-right corner of any
window to go online."
(It doesn't have to be a composer window)
re: "FileTooBig". This is a file system error and is probably rare. Each
file system in each OS will have different limits.
re: "NameTooLong" This is also OS-specific and seems to be determined by both
source machine and server. Mac, for example only allows 31 characters and
filenames will get truncated if longer. We really should add some feedback or
limit the length at the time user enters the name, but I didn't want to do that
for this release (I plan to for next one).
How about: "The filename or subdirectory name..."
We use "filename in many places. (again, just trying to be as compact as
possible!
I'll use exactly what you suggest for others.
These are more errors that I don't think we encounter during publishing,
so we don't have error strings yet.
Are there any here that anyone thinks we should include now?
(cc'ing Darin and Doug to get their opinion)
//kIsLocked = 2152857614;
//const kReadOnly = 2152857619;
//const kErrorBindingRedirected = 2152398851;
//const kAlreadyConnected = 2152398859; // in netCore.h
//const kInProgress = 2152398863; // netCore.h
//const kNoContent = 2152398865; // netCore.h
//const kUnknownProtocol = 2152398866 // netCore.h
//const kFtpLogin = 2152398869; // ftpCore.h
//const kFtpCWD = 2152398870; // ftpCore.h
//const kFtpPasv = 2152398871; // ftpCore.h
//const kFtpPwd = 2152398872; // ftpCore.h
//const kDestinationNotDir = 2152857605;
//const kTargetDoesNotExist = 2152857606;
//const kAlreadyExists = 2152857608;
//const kInvalidPath = 2152857609;
//const kDirectoryNotEmpty = 2152857620;
//const kUnrecognizedPath = 2152857601;
//const kUnresolvableSymlink = 2152857602;
//const kUnknownType = 2152857604;
//const kNotDirectory = 2152857612;
Reporter | ||
Comment 10•22 years ago
|
||
>First, a general question: Should all these messages be sentences and end with
>a period?
Yes.
+SubdirDoesNotExist=The subdirectory "%dir%" doesn't exist at this site or
filename is a subdirectory.
Suggested text: "The subdirectory "%dir%" doesn't exist at this
site, or the file %file% uses the same name as the subdirectory."
+FilenameIsSubdir=Filename %file% is a subdirectory name. Please use a different
filename.
Suggested text: "The file %file% uses the same name as the subdirectory. Please
use a different filename."
Your other suggestions are OK.
Assignee | ||
Comment 11•22 years ago
|
||
Robin: But your message "The file %file% uses the same name as the subdirectory"
implies they used the same text for both filename and subdirectory name.
That's probably not the case. The "subdirectory" in this case is *another*
subdirectory under the one they enterred:
E.g.:
Filename = myfile
subdirectory = htmlfiles
and site has a directory:
.../htmlfiles/myfile/
So in this case, the subdirectory "htmlfiles" is correct. The filename "myfile"
causes the error because "myfile" is already a "sub-subdirectory".
Confusing enough? :-\
So maybe use something like:
"The file %file% uses the same name as another subdirectory" ?
This really makes me mad. Until I discovered this other problem, a bad
subdirectory was one of the clearer messages we had :-(
Comment 12•22 years ago
|
||
> Suggested text: "The subdirectory "%dir%" doesn't exist at this
> site, or the file %file% uses the same name as the subdirectory."
I prefer something like:
"The subdirectory "%dir%" doesn't exist at this site, or the file "%file"
already exists as a directory on this site."
Robin--can you fix it more?
Also, Charley--please be consistent about when we use double-quotes and when we
don't.
Reporter | ||
Comment 13•22 years ago
|
||
"The filename "%file%" is already in use by another subdirectory."
and
"The subdirectory "%dir%" doesn't exist at this site, or the filename "%file%"
is already in use by another subdirectory."
Assignee | ||
Comment 14•22 years ago
|
||
Changes from reviewers comments.
Note one change in feedback for failed file upload: Instead of showing
"Some files failed to publish", we now show number of files like this:
"X of Y files failed to publish"
for the case when there are broken images and we still are "completed" as long
as
the html file succeeds.
Attachment #86118 -
Attachment is obsolete: true
Reporter | ||
Comment 15•22 years ago
|
||
Suggested changes to error message text >>indicated like this<< :
+SubdirDoesNotExist=The subdirectory "%dir%" doesn't exist on this site or the
>>filename<< "%file%" is already in use by another subdirectory.
+FileTooBig=The file "%file%" is >>too<< large to publish.
+ServerNotAvailable=>>The server<< is not available. Check your connection and
try again later.
Assignee | ||
Comment 16•22 years ago
|
||
More changes from reviewers. Dropped kIsDirectory and kTooBig since we probably
will never see those errors.
Attachment #86261 -
Attachment is obsolete: true
Comment 17•22 years ago
|
||
Comment on attachment 86285 [details] [diff] [review]
patch v3
r=brade if the following is removed:
-TableCell=Table Cell
+TableCell=Table or Cell
also, I'd like to see the commented out constants ordered numerically but that
shouldn't block this checkin
Attachment #86285 -
Flags: review+
Reporter | ||
Comment 18•22 years ago
|
||
r=robinf on error message text
Comment 19•22 years ago
|
||
Comment on attachment 86285 [details] [diff] [review]
patch v3
sr=hewitt
Attachment #86285 -
Flags: superreview+
Assignee | ||
Comment 20•22 years ago
|
||
checked into trunk
Status: ASSIGNED → RESOLVED
Closed: 22 years ago
Keywords: adt1.0.1,
mozilla1.0.1
Resolution: --- → FIXED
Whiteboard: publish[adt2 rtm][FIX IN HAND][need r=,sr=],custrtm- → publish[adt2 rtm][fixed in trunk],custrtm-
Comment 21•22 years ago
|
||
When do you expect to have these changes ready to be checked into the branch?
l10n really needs all UI changes checked in now. Please advise.
Assignee | ||
Comment 22•22 years ago
|
||
Attachment #85845 -
Attachment is obsolete: true
Comment 23•22 years ago
|
||
This fix is a direct result of usability feedback on publishing. People were
really confused about the feedback and this bug fixes the problems identified.
It's really important to take this for RTM otherwise all the work that we did on
publishing will be usability impaired and confusing for users.
Comment 24•22 years ago
|
||
sujay, can you verify this on the trunk? Please check in the string changes to
after getting drivers approval. Once it's been verified, we'll + the rest of
the bug.
Comment 25•22 years ago
|
||
l10n approved. Please check this into the branch ASAP. thanks
Comment 26•22 years ago
|
||
Comment on attachment 86285 [details] [diff] [review]
patch v3
a=chofmann for 1.0.1. add the fixed1.0.1 keyword and remove mozilla1.0.1+
keyword when your checked in on the branch
Attachment #86285 -
Flags: approval+
Updated•22 years ago
|
Keywords: mozilla1.0.1 → mozilla1.0.1+
Comment 27•22 years ago
|
||
I see the Troubleshooting button. I presume there is a bug filed for
the yet to be implemented help section.
verified in 6/5 trunk build.
Status: RESOLVED → VERIFIED
Reporter | ||
Comment 28•22 years ago
|
||
There's no bug for adding the Troubleshooting content to help, but it will be done
shortly. I'll work with Charley on this.
I'll use the help context ID that Charley has defined in his patch:
openHelp("comp-doc-publish-troubleshooting");
Assignee | ||
Comment 29•22 years ago
|
||
Just the strings (editor.properties and EditorPublishProgress.dtd) checked into
branch.
Comment 30•22 years ago
|
||
adt1.0.1+ added, please add fixed1.0.1 keyword when landing.
Assignee | ||
Comment 31•22 years ago
|
||
checked into mozilla1.0.1 branch
Keywords: mozilla1.0.1+ → fixed1.0.1
Whiteboard: publish[adt2 rtm][fixed in trunk],custrtm- → publish[adt2 rtm][fixed in trunk and branch],custrtm-
Reporter | ||
Comment 32•22 years ago
|
||
Checked in to commercial trunk and branch: the "Troubleshooting" button now
points to a new help section "Solving Common Publishing Problems."
Updated•20 years ago
|
Product: Browser → Seamonkey
You need to log in
before you can comment on or make changes to this bug.
Description
•