1,500 instances of "Couldn't convert chrome URL: chrome://branding/locale/brand.properties" emitted from none during linux64 debug testing
Categories
(Firefox :: General, defect)
Tracking
()
Tracking | Status | |
---|---|---|
firefox77 | --- | fixed |
People
(Reporter: erahm, Assigned: heycam)
References
(Blocks 1 open bug)
Details
Attachments
(1 file)
Reporter | ||
Comment 1•8 years ago
|
||
Comment 2•6 years ago
|
||
Assignee | ||
Comment 3•5 years ago
|
||
Right, this is being called to get the value to pass to gdk_set_program_name
, which influences the WM_CLASS
property of windows that get created. This happens very early in the life a process, and for a child process this happens before we send the RegisterChrome
message that causes all of the chrome packages (including "branding") to be registered. I suspect it's not important to call gdk_set_program_name
in content processes, and that we can condition this section on whether we're the parent process. Karl, does that sound right to you?
Assignee | ||
Comment 4•5 years ago
|
||
An alternative might be to move this gdk_set_program_name
call later, just before we create the first window.
Assignee | ||
Comment 5•5 years ago
|
||
Updated•5 years ago
|
Comment 6•5 years ago
|
||
I expect it should be fine to skip the call in the content process.
When GDK opens an X11 Display, even in the content process, it creates a "leader window" and sets the class name on that via XmbSetWMProperties()
. However, I doubt the leader window for the content process is actually used because there are no other windows pointing at the leader.
And, given the brand name call is failing, there is no value in making an attempt.
Comment 8•5 years ago
|
||
bugherder |
Description
•