Static registration of components should fail when registering the same contracts for the same process
Categories
(Core :: XPCOM, defect)
Tracking
()
| Tracking | Status | |
|---|---|---|
| firefox68 | --- | fixed |
People
(Reporter: glandium, Assigned: glandium)
References
Details
Attachments
(1 file)
While we do have legitimate uses of runtime registration of components to override the builtin ones for e.g. tests, allowing that for static registrations is a footgun. In fact, I spent a large amount of time trying to figure out why moving android widget components to static registration broke one specific clipboard test, and the reason was that @mozilla.org/widget/clipboard;1 is registered for all processes in widget/android, and then registered for the content process only in widget. Before my changes, the latter component was used, and after my changes, the former, because, without changing the process selection, the changed order made the content process-only component ignored in my case.
At the very least, we should do this check on debug builds.
|
Assignee | |
Comment 1•5 years ago
|
||
Because not all static components are using the static registration yet,
we can end up in situations where a same component is registered
multiple times, which can have some unexpected consequences.
Interestingly enough, this change revealed that we did have static
registration in place for components that were kept under the old system
after bug 1478124 and bug 1524687.
There are also possibly some non-obvious things that can happen while
migrating the remaining components, like what happened to me while I
worked on @mozilla.org/widget/components;1 (see bug 1542214 comment 0).
Pushed by mh@glandium.org: https://hg.mozilla.org/integration/autoland/rev/fd68ef11f142 Prevent registering the same CID and contract IDs during component manager initialization. r=froydnj
|
||
Comment 3•5 years ago
|
||
| bugherder | ||
Description
•