Bugzilla

(In reply to Robin Steuber (they/them) [:bytesized] from comment #2)
> That doesn't sound like the expected behavior. Could you please enable `app.update.log` in `about:config`, open the browser console (Control+Shift+J), set the filter to `AUS:`, reproduce this bug, and attach the resulting console messages to this bug so that I can see what's going on?

I will try to reproduce by deleting the task. I don't know if I'll be able to get into the same state as it was before. This user profile is a few decades old (pre-Firefox) and has been used across completely different platforms, so could've ended up in this state through some weird chain of Firefox settings changes throughout the years. Unfortunately I did not capture what the settings were yesterday before I finally managed to get the Firefox Background Update task created.

But even before I try, the more I look at this Firefox Background Update task the more confusing and puzzling the whole thing looks. The task did not exist yesterday, until I managed to finally get it created last night by following the steps I outlined in the first post. This morning, while looking at it closer and trying to Run it manually on demand a few times, I noticed a number of things:
a. It shows Last Run Time as being 2 weeks ago 2024-01-12.
c. Task trigger is dated 2 years ago 2022-03-06.
d. Last Run Result is: (0xC000026B).
c. When running, the task uses a privileged Admin account, not the normal user account that run Firefox during the above steps that triggered its creation (it was really late, but I don't think I executed Firefox with "run as administrator" last night).
d. The task is configured to "Run only when user is logged on".

This raises a number of questions:
* Does this mean the task existed before and then somehow disappearted 2 weeks ago (but preserved prior execution history)?
* Is 2022-03-06 a hardcoded trigger date during task creation?
* Task seems to be failing to run when triggered either automatically or manually (I haven't found what 0xC000026B code means). Is this because it's configured to run only when Admin user happens to be logged in during trigger time (which is almost never)?

> Even assuming that there is, it is currently a hard requirement that Firefox have a default profile that has been used at least once in order to run Background Update. I'll have to think about if there is any way to get around this.

Are you referring to Firefox profile or Windows user profile for this hard requirement?
Or both, because one implies the other?
Or default Firefox profile within each Windows user profile?
Or does Firefox nominate a specific Firefox profile inside a specific Windows user profile as being default and remembers it in some system-wide setting somewhere, like HKLM registry?

Is this related to the "Run only when user is logged on" task setting?
Is the task configured to run using Admin account because Admin was used to install Firefox initially at some point?
I doubt that is the case as I'm pretty sure this Admin account was created after Firefox was already installed/used.

I would think configuring this task to "Run whether user is logged on or not" would be a lot more preferable than the current "Run only when user is logged on" setting. Or would this break the default profile hard requirement you are referring to?

(In reply to Robin Steuber (they/them) [:bytesized] from comment #2)
> That doesn't sound like the expected behavior. Could you please enable `app.update.log` in `about:config`, open the browser console (Control+Shift+J), set the filter to `AUS:`, reproduce this bug, and attach the resulting console messages to this bug so that I can see what's going on?

I will try to reproduce by deleting the task. I don't know if I'll be able to get into the same state as it was before. This user profile is a few decades old (pre-Firefox) and has been used across completely different platforms, so could've ended up in this state through some weird chain of Firefox settings changes throughout the years. Unfortunately I did not capture what the settings were yesterday before I finally managed to get the Firefox Background Update task created.

But even before I try, the more I look at this Firefox Background Update task the more confusing and puzzling the whole thing looks. The task did not exist yesterday, until I managed to finally get it created last night by following the steps I outlined in the first post. This morning, while looking at it closer and trying to Run it manually on demand a few times, I noticed a number of things:

a. It shows Last Run Time as being 2 weeks ago 2024-01-12.
c. Task trigger is dated 2 years ago 2022-03-06.
d. Last Run Result is: (0xC000026B).
c. When running, the task uses a privileged Admin account, not the normal user account that run Firefox during the above steps that triggered its creation (it was really late, but I don't think I executed Firefox with "run as administrator" last night).
d. The task is configured to "Run only when user is logged on".

This raises a number of questions:
* Does this mean the task existed before and then somehow disappearted 2 weeks ago (but preserved prior execution history)?
* Is 2022-03-06 a hardcoded trigger date during task creation?
* Task seems to be failing to run when triggered either automatically or manually (I haven't found what 0xC000026B code means). Is this because it's configured to run only when Admin user happens to be logged in during trigger time (which is almost never)?

> Even assuming that there is, it is currently a hard requirement that Firefox have a default profile that has been used at least once in order to run Background Update. I'll have to think about if there is any way to get around this.

Are you referring to Firefox profile or Windows user profile for this hard requirement?
Or both, because one implies the other?
Or default Firefox profile within each Windows user profile?
Or does Firefox nominate a specific Firefox profile inside a specific Windows user profile as being default and remembers it in some system-wide setting somewhere, like HKLM registry?

Is this related to the "Run only when user is logged on" task setting?
Is the task configured to run using Admin account because Admin was used to install Firefox initially at some point?
I doubt that is the case as I'm pretty sure this Admin account was created after Firefox was already installed/used.

I would think configuring this task to "Run whether user is logged on or not" would be a lot more preferable than the current "Run only when user is logged on" setting. Or would this break the default profile hard requirement you are referring to?