Closed Bug 1618375 Opened 6 years ago Closed 6 years ago

Thunderbird fails to start with blocklist.xml: TypeError: doc is null

Categories

(Toolkit :: Blocklist Implementation, defect)

68 Branch
defect
Not set
normal

Tracking

()

RESOLVED FIXED
Tracking Status
firefox-esr68 76+ fixed
firefox74 --- unaffected
firefox75 --- unaffected
firefox76 --- unaffected
firefox77 --- unaffected

People

(Reporter: mozilla-bugs, Assigned: Gijs)

Details

Attachments

(1 file)

User Agent: Mozilla/5.0 (X11; Linux x86_64) AppleWebKit/537.36 (KHTML, like Gecko) QtWebEngine/5.14.1 Chrome/77.0.3865.129 Safari/537.36

Steps to reproduce:

I had Thunderbird crashing, and then it failed to start.

On the terminal I've seen:

JavaScript error: resource://gre/modules/Blocklist.jsm, line 2086: TypeError: doc is null

I've found that there is an empty blocklist.xml file (0 bytes).

Removing it allowed Thunderbird to start again.

This should be handled more gracefully.

Component: Untriaged → Security
Component: Security → Blocklist Implementation
Product: Thunderbird → Toolkit
Version: 68 → 68 Branch

Although this bug was seen with Thunderbird, I'm reassigning it to "toolkit". Looks like this is in general code not specific to TB.

Ugh. The XML implementation has been removed from mozilla-central. It's not on any supported branches anymore besides ESR 68. :-\

I suppose a nullcheck isn't particularly hard to add, though it does seem like quite the edgecase.

Status: UNCONFIRMED → NEW
Ever confirmed: true
Assignee: nobody → gijskruitbosch+bugs
Status: NEW → ASSIGNED

Comment on attachment 9138591 [details]
Bug 1618375 - handle empty blocklist.xml file in case of crashes, r?florian

ESR Uplift Approval Request

  • If this is not a sec:{high,crit} bug, please state case for ESR consideration: Adds a nullcheck and prevents Firefox/Thunderbird never starting up
  • User impact if declined: Some users may get stuck in a state where Firefox/Thunderbird never starts up
  • Fix Landed on Version: n/a
  • Risk to taking this patch: Low
  • Why is the change risky/not risky? (and alternatives if risky): I'm just adding some nullchecks. We're handling a case where previously, the load event handler would throw an exception, so we'd wait forever on a Promise, and potentially not start up as a result.
  • String or UUID changes made by this patch: n/a
Attachment #9138591 - Flags: approval-mozilla-esr68?

Ryan, this code has been removed on central/beta (and is preffed off on release so landing it there makes no difference) so it cannot really land anywhere other than esr. Please can you ensure this shows up on the relevant person's triage for approval? Thanks!

Flags: needinfo?(ryanvm)

(In reply to :Gijs (he/him) from comment #5)

Ryan, this code has been removed on central/beta (and is preffed off on release so landing it there makes no difference) so it cannot really land anywhere other than esr. Please can you ensure this shows up on the relevant person's triage for approval? Thanks!

Ryan says I don't need to do anything else. :-)

Flags: needinfo?(ryanvm)

Comment on attachment 9138591 [details]
Bug 1618375 - handle empty blocklist.xml file in case of crashes, r?florian

Add a null check to avoid crashing in some edge cases. Approved for 68.8esr.

Attachment #9138591 - Flags: approval-mozilla-esr68? → approval-mozilla-esr68+
Status: ASSIGNED → RESOLVED
Closed: 6 years ago
Resolution: --- → FIXED

Thanks for uplifting this.

Just for grins I tried this on WIndows to see if I could get a crash report: 68.6.0 starts up, 68.4.1 just hangs forever with a little CPU

You need to log in before you can comment on or make changes to this bug.

Attachment

General

Creator:
Created:
Updated:
Size: