Closed Bug 973559 Opened 6 years ago Closed 6 years ago

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

Categories

(Firefox :: Session Restore, defect)

x86_64
macOS
defect
Not set

Tracking

()

RESOLVED FIXED
Firefox 30

People

(Reporter: jruderman, Assigned: ttaubert)

References

(Blocks 2 open bugs)

Details

(Keywords: testcase, Whiteboard: [qa-])

Attachments

(2 files)

Attached file 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]
************************************************************
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.
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.
Ok, I don't know exactly why this fixes the failure but having a nsIURI object in the serialized output was wrong anyway.
Assignee: nobody → ttaubert
Status: NEW → ASSIGNED
Attachment #8377096 - Flags: review?(wmccloskey)
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.
Attachment #8377096 - Flags: review?(wmccloskey) → review+
(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.
https://hg.mozilla.org/mozilla-central/rev/365329ab2aa7
Status: ASSIGNED → RESOLVED
Closed: 6 years ago
Resolution: --- → FIXED
Whiteboard: [fixed-in-fx-team]
Target Milestone: --- → Firefox 30
Whiteboard: [qa-]
You need to log in before you can comment on or make changes to this bug.