1174239 - [meta] Identify and reduce synchronous messages sent from the content process upon tab open or switch

Status: RESOLVED FIXED

(Core :: DOM: Content Processes, defect, P2)

Description

[Mike Conley (:mconley) (:⚙️)]

I opened a tab, saw the spinner, and took a profile:

http://people.mozilla.org/~bgirard/cleopatra/#report=4b7c1d6d73b32b56ca0467164bbc4970812d35d5&filter=[{%22type%22%3A%22RangeSampleFilter%22,%22start%22%3A1385045,%22end%22%3A1391619},{%22type%22%3A%22RangeSampleFilter%22,%22start%22%3A1390396,%22end%22%3A1391615}]&selection=0,1,2,1818,1819,1820,1764,1821,14,15,1822,1823,12,13,14,15,1822,16,18,358,359,360,361,425,2145,2469,2147,2470,2471,1021,2472,2473,2474,2475,2476,2477,529,530,627,628,629,630

I notice that in the content process, we appear to be sending up a few synchronous messages. For example:

pdfjschildbootstrap.js somehow calls into the parent synchronously via PdfjsContentUtils.jsm:107:

  isDefaultHandlerApp: function () {
    return this._mm.sendSyncMessage('PDFJS:Parent:isDefaultHandlerApp')[0];
  },

Another is when we receive a message from the parent (UIResolutionChanged), and then send up a synchronous message to get the default scale.

We should probably:

1) Either defer these synchronous messages until after first paint, or better yet
2) Send down the information from the parent when the browser is first opened or switched to, instead of making the child ask for it.

These are the ones I've picked out from my profile, but I'd love it if we could find a way of identifying synchronous messages from the child that are occurring between the time that a tab is opened / switched to, and the time that it has painted.

Comment 1

[Mike Conley (:mconley) (:⚙️)]

I have a pull request to add a cleopatra diagnostic entry for WaitForSyncNotify calls:

https://github.com/bgirard/cleopatra/pull/62/files

Comment 2

[Mike Conley (:mconley) (:⚙️)]

I can't seem to find any more sync messages from the content process beyond what I've filed and marked as dependencies here.

I'm marking this as meta and removing from tracking from M8. The dependencies have all been triaged.

Comment 3

[Mayank Bansal]

should this bug be RESOLVED FIXED by tab-warming ? Can the deps (bug 1135719 ) be also closed?

Comment 4

[Mike Conley (:mconley) (:⚙️)]

Tab warming would not have impacted synchronous messaging during tab switches, so I don't think that's cause to close this one out.

The dependencies, however, are closed, so that's sufficient cause. :)