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.
Assignee: nobody → wmccloskey
tracking-e10s: --- → ?
Assignee: wmccloskey → mrbkap
tracking-e10s: ? → m6+
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.
So, we should move chrome registry sending to happen earlier, right? (kind of a variant of 1) 2. sounds super weird and error prone.
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?
Wow, that was a brain fart on my part, yeah. https://treeherder.mozilla.org/#/jobs?repo=try&revision=12ee670a9cd1
Created attachment 8594185 [details] [diff] [review] Remove workaround
Attachment #8594185 - Flags: review?(dtownsend)
Attachment #8594185 - Flags: review?(dtownsend) → review+
Status: NEW → RESOLVED
Last Resolved: 3 years ago
status-firefox40: --- → fixed
Resolution: --- → FIXED
Target Milestone: --- → mozilla40
You need to log in before you can comment on or make changes to this bug.