2013816 - Firefox may fail to start due to "Couldn't convert chrome URL: chrome://branding/locale/brand.properties"

Status: RESOLVED WORKSFORME

(Toolkit :: Startup and Profile System, defect, P3)

Description

[Henrik Skupin [:whimboo][⌚️UTC+2]]

For bug 1868846 I can see that whenever browser chrome tests are not running and failing early with Waiting for browser... that no browser window is actually open. Whenever this happens the following output can be seen in the log:

https://treeherder.mozilla.org/logviewer?job_id=546499801&repo=autoland&lineNumber=6047-6048

[task 2026-02-01T05:03:10.101+00:00] 05:03:10     INFO - GECKO(5039) | Couldn't convert chrome URL: chrome://branding/locale/brand.properties
[task 2026-02-01T05:03:10.102+00:00] 05:03:10     INFO - GECKO(5039) | [Child 5044, Main Thread] WARNING: Could not get the program name for a cubeb stream.: 'NS_SUCCEEDED(rv)', file /builds/worker/checkouts/gecko/dom/media/CubebUtils.cpp:569
[task 2026-02-01T05:15:07.123+00:00] 05:15:07     INFO - runtests.py | Waiting for browser...
[task 2026-02-01T05:15:30.150+00:00] 05:15:30     INFO - TEST-UNEXPECTED-TIMEOUT | automation.py | application timed out after 740 seconds with no output

I assume that there is something wrong with the loading of chrome://branding/locale/brand.properties which indeed is a central piece of information. The failures only happen on autoland but never for mozilla-central nor release branches. As such I assume that there is a problem with registering this file as chrome handler?

Note that this is not a broken build given that subsequent starts of Firefox for the same installed binary will work and the failure is gone:
https://treeherder.mozilla.org/logviewer?job_id=546499801&repo=autoland&lineNumber=4119-4122

Also this seems to be a macOS only issue when checking the classified failures on bug 1868846.

Dave, do you have an idea?

Comment 1

[Henrik Skupin [:whimboo][⌚️UTC+2]]

Err, wait. Bug 1414495 actually covers all the other platforms while bug 1868846 is only about the TV jobs.

Comment 2

[Dave Townsend [:mossop]]

The error looks like it is coming from CubebUtils trying to load the branding in a child process. I wonder if that initialisation is racing with getting the chrome protocol registrations down to the child process?

Any ideas Paul?

Comment 3

[Paul Adenot (:padenot)]

This has been going on for the longest time and isn't the issue here. I'll get it sorted in bug 2013874.

Comment 4

[Henrik Skupin [:whimboo][⌚️UTC+2]]

Paul, so you are saying it's definitely not blocking the start of Firefox and in detail for opening the first browser window? The thing is that each time we have this failure I can see this message but not when it all works.

Comment 5

[Paul Adenot (:padenot)]

Yes. I wrote a fix, you'll be able to try after landing.

Comment 6

[BugBot [:suhaib / :marco/ :calixte]]

The severity field is not set for this bug.
:mossop, could you have a look please?

For more information, please visit BugBot documentation.

Comment 7

[Paul Adenot (:padenot)]

Let's not bother mossop with this one. I got backed out, will reland, and we can investigate.

Comment 8

[Henrik Skupin [:whimboo][⌚️UTC+2]]

Now with bug 2013874 fixed last Friday the number of failures on bug 1414495 reduced quite a lot. But maybe it's just because there were lesser pushes due to the weekend. I'll observe the test failures over the next couple of days to see if it helped for real or not.

Comment 9

[Henrik Skupin [:whimboo][⌚️UTC+2]]

Checking bug 1414495 again I can see that all the failures on autoland and mozilla-central have stopped from appearing. There is no more a hang during startup with the Waiting for browser... message.

But this looks different for bug 1868846, which is for TV jobs on macOS. Here I can still see that for a build from yesterday:

https://treeherder.mozilla.org/logviewer?job_id=551485774&repo=autoland&lineNumber=7062-7065

[task 2026-03-03T03:49:38.046+00:00] 03:49:38     INFO - GECKO(1968) | Couldn't convert chrome URL: chrome://branding/locale/brand.properties
[task 2026-03-03T03:49:38.047+00:00] 03:49:38     INFO - GECKO(1968) | [Child 1977, Main Thread] WARNING: Could not get the program name for a cubeb stream.: 'NS_SUCCEEDED(rv)', file /builds/worker/checkouts/gecko/dom/media/CubebUtils.cpp:569
[task 2026-03-03T04:01:35.147+00:00] 04:01:35     INFO - runtests.py | Waiting for browser...
[task 2026-03-03T04:01:58.073+00:00] 04:01:58     INFO - TEST-UNEXPECTED-TIMEOUT | automation.py | application timed out after 740 seconds with no output

Looks like there is still an issue left.

Comment 10

[Henrik Skupin [:whimboo][⌚️UTC+2]]

Paul, so far we got two more failures (only \o/) classified with this underlying issue. Othewise the patch helped a lot - so it was really the reason why Firefox didn't correctly started up. Any idea what might still not work as expected? If not we could let the bug sit around for a while and continue to observe.

Comment 11

[Paul Adenot (:padenot)]

Are we sure it simply didn't change signature? Or that the line in the log was about another issue?

Comment 12

[Henrik Skupin [:whimboo][⌚️UTC+2]]

(In reply to Paul Adenot (:padenot) from comment #11)

Are we sure it simply didn't change signature? Or that the line in the log was about another issue?

In my view, it would be quite surprising if the behavior changed exactly when your first patch landed, given that this (hang around Waiting for browser) issue existed for years.

Comment 13

[Henrik Skupin [:whimboo][⌚️UTC+2]]

While all the failures for bug 1414495 are now gone (yay!!) the hang is still present for TV jobs (bug 1868846). But the log output doesn't show any problem with this particular failure, which as well no longer appears.

Lets close this bug as WFM for now.