Closed Bug 514751 Opened 10 years ago Closed 10 years ago

malformed URI exception during session restore

Categories

(Firefox :: Session Restore, defect, P1, critical)

defect

Tracking

()

RESOLVED FIXED
Firefox 3.7a1
Tracking Status
status1.9.2 --- beta1-fixed

People

(Reporter: vlad, Assigned: zpao)

References

Details

(Keywords: dataloss, testcase)

Attachments

(3 files)

Saw this in the error console when restoring a bunch of tabs:

Error: uncaught exception: [Exception... "Component returned failure code: 0x804b000a (NS_ERROR_MALFORMED_URI) [nsIIOService.newURI]"  nsresult: "0x804b000a (NS_ERROR_MALFORMED_URI)"  location: "JS frame ::
file:///C:/Program%20Files%20(x86)/Namoroka/components/nsSessionStore.js ::
          sss_deserializeHistoryEntry :: line 2130"  data: no]

Unfortunately, I didn't think to save my session store file :/
note: vlad also said he lost his session, which makes this serious indeed.

this particular exception, if related to the session loss, should be easy enough to wallpaper, so that the rest of the session isn't lost when this happens.

brendan said he'd seen similar behavior, and only in the last few days. adding qawanted to get better STR and a regression range.

marking blocking for investigation, due to dataloss.
Flags: blocking-firefox3.6+
Keywords: dataloss, qawanted
OS: Windows NT → Windows 7
Likely related: bug 509315 (SeaMonkey); bug 514370 (about:sessionrestore).
Brendan's seeing this on a mac, changing OS to All.
OS: Windows 7 → All
Hardware: x86 → All
Priority: -- → P1
For some reason we're getting an extra history entry that's completely empty {}. The we try to add that to history by accessing it's .url, which doesn't work.

So this is the quick wallpaper. I'll look into why this is happening in the first place.
Assignee: nobody → paul
Attachment #399321 - Flags: review?
Attachment #399321 - Flags: review? → review?(dietrich)
Attached file Reduced Test Case
This is a reduced guilty sessionstore.js
Attachment #399321 - Flags: review?(dietrich) → review+
Comment on attachment 399321 [details] [diff] [review]
Wallpaper Patch v0.1

r=me for wallpaper to land asap. please followup w/ unit test.
Pushed http://hg.mozilla.org/mozilla-central/rev/1ad1932defe6

Will followup with a test & continue to look into why we're getting into this state in the first place.
Blocks: 509315
Comment on attachment 399530 [details] [diff] [review]
Wallpaper Patch Test v0.1

looks ok from here. r=me given you've confirmed it fails w/out the wallpaper patch.
Attachment #399530 - Flags: review?(dietrich) → review+
Pushed the test in http://hg.mozilla.org/mozilla-central/rev/59f211597f4a.

So do we push these (as a single patch) to branch too or do we try to figure out the actual problem first? And how does that work with resolving the bug? Is this now fixed and we figure out the actual problem in a followup bug?

Sorry, I'm not sure how the whole wallpaper thing fits into our workflow.
Is this related to bug 467248 or bug 494917 ?
Pushed http://hg.mozilla.org/releases/mozilla-1.9.2/rev/ad284b242e98 and filed
bug 516073 to followup with the proper fix when we find it.
Status: NEW → RESOLVED
Closed: 10 years ago
Resolution: --- → FIXED
Do we still need a regression window? And is 1.9.1 affected too?
Severity: normal → critical
Flags: in-testsuite?
Keywords: testcase
Target Milestone: --- → Firefox 3.7a1
(In reply to comment #13)
> Do we still need a regression window? And is 1.9.1 affected too?

A little late here, but a regression window would be great. I feel like it's going to be hard to find though. That probably better belongs in bug 516073 though since that's the actual problem.

1.9.1 would be affected if the browser ever saved the empty history entry, but I haven't seen any reports of this.
Flags: in-testsuite? → in-testsuite+
Making the executive decision that finding a regression window here after almost 6 years is pretty unlikely to happen.
You need to log in before you can comment on or make changes to this bug.