973559 - content-sessionStore.js:629 - nsIURI.userPass - NS_ERROR_FAILURE

Status: RESOLVED FIXED

(Firefox :: Session Restore, defect)

Description

[Jesse Ruderman]

Attachment: testcase

************************************************************
* Call to xpconnect wrapped JSObject produced this error:  *
[Exception... "Component returned failure code: 0x80004005 (NS_ERROR_FAILURE) [nsIURI.userPass]"  nsresult: "0x80004005 (NS_ERROR_FAILURE)"  location: "JS frame :: chrome://browser/content/content-sessionStore.js :: MessageQueue.send :: line 629"  data: no]
************************************************************

Comment 1

[Tim Taubert [:ttaubert] (inactive)]

Hmm. Where is that failure coming from? We have no code in content-sessionStore.js that modifies URIs. All I can think of is the code in browser.js that updates the current URI for the crash reporter.

Comment 2

[Tim Taubert [:ttaubert] (inactive)]

This seems to be caused by shistory. Collecting itself doesn't fail but passing it to sendRcpMessage() or sendAsyncMessage() throws an error. The same error is thrown when trying to JSON.stringify() the collected data.

Comment 3

[Tim Taubert [:ttaubert] (inactive)]

Attachment: 0001-Bug-973559-Fix-baseURI-serialization-for-srcdoc-fram.patch

Ok, I don't know exactly why this fixes the failure but having a nsIURI object in the serialized output was wrong anyway.

Comment 4

[Bill McCloskey [inactive unless it's an emergency] (:billm)]

Comment on attachment 8377096 [details] [diff] [review]
0001-Bug-973559-Fix-baseURI-serialization-for-srcdoc-fram.patch

Review of attachment 8377096 [details] [diff] [review]:
-----------------------------------------------------------------

I can see why this is a problem. sendAsyncMessage won't be able to send an nsIURI over an IPC channel. But I wonder how this ever worked before. I wouldn't have thought that JSON.stringify would be able to handle it either.

Don't we also have to change the corresponding code in deserializeEntry? It seems like we need to call makeURI there or else the assignment to shEntry.baseURI will fail.

Comment 5

[Tim Taubert [:ttaubert] (inactive)]

(In reply to Bill McCloskey (:billm) from comment #4)
> Don't we also have to change the corresponding code in deserializeEntry? It
> seems like we need to call makeURI there or else the assignment to
> shEntry.baseURI will fail.

Good point, I didn't even look at deserializeEntry because I assumed we're doing the right thing there... Thanks for catching that.

Comment 6

[Tim Taubert [:ttaubert] (inactive)]

https://hg.mozilla.org/integration/fx-team/rev/365329ab2aa7

Comment 7

[Wes Kocher (:KWierso) (Not reading bugmail; email directly if needed)]

https://hg.mozilla.org/mozilla-central/rev/365329ab2aa7