Closed Bug 966467 Opened 6 years ago Closed 6 years ago

[e10s] Content processes should get different widgets than the main process

Categories

(Core :: Widget, defect)

x86_64
Linux
defect
Not set

Tracking

()

VERIFIED FIXED
mozilla30
Tracking Status
firefox31 --- verified

People

(Reporter: billm, Assigned: billm)

References

Details

(Keywords: addon-compat)

Attachments

(4 files)

There are a number of services and components that get created in all processes but that don't make sense in content processes. Some examples:

nsIDragService
nsIClipboard
nsIFilePicker
all the stuff related to printing

These things make OS calls that won't be available to content processes once they're sandboxed. Even now they sometimes crash. It would be better to avoid instantiating these services in child processes.

In addition, we often want to expose other versions of these services in content processes. For example, we already have nsFilePickerProxy, which just forwards all method calls to the parent. Pretty soon we're going to have other proxy services. The way nsFilePickerProxy is exposed is kind of hacky, and it would be nice to make clean interfaces for all this.
This first patch allows us to selectively expose services to either the content process or the main process.
Attachment #8368815 - Flags: review?(benjamin)
Attached patch disable-servicesSplinter Review
This patch disables a bunch of services that we don't want in content processes.
Attachment #8368816 - Flags: review?(vladimir)
Attached patch content-widgetsSplinter Review
This patch adds a file widgets/xpwidgets/nsContentProcessWidgetFactory.cpp. Its purpose is to create all the widgets that are cross-platform and meant only for content processes. To start with, it just contains the existing nsFilePickerProxy.
Attachment #8368819 - Flags: review?(vladimir)
This patch adds nsClipboardProxy, which I copied from the old Android widget code. I also expanded it a little to handle the selection clipboard that X has. It only handles text data in the clipboard, but we can fix that later.
Attachment #8368821 - Flags: review?(vladimir)
Duplicate of this bug: 961536
Comment on attachment 8368815 [details] [diff] [review]
xpcom-process-selector

It would be nice to extend this in a followup to allow chrome.manifest-registered JS components to be able to be marked CONTENT_PROCESS_ONLY/MAIN_PROCESS_ONLY (for e.g. bug 930456).
Blocks: 910384
Comment on attachment 8368815 [details] [diff] [review]
xpcom-process-selector

How does this affect B2G? That has or will have main/app/content processes at least for the browser. Which processes will be used for each of those?
Attachment #8368815 - Flags: review?(benjamin) → review+
Jorge this changes the layout of CIDEntry, which means that binary components cannot be compiled to work with multiple versions. We need to announce this to Skype/Norton toolbar at least and put it in the developer notes.
Keywords: addon-compat
B2G uses GeckoProcessType_Content processes for everything that's not the main process. My strategy for dealing with this is:
1. Don't use these process selectors in the gonk widget code.
2. Exclude the nsContentProcessWidgetFactory.cpp code from B2G using an #ifdef (I had to add that after I posted the patch).
(In reply to Benjamin Smedberg  [:bsmedberg] from comment #8)
> Jorge this changes the layout of CIDEntry, which means that binary
> components cannot be compiled to work with multiple versions. We need to
> announce this to Skype/Norton toolbar at least and put it in the developer
> notes.

Do we not version this somehow?
(In reply to Benjamin Smedberg  [:bsmedberg] from comment #8)
> Jorge this changes the layout of CIDEntry, which means that binary
> components cannot be compiled to work with multiple versions.

Can't work with 29 and 30, or can't ever work with multiple versions again?
Duplicate of this bug: 936089
Verified in the duplicate https://bugzilla.mozilla.org/show_bug.cgi?id=936089#c10
Status: RESOLVED → VERIFIED
You need to log in before you can comment on or make changes to this bug.