Opened 14 months ago

Last modified 5 months ago

#31573 reopened defect

Uncaught exception in SessionStore.jsm with Tor Browser based on ESR 68

Reported by: gk Owned by: pospeselr
Priority: Medium Milestone:
Component: Applications/Tor Browser Version:
Severity: Normal Keywords: ff68-esr, tbb-regression, tbb-9.0.1-can, GeorgKoppen201911, TorBrowserTeam201911R, tbb-9.0-issues
Cc: intrigeri, tbb-team Actual Points: 0.1
Parent ID: Points: 0.1
Reviewer: Sponsor:

Description

During start-up I can see:

JavaScript error: resource:///modules/sessionstore/SessionStore.jsm, line 1325: uncaught exception: 2147746065

Child Tickets

Attachments (1)

its-still-happening-guys.png (56.3 KB) - added by Thorin 5 months ago.
it's still happening guys…

Download all attachments as: .zip

Change History (21)

comment:1 Changed 13 months ago by intrigeri

Cc: intrigeri added

comment:2 Changed 12 months ago by gk

Keywords: tbb-9.0-issues added

9.0 issues.

comment:3 Changed 12 months ago by gk

Keywords: tbb-regression added

comment:4 Changed 12 months ago by gk

Keywords: tbb-9.0.1-can added

comment:5 Changed 12 months ago by pospeselr

Owner: changed from tbb-team to pospeselr
Status: newassigned

comment:6 Changed 12 months ago by pospeselr

So this is happening because the dom.push.enabled pref is false, so PushComponents.jsm throws NS_ERROR_NOT_AVAILABLE when trying to access the PushService singleton. I *think* we can solve this by just swallowing the exception, but I need to look through the code a bit more to be sure.

comment:7 in reply to:  6 Changed 12 months ago by gk

Replying to pospeselr:

So this is happening because the dom.push.enabled pref is false, so PushComponents.jsm throws NS_ERROR_NOT_AVAILABLE when trying to access the PushService singleton. I *think* we can solve this by just swallowing the exception, but I need to look through the code a bit more to be sure.

So, this is actually a Firefox bug given that the pref is set to false in plain esr68? If so, please file an upstream bug as well and get the patch attached there, too, thanks.

comment:8 Changed 12 months ago by gk

Cc: tbb-team added

comment:10 Changed 12 months ago by pospeselr

This issue appears to have been fixed in gecko-dev commit 6a0111db7ba5a1a92f3eb68b89cb415bd08a4f3e in Mozilla Bug 1369436. It's a relatively small change so I'll see if back-porting to ESR68 makes this problem go away.

EDIT:

So after backporting this patch (as well as a follow-up fix 192e75e65bb32ce824c332992135aa7e9d6f246d) this issue is still occurring, and in fact this occurs in stock firefox 70 as well when dom.push.enabled is false.

Last edited 12 months ago by pospeselr (previous) (diff)

comment:11 Changed 12 months ago by gk

Actual Points: 0.1
Keywords: GeorgKoppen201911 TorBrowserTeam201911R added
Points: 0.1
Status: assignedneeds_review

We have a patch that landed and should get backported. bug_31573 (https://gitweb.torproject.org/user/gk/tor-browser.git/commit/?h=bug_31573&id=739c353b91d30238977a20b31b7ecf624c17006b) has a possible fix up for review.

comment:12 Changed 12 months ago by pospeselr

Looks good to me!

comment:13 Changed 12 months ago by gk

Resolution: fixed
Status: needs_reviewclosed

Thanks! Merged to tor-browser-68.2.0esr-9.5-1 (commit 739c353b91d30238977a20b31b7ecf624c17006b).

Changed 5 months ago by Thorin

it's still happening guys...

comment:14 Changed 5 months ago by gk

Resolution: fixed
Status: closedreopened

comment:15 Changed 5 months ago by gk

Keywords: tbb-9.5-issues added; tbb-9.0-issues removed

Hrm, I wonder why that's actually happening again. Maybe the backport we did is not generic enough anymore?

Thorin: do you see that with 9.5a2 as well?

comment:16 Changed 5 months ago by Thorin

Great .. my D:\Portable\ArchiveTBalpha has almost everything but 9.5a2 .. sigh... OK, done - yes, the error is in 9.5a2 as well

Edit: and in 9.5a1

Last edited 5 months ago by Thorin (previous) (diff)

comment:17 in reply to:  16 Changed 5 months ago by gk

Replying to Thorin:

Great .. my D:\Portable\ArchiveTBalpha has almost everything but 9.5a2 .. sigh... OK, done - yes, the error is in 9.5a2 as well

Great. And Firefox 72 looks fine? (That's the first version which contains the fix developed and deployed by Mozilla)

comment:18 Changed 5 months ago by Thorin

So this is a ff78-esr-will-have keyword (lots of keywords there!) and we can come back and check this ticket when we build based on that - and we don't rebase the patch from comment 13? Right?

comment:19 in reply to:  18 Changed 5 months ago by gk

Replying to Thorin:

So this is a ff78-esr-will-have keyword (lots of keywords there!) and we can come back and check this ticket when we build based on that - and we don't rebase the patch from comment 13? Right?

If the patch which landed in Firefox 72 is actually fixing the problem (maybe it's a new/different one?) we can add the keyword, yes. I was under the impression that the version we shipped would do that and I was wrong. Maybe that holds for the fix from Firefox 72 onward as well... Or we could just remove the patch we currently have and apply the one that actually landed earlier than that if it turns out to be good.

comment:20 Changed 5 months ago by sysrqb

Keywords: tbb-9.0-issues added; tbb-9.5-issues removed
Note: See TracTickets for help on using tickets.