1141661 - Delayed process scripts at chrome URLs aren't loaded in new processes

Status: RESOLVED FIXED

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

Description

[Dave Townsend [:mossop]]

Because we send the chrome registry across after we attempt to load process scripts in a new process any process script at a chrome URL can't be found.

Comment 1

[Blake Kaplan (:mrbkap) (inactive)]

I see two ways to fix this:

  1. Try to delay loading frame scripts until later in PContent startup (that is, after we register chrome).
  2. Remember any chrome:-protocol'd scripts that failed to resolve in the child and try to re-resolve them when we register new chrome. This seems safer, but I don't know if we want to allow buggy extensions to accidentally load frame scripts before they register their chrome.

Olli, any additional thoughts? My initial reaction is to implement option 2.

Comment 2

[Olli Pettay [:smaug][[e-mail]]]

So, we should move chrome registry sending to happen earlier, right?
(kind of a variant of 1)


2. sounds super weird and error prone.

Comment 3

[Dave Townsend [:mossop]]

Seems like it would be straightforward to do 1. Sending the process scripts and sending the chrome registry both happen synchronously from ContentParent::InitInternal so we just need to flip the order no?

Comment 4

[Blake Kaplan (:mrbkap) (inactive)]

Wow, that was a brain fart on my part, yeah.

https://treeherder.mozilla.org/#/jobs?repo=try&revision=12ee670a9cd1

Comment 5

[Blake Kaplan (:mrbkap) (inactive)]

Attachment: Fix

Comment 6

[Blake Kaplan (:mrbkap) (inactive)]

Attachment: Remove workaround

Comment 7

[Wes Kocher (:KWierso) (Not reading bugmail; email directly if needed)]

https://hg.mozilla.org/integration/mozilla-inbound/rev/43f77c634a8b
https://hg.mozilla.org/integration/mozilla-inbound/rev/87048f5c4e77

Comment 8

[Carsten Book [:Tomcat]]

https://hg.mozilla.org/mozilla-central/rev/43f77c634a8b
https://hg.mozilla.org/mozilla-central/rev/87048f5c4e77