I will put one patch here to fix a variety of problems to make it easier to attach one fix for all.
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! :-)
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
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.
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.
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.
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.
this but got closed out...Charley, did someone file a bug for each of Kathy's issues? see her list in this bug report...