Closed Bug 249439 Opened 20 years ago Closed 9 years ago

Roaming cannot use HTTPS when exiting Mozilla

Categories

(Core Graveyard :: Profile: Roaming, defect)

defect
Not set
major

Tracking

(Not tracked)

RESOLVED INCOMPLETE

People

(Reporter: InvisibleSmiley, Unassigned)

References

Details

User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.8a2) Gecko/20040701 MultiZilla/1.6.4.0b Build Identifier: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.8a2) Gecko/20040701 MultiZilla/1.6.4.0b After successful use of Roaming via FTP I tried using HTTPS. On startup, it works fine. But when I exit Mozilla, all transfers fail (indicated by red x's in front of the files selected for Roaming). When I click on the Troubleshooting button, I get the following for each file (here with listing.xml): File metadata: "listing.xml" failed with error Error establishing an encrypted connection to <my https server>. Error Code: -8128 Personally, I guess either SSL/the security module is not accessible any more at that point in time or it's something which is not really Mozilla's fault (in which case I'd like to know how to find out about what went wrong). My HTTPS server is using mod_roaming. Reproducible: Always Steps to Reproduce: 1. Setup Roaming over HTTPS 2. Make sure some files have to be transferred 3. Watch the Roaming transfer dialog Actual Results: All transfers fail Expected Results: The files should be transferred or it should be pointed out more clearly what went wrong (in case it's not really Mozilla's fault). I can see this on Linux, Windows and Solaris. Thus marking 'All'.
If it works on startup, it's likely that it's a Mozilla bug. It worked last year, so probably somebody again changed the startup/shutdown sequence, breaking roaming. I have no motivation or time to pinpiont and fix that now.
Severity: normal → major
Status: UNCONFIRMED → NEW
Ever confirmed: true
I also see that with https in the nightly builds (Mozilla/5.0 (Windows; U; Windows NT 5.2; en-US; rv:1.8a3) Gecko/20040816) I also see the red x's with http, but despite the error messages, in that case, the files are transferred. The text in the transfer dialog box: Transfering Status [Exception... "Component returned failure code: 0x80520015 (NS_ERROR_FILE_ACCESS_DENIED) [nsIFile.remove]" nsresult: "0x80520015 (NS_ERROR_FILE_ACCESS_DENIED)" location: "JS frame :: chrome://sroaming/content/transfer/filesList.js :: remove :: line 556" data: no] Troubleshooting button shows this dialog (for http transfer): File metadata: "listing.xml" succeeded, HTTP server said "200: OK" File metadata: "listing.xml" succeeded, HTTP server said "200: OK" Bookmarks: Transfer has been cancelled Personal Addressbook: Transfer has been cancelled Collected Addressbook: Transfer has been cancelled ... Despite the error messages, the files are transferred, as a look in the server logs shows. For https transfer, the Troubleshooting button shows this dialog: File metadata: "listing.xml" failed with Error establishing an encrypted connection to <my-URL>. Error Code: 8128. File metadata: "listing.xml" failed with Error establishing an encrypted connection to <my-URL>. Error Code: 8128. Bookmarks: Transfer has been cancelled Personal Addressbook: Transfer has been cancelled Collected Addressbook: Transfer has been cancelled ...
This still doesn't work in SeaMonkey 1.0.5 It crashes in nss3.dll module after the transfer dialog shows up.
Please add bug #249439 to the dependency list of this bug. Support of secure transfers is VERY important for roaming.
This bug is filed in a bugzilla component related to pre-Firefox code which no longer exists. I believe it is no longer relevant and I am therefore closing it INCOMPLETE. If you believe that this bug is still valid and needs to be fixed, please reopen it and move it to the Toolkit:Startup and Profile System product/component.
No longer blocks: 1243899
Status: NEW → RESOLVED
Closed: 9 years ago
Resolution: --- → INCOMPLETE
Product: Core → Core Graveyard
You need to log in before you can comment on or make changes to this bug.