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

During start-up I can see:

JavaScript error: re[//modules/sessionstore/SessionStore.jsm,](//modules/sessionstore/SessionStore.jsm,) line 1325: uncaught exception: 2147746065

added GeorgKoppen201911 TorBrowserTeam201911R actualpoints::0.1 component::applications/tor browser ff68-esr owner::pospeselr points::0.1 priority::medium severity::normal status::reopened tbb-9.0-issues tbb-9.0.1-can tbb-regression type::defect labels

Trac:
Cc: N/A to intrigeri

9.0 issues.

Trac:
Keywords: N/A deleted, tbb-9.0-issues added

Trac:
Keywords: N/A deleted, tbb-regression added

Trac:
Keywords: N/A deleted, tbb-9.0.1-can added

Trac:
Status: new to assigned
Owner: tbb-team 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.

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.

Trac:
Cc: intrigeri to intrigeri, tbb-team

Filed Mozilla issue: https://bugzilla.mozilla.org/show_bug.cgi?id=1591259

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.

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.

Trac:
Points: N/A to 0.1
Keywords: N/A deleted, GeorgKoppen201911, TorBrowserTeam201911R added
Actualpoints: N/A to 0.1
Status: assigned to needs_review

Looks good to me!

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

Trac:
Status: needs_review to closed
Resolution: N/A to fixed

Trac:

it's still happening guys...

Trac:
Resolution: fixed to N/A
Status: closed to reopened

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?

Trac:
Keywords: tbb-9.0-issues deleted, tbb-9.5-issues added

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

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)