I have an FTP server that I have multiple username / passwords for, and if I use the publish icon on the toolbar, the page gets published to the first account on the list regardless of whether or not the page was just publish ed to another account previously. Steps to Reproduce: 1. Launch Composer 2. Make sure you have multiple username / passwords setup in the publish site settings for the same ftp server. For example, I have 'user1' and 'user2' at ftp://poochie.office.aol.com. And in the 'publish as' box, 'user1' is first and 'user2' is below it. ('user2' is the default by the way) 3. Create a page, and publish it to the username that is not first in the list. In my case it is 'user2'. 4. Make some changes to the page, and click the publish icon on the toolbar 5. Use the browser to navigate to the page where the page should be (the webspace of the 'user2' user) Actual Results: Only the first page is there, the changes made in step 3 are not there. Now navigate to the other users ('user1' in my case) page, and the page with the changes are there. Expected Results: I would expect that I had published the page as 'user2', that the changes would be published there also. This could cause data loss as any files located in the 'user1' user's space could be overwritten. Note: This problem happens even if 'user2' is the default. I am assuming this is because Composer uses the 'Format - Page Titles and Properties' information when publishing, and once it has the site location, it just checks the publish site settings, and publishes to the first site it finds.

This would be solved by saving the nsIURI object for each document we edit. Then we could include the username as part of the "find publishing data" logic. There are other advantages to doing that as well, such as better file location information on Macs. I've talked to Brade about this problem. Yes, we only look at the document URL (what you see in 'Format - Page Titles and Properties'). After we publish, we currently don't retain the username.

Sorry, can't do anything about this for 1.0

We are now forced to address this issue in order to get FTP publishing to work at all, so this is now being fixed as part of changes for bug 133823. *** This bug has been marked as a duplicate of 133823 ***

verified.