134182 - Fix Publishing UI problems tracking bug

Status: VERIFIED INVALID

(SeaMonkey :: Composer, defect)

Description

[Charles Manske]

I will put one patch here to fix a variety of problems to make it easier to 
attach one fix for all.

Comment 1

[Charles Manske]

Attachment: Patch v1

Comment 2

[Kathleen :Brade]

Comment on attachment 76740 [details] [diff] [review]
Patch v1

I don't think we should do this:
@@ -1610,10 +1630,14 @@
     if (!url)
       continue;

+    // Never show username and password in menu!
+    url = StripUsernamePassword(url);
+

If the url doesn't have the login, it may not be valid/loadable.  We should
only strip the password.

Please split this patch up so it's easier to see which fixes go with which
bugs.  Thanks! :-)

Comment 3

[Kathleen :Brade]

There are several different issues which we should enumerate for QA to verify. 
Charley will have to decide which get fixed in this bug and which are covered in
other bugs.

Here are some issues which should be noted:
  * Publish Progress dialog on Mac has no title bar (find dialog in Composer
doesn't either; find dialog in Navigator is fine)
  * use of ioService.newURI instead of createInstance
  * removing hard-coded constant for localization effort
  * problem of saving related files when pref isn't set (bug #?)
  * need to set login (but not pw) as part of document uri
  * having login as part of document uri in recent pages (esp if ftp)
  * setting the appropriate uri of the document (ftp vs http)
  * CheckAndSave dialog work (bug #?)
  * fixing url part extract problems
  * need to add publishing error strings
  * publish progress disappearing too quickly

Comment 4

[Charles Manske]

I agree with all issues noted by brade except:
 * need to set login (but not pw) as part of document uri

I still think we should not do this. It doesn't make any difference to capability
of page to load. The "url part extract problems" was the root of that problem
(see bug 133823). Including username in a doc url will greatly increase risk
of not recognizing it in publish database and cause duplicate site entries, etc.

Comment 5

[sujay]

another issue which is related to "publish progress disappearing too quickly"
is that user cannot check the "Keep this window open after publish" because
it disappears to fast.

Comment 6

[sujay]

If QA does not receive reproducible steps to verify the several issues
in this bug, then development will have to assist in verifying them.
The UI ones should be easy to figure out, but there are some that needs
steps.

Comment 7

[Charles Manske]

Individual patches will be supplied on each bug. I'm killing this one so we don't
put any more discussion here. I'll copy brade's excellent list to appropriate 
bugs.

Comment 8

[sujay]

verified.

Comment 9

[sujay]

this but got closed out...Charley, did someone file a bug for each
of Kathy's issues? see her list in this bug report...

Comment 10

[Charles Manske]

yes