1872482 - XULRunner "Could not determine any profile running in backgroundtask mode!" window appears intermittently (maybe Nightly is updating in background?)

Status: RESOLVED FIXED

(Toolkit :: Startup and Profile System, defect)

Description

[Mayank Bansal]

Recently started seeing this window. While this window is open, I get the second message if I manually try to search for updates.

Comment 1

[Mayank Bansal]

Attachment: Screenshot 2023-12-30 171918.png

Comment 2

[Mayank Bansal]

Attachment: Screenshot 2023-12-30 172143.png

Comment 3

[Mayank Bansal]

Attachment: about:support

Comment 4

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

Are you still experiencing this problem? I'm suspicious that the issue is that the background update task is attempting to run when there is no default profile set. It's not surprising to me that this would fail to work, but it is surprising to me that we would show a window in that case. We really shouldn't be showing any kind of UI from the Background Update Task. I'm also surprised that we aren't unregistering the background update task.

Comment 5

[Mayank Bansal]

I still see this everyday. I am pretty sure I have set a default profile.

Comment 6

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

(In reply to Mayank Bansal from comment #5)

I still see this everyday. I am pretty sure I have set a default profile.

Could you check in about:profiles? There should be one entry without a "Set as Default Profile" button.

Also, could you provide background update task logs? These can be obtained by navigating to about:support, clicking on the "Open Folder" button in the "Update Folder" row, and then finding backgroundupdate.moz_log.

Comment 7

[Mayank Bansal]

Attachment: Screenshot 2024-02-27 235954.png

Comment 8

[Mayank Bansal]

Attachment: backgroundupdate.moz_log

Comment 9

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

Well, it looks like the issue is happening here. I believe that this is before anything meaningful gets logged, which is pretty consistent with the recent log entries that show nearly nothing. But (a) I don't think we should show that or any dialog in background task mode and (b) it's concerning to me that we are getting that at all when it seems that there is a default profile.

I would like to investigate this further, but it will need to wait a bit. I'm incredibly busy right this moment. In the meantime, I am going to increase the severity because I would consider the combination of the above 2 issues to be serious enough to warrant it.

Comment 10

[Sören Hentzschel]

Attachment: backgroundtask.png

The same error message was reported in the German Firefox support forum three weeks ago when a user tried to install Firefox 122.0.1 over Firefox 122.0. We have not received any further reports.

Comment 11

[janbrex]

We have the same error here too. German Version 123.0. Seems to be occurring daily for the past few weeks.

Comment 12

[Mayank Bansal]

Attachment: Bug2.png

I sometimes get this window too.

Comment 13

[Mike Conley (:mconley) (:⚙️)]

I had a family member report this to me over the weekend. They're seeing it several times a day. I also asked what experiments were listed in about:studies, and they were:

• BackgroundUpdate: Enable unelevated installations (rollout) - 3 release
• Launch Firefox on OS restart - treatment A rollout
• spocs endpoint rollout (release)
• MozillaAccounts toolbar button default visibility rollout
• add an image to PDF (with alt text) - rollout
• upgrade spotlight rollout
• CSV import (release rollout)

Comment 14

[Max]

Hi!
It first looks as if the error message from Mayank Bansal was unrelated as this bug is about:

Could not determine any profile running in backgroundtask mode

and the image Attachment 9390378 [details] shows:

This profile was last used with a newer version of this application. Please create a new profile.

However, I wonder if the common denominator might just be our assumption about headless mode not displaying dialogs, which in fact seems to be not yet fully implemented/for all edge cases and that we should conditionally use printf_stderr instead of Output, like here? That would consequently mean, that these are not actual error messages indicating an real error, but log messages indicating that we found the correct abort condition. That said I realize that this is not an explanation why this would start happening now, but in fact the linked bug suggests that this already happened one year ago and I quote Nick Alexander:

There are two situations that I know of that can cause this, both unusual:

1. The background task profile directory (in Background Tasks Profiles/) has been deleted entirely.
2. The background task profile has been downgraded (see https://bugzilla.mozilla.org/show_bug.cgi?id=1792756).
   So I am going to link Bug 1792756 as well here.

And question to Nick: I wonder if and if, how updates for unelevated installations could have triggered the error to be shown more frequently? Let me know if you got an idea, because I am going to look on it, but I can only work time boxed right now and am not sure how far that will get me with this.

Comment 15

[Mike Conley (:mconley) (:⚙️)]

Not sure if this is helpful, but I debugged this with my family member over the weekend. My primary goal was to prevent the dialog from appearing again, and collecting general diagnostic data was a distant secondary goal.

What I found out is that there was an item in profiles.ini for the background update task, but no corresponding profile folder within the background task profiles folder. After creating that folder and manually running the background update task via the Windows Task Scheduler, I confirmed that the dialog did not reappear.

Comment 16

[Nick Alexander :nalexander [he/him]]

(In reply to Mike Conley (:mconley) (:⚙️) from comment #15)

Not sure if this is helpful, but I debugged this with my family member over the weekend. My primary goal was to prevent the dialog from appearing again, and collecting general diagnostic data was a distant secondary goal.

What I found out is that there was an item in profiles.ini for the background update task, but no corresponding profile folder within the background task profiles folder. After creating that folder and manually running the background update task via the Windows Task Scheduler, I confirmed that the dialog did not reappear.

Thanks for sleuthing, Mike. Do you recall if this installation was privileged/elevated, i.e., in c:/Program Files?

It seems to me that we can teach the background task profile system to create the profile folder if it's missing. See also Bug 1873274, which is about harmonizing some other detail of the profile system about missing profile folders.

Comment 17

[Mike Conley (:mconley) (:⚙️)]

I believe the installation is under Program Files, yes.

Comment 18

[Nick Alexander :nalexander [he/him]]

(In reply to Mike Conley (:mconley) (:⚙️) from comment #17)

I believe the installation is under Program Files, yes.

Thanks!

For Max: that almost certainly rules out any interaction with unelevated updates.

Comment 19

[Mayank Bansal]

Attachment: profiles.ini

Comment 20

[Mayank Bansal]

Attachment: installs.ini

Comment 21

[Nick Rishel [:nrishel]]

STR

1. Run firefox --backgroundtask defaultagent do-task asdf.
2. Delete %appdata%/Mozilla/Firefox/Background Task Profiles/[hash].MozillaBackgroundTask-[progid]-defaultagent.
3. Run firefox --backgroundtask defaultagent do-task asdf.

Expectation:
Background task runs, recreating it's profile.

Actual:
"Could not determine any profile running in backgroundtask mode!" message box appears.

Note:
Deleting the related entry from [BackgroundTasksProfiles] in profiles.ini fixes the issue.

Comment 22

[Nipun Shukla]

Marking this as S4 due to it no longer being user-visible as per the fix in Bug 1889464.

Comment 23

[Mayank Bansal]

Hi Nipun,

Since bug 1889464, I do not see the error message from comment 1.
But I still see the error message from comment 12. Can that be "fixed" as well?

Comment 24

[Nipun Shukla]

That's tracked in bug 1876714 and is marked as lower severity due to it generally requiring the user to install multiple channels of Firefox and mix and match profiles between them.

Comment 25

[Max]

Here comes a version to automatically create a new profile with the old name. This makes it work a little bit like $HOME/.local/ kind of directories. The version contains some printf debugging and does not restore the actual name of the original profile (only creates its former path name). The reason I am committing it in this unfinished state is to hand it over. I hope you find it useful and do not forget to adapt the mozconfig and comment out # ac_add_options --enable-artifact-builds to try it.

Comment 26

[Max]

Attachment: WIP: Bug 1872482 - XULRunner "Could not determine any profile running in backgroundtask mode!"

Comment 27

[Eric Chen]

(In reply to Mike Conley (:mconley) (:⚙️) from comment #15)

Not sure if this is helpful, but I debugged this with my family member over the weekend. My primary goal was to prevent the dialog from appearing again, and collecting general diagnostic data was a distant secondary goal.

What I found out is that there was an item in profiles.ini for the background update task, but no corresponding profile folder within the background task profiles folder. After creating that folder and manually running the background update task via the Windows Task Scheduler, I confirmed that the dialog did not reappear.

Hi Mike, do you remember if and where profiles.ini is accessed within the source code? I'm currently adding the functionality to automatically recreate a missing default profile. To do so, I need to read profiles.ini to obtain the original profile name. It'll be helpful to see how "profile.ini" is previously accessed in the code so I can model my code similarly.

Comment 28

[Mike Conley (:mconley) (:⚙️)]

Hi Eric,

It's accessed fairly early on in the lifetime of the process, but my experience with profiles.ini drops off pretty quickly after that. I recommend asking Mossop or jhirsch in Matrix, or needinfo'ing one of them in the bug you've been assigned for that work to get more details.

Comment 29

[Eric Chen]

Attachment: WIP: Bug 1872482 - recreating firefox default profile if the previous default profile's directory is missing r=mpohle!

Comment 30

[Eric Chen]

Attachment: WIP: Bug 1872482 - Restores a user's default profile if the default profile directory is missing r=m4x!

Comment 31

[Eric Chen]

Attachment: Bug 1872482 - recreate non-ephemeral background task profile directory if it's missing r=mossop!

Comment 32

[Pulsebot]

Pushed by [e-mail]:
https://hg.mozilla.org/integration/autoland/rev/75622da16db6
recreate non-ephemeral background task profile directory if it's missing r=mossop

Comment 33

[tszentpeteri]

https://hg.mozilla.org/mozilla-central/rev/75622da16db6