Closed Bug 1615109 Opened 6 months ago Closed 4 months ago

Could not map contract ID '@mozilla.org/sharepicker;1' to CID {1201d357-8417-4926-a694-e6408fbedcf8} because no implementation of the CID is registered.

Categories

(Core :: DOM: Core & HTML, defect, P2)

defect

Tracking

()

VERIFIED FIXED
mozilla76
Tracking Status
firefox74 --- wontfix
firefox75 --- wontfix
firefox76 --- verified

People

(Reporter: cpeterson, Assigned: mccr8)

Details

Attachments

(2 files)

Steps to reproduce

  1. Enable Fission
  2. Open multiprocess browser console (Ctrl+Shift+J)
  3. Open any website, such as cnn.com

Expected results

The page loads without any errors logged to the browser console.

Actual results

Many browser console errors about the sharepicker:

Could not map contract ID '@mozilla.org/sharepicker;1' to CID {1201d357-8417-4926-a694-e6408fbedcf8} because no implementation of the CID is registered.
Could not map contract ID '@mozilla.org/sharepicker;1' to CID {1201d357-8417-4926-a694-e6408fbedcf8} because no implementation of the CID is registered.
Could not map contract ID '@mozilla.org/sharepicker;1' to CID {1201d357-8417-4926-a694-e6408fbedcf8} because no implementation of the CID is registered.

I don't see these console errors when Fission is disabled.

Correction: I do see these sharepicker errors without Fission, but the errors are much more frequent with Fission (perhaps because there are more content processes?).

Component: DOM: Core & HTML → XPCOM

kmag wonders if we are registering sharepicker incorrectly. Nika says it is registered in multiple places, which is surprising.

kmag asked me to assign this bug to him.

This bug is not Fission related, but we see more console errors with Fission because we're spawning more content processes, each of which is registering sharepicker.

Fission Milestone: ? → ---
Priority: -- → P2
Summary: [Fission] Could not map contract ID '@mozilla.org/sharepicker;1' to CID {1201d357-8417-4926-a694-e6408fbedcf8} because no implementation of the CID is registered. → Could not map contract ID '@mozilla.org/sharepicker;1' to CID {1201d357-8417-4926-a694-e6408fbedcf8} because no implementation of the CID is registered.

(In reply to Chris Peterson [:cpeterson] from comment #2)

kmag wonders if we are registering sharepicker incorrectly. Nika says it is registered in multiple places, which is surprising.

kmag asked me to assign this bug to him.

Doesn't look like this happened?

I see these messages even with fission disabled now.

Flags: needinfo?(kmaglione+bmo)

(In reply to :Gijs (he/him) from comment #3)

I see these messages even with fission disabled now.

That is expected. This bug is not caused by Fission, but we see more console errors with Fission because we're spawning more content processes, each of which is registering sharepicker.

Assignee: nobody → continuation
Flags: needinfo?(kmaglione+bmo)
Component: XPCOM → DOM: Core & HTML

This is a problem with the way share picker registration is done. @mozilla.org/sharepicker;1 is associated with kNS_SHAREPICKER_CID, but then there is no implementation given for kNS_SHAREPICKER_CID. However, we don't use the sharepicker in the content process, so just remove that.

The stub implementation in browser/components/webshare/ also looks questionable to me:

  • The share picker is defined on Android and Windows, so does that mean we have two implementations of webshare on those platforms? I'm not sure what happens there.
  • The getters that return constant values should probably be fields. For instance, QueryInterface() will generate a new QI function every time it is called. (kmag pointed this out.)

I think the easiest fix for those two issues is to delete the stub implementation. ShareDelegate looks like a better implementation to crib off of at this point. I think the code will deal with @mozilla.org/sharepicker;1 not being implemented in a reasonable way, but I'll need to double check that.

This file has an entry in kWidgetContracts for kNS_SHAREPICKER_CID, but not in
kWidgetCIDs, so there's no implementation. I think this is causing the "Could
not map contract" warning message. We never use the share picker in the content
process, so just remove this.

The stub implementation seems like it conflicts on platforms where we have an
implementation, is registered in the child process where we don't need it,
and the implementation itself uses getters where it should use fields.

The code that tries to find a sharepicker implementation handles one not
being registered just fine as far as I can see, so just remove the stub
implementation now that we have actual implementations for people to
look at.

Pushed by amccreight@mozilla.com:
https://hg.mozilla.org/integration/autoland/rev/baebb5cd3163
part 1 - Get rid of the unused content process share picker registration. r=marcosc
https://hg.mozilla.org/integration/autoland/rev/6ae6f2b454d8
part 2 - Remove the SharePicker stub implementation. r=marcosc
Status: NEW → RESOLVED
Closed: 4 months ago
Resolution: --- → FIXED
Target Milestone: --- → mozilla76
Flags: qe-verify+

Reproduced the issue using 75.0a1 (20200212205745) on Windows 10x64.
The issue is verified fixed with 76.0b5 (20200415234430) on Windows 10x64. There are no Could not map contract ID '@mozilla.org/sharepicker;1' to CID {1201d357-8417-4926-a694-e6408fbedcf8} because no implementation of the CID is registered. errors thrown in browser console after visiting https://edition.cnn.com on Windows 10x64.

Status: RESOLVED → VERIFIED
Flags: qe-verify+
You need to log in before you can comment on or make changes to this bug.