User-Agent: Mozilla/5.0 (Macintosh; U; PPC Mac OS X Mach-O; en-US; rv:1.3) Gecko/20030312 Build Identifier: Mozilla/5.0 (Macintosh; U; PPC Mac OS X Mach-O; en-US; rv:1.3) Gecko/20030312 When I edit pages at my personal Website (hosted by Hostway), I can edit and publish (upload) pages twice or three times without any problems, but on the third or fourth try and every try thereafter the upload process stalls after I click "Publish"; that is, the "Publishing Status" section in the "Publishing: (page title)" window continues to show "Publishing..." indefinitely. This happened with an earlier version of Mozilla (1.2.1?), and I was able to fix it by reverting to an earlier settings folder, making me think that the problem was a corrupted settings file. This time, I have tried two different backed-up settings from before updating to 1.3, but the problem persists. Reproducible: Always Steps to Reproduce: 1. Open a Web page in the browser at a site to which I have ftp access. 2. Edit the page. 3. Click "Publish." Actual Results: The first two or three times, the page uploaded properly within a few seconds. The third or fourth time thereafter, the "Publishing: ..." window continued to display "Publishing..." indefinitely. Quitting and restarting Mozilla allowed me to upload pages two or three times again, then the problem occurred again. Expected Results: It should have allowed me to upload as many files as I want without restarting Mozilla.
Tom, can you reproduce this problem using another Mozilla user profile?
Additional tests by me (the original reporter) using a different user profile and uploading to the same site yielded the same result: each time, FTP publish failed after the third try. Using my original profile but uploading to a different site, I was able to publish for more than three times, but after about a dozen times (I wasn't counting) the publish function began to fail and a "530 Sorry, the maximum number clients (12) from your host are already connected" message appeared. Could this mean that Mozilla is connecting as a different client each time I publish? Perhaps the first site had a maximum of three clients and the second site twelve.
I'm seeing a problem where I can't publish the same document after the first ftp publishing has occured. The error I get the following: The process cannot access the file because it is being used by another. Here is the server I'm publishing to: 220 geckoqa Microsoft FTP Service (Version 5.0). Remote system type is Windows_NT
The problem I described is happening on both Mach-o OS X (2003-03-13-03) and Win32 (2003-03-13-04) trunk builds.
Editor triage team: nsbeta1+/adt2
First, it looks like a duplicate of bug #138658 Second, I see the same thing here (Mozilla 1.3 Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.3) Gecko/20030312 Publishing to my own web server fails at the 15th attempt in a short time. Looking at netstat output from a windows command line, it looks like composer is not closing the ftp connection. At 15 active connections, my server refuses more. It is 100% reproductible here. FTP server is proftpd on freebsd. Log is: Mar 26 18:31:25 bull proftpd: localhost (192.168.0.130[192.168.0.130]) - USER fred: Login successful. Mar 26 18:31:28 bull proftpd: localhost (192.168.0.130[192.168.0.130]) - USER fred: Login successful. Mar 26 18:31:31 bull proftpd: localhost - MaxInstances (15) reached, new co nnection denied. My workaround is to exit mozilla, then wait for connections to timeout and reconnect.
Using the 2003-05-07-03 Macho build, I haven't been able to reproduce the problem I mentioned in comment #3. I have been publishing (using ftp) the same document each time I modify it. I published this document 5 -10 times and never got a error. Perhaps this has been resolved ? Reporter, I would try with the latest Macho trunk build to see if you can still reproduce.
I was able to reproduce this bug exactly with Mozilla 1.3.1 for Mac OS X, but the bug did not appear with 1.4b for Mac OS X (Build ID: 2003050714) when tested under the same conditions. So it looks like it has been fixed in 1.4b. Many thanks to whoever made the fix.