1857058 - Save Browser Console update logs alongside other update log files

Status: NEW

(Toolkit :: Application Update, enhancement, P3)

Description

[Robin Steuber (she/her) [:bytesized]]

It is often frustrating when debugging reported update issues that the logs from Firefox downloading, staging, and preparing are not preserved by the time the user typically notices the update. So if the issue is difficult to reproduce, it become difficult to get the logs needed to fix the issue.

I think that we could fix this by putting these logs alongside update.log in the update patch directory and then either cleaning them up (or not write them in the first place, if possible) if there ultimately is no update or moving them to stay alongside last-update.log and backup-update.log if we attempt to install an update.

We have something like this now except that it logs to the profile directory, it is gated behind app.update.log.file, and it automatically turns itself off at application launch to prevent unnecessary I/O. We can probably just remove the pref when we make this change, but we do want to address the excessive I/O problem; the update service can generate log messages pretty often and we really don't want a high fraction of those to generate disk traffic. We'll have to investigate whether there is a file I/O interface that can perform the level of buffering that we'd want here or if we'll need to implement our own buffering.

Comment 1

[Robin Steuber (she/her) [:bytesized]]

Oh, also, like with update.log, I would really like to write this in the default case rather than just when app.update.log is turned on. I'm not sure if that decision will get push back; we may need to discuss this further. But I would consider that to be the ideal situation.

Comment 2

[Wayne Mery (:wsmwk)]

(In reply to Robin Steuber (she/her) [:bytesized] from comment #1)

Oh, also, like with update.log, I would really like to write this in the default case rather than just when app.update.log is turned on. I'm not sure if that decision will get push back; we may need to discuss this further. But I would consider that to be the ideal situation.

Did you get any useful feedback?

Comment 3

[Robin Steuber (she/her) [:bytesized]]

No one has argued with me about it yet. So I'm considering it.