Closed
Bug 249439
Opened 20 years ago
Closed 9 years ago
Roaming cannot use HTTPS when exiting Mozilla
Categories
(Core Graveyard :: Profile: Roaming, defect)
Core Graveyard
Profile: Roaming
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'.
Comment 1•20 years ago
|
||
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
...
Comment 3•18 years ago
|
||
This still doesn't work in SeaMonkey 1.0.5
It crashes in nss3.dll module after the transfer dialog shows up.
Comment 4•18 years ago
|
||
Please add bug #249439 to the dependency list of this bug.
Support of secure transfers is VERY important for roaming.
Updated•18 years ago
|
Blocks: roamingtracking
Blocks: 1243899
Comment 5•9 years ago
|
||
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.
Assignee | ||
Updated•8 years ago
|
Product: Core → Core Graveyard
You need to log in
before you can comment on or make changes to this bug.
Description
•