-
Notifications
You must be signed in to change notification settings - Fork 10.2k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Split pdfjschildbootstrap.js to avoid sync IPC #8218
Conversation
|
||
if (Services.appinfo.processType === Services.appinfo.PROCESS_TYPE_CONTENT) { | ||
// register various pdfjs factories that hook us into content loading. | ||
PdfJs.ensureRegistration(); |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Did you mean ensureRegistered
?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Oops! I guess I should test it a little more.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
You can run gulp firefox
to build the Firefox extension XPI locally, which should help with testing this.
@@ -173,7 +173,7 @@ var PdfJs = { | |||
|
|||
updateRegistration: function updateRegistration() { | |||
if (this.enabled) { | |||
this._ensureRegistered(); | |||
this.ensureRegistered(); |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
If this one is public, i.e., has no underscore, then I think it would be good to make _ensureUnregistered
public as well, so remove the underscore there as well for consistency.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
That sounds reasonable. I just left it private because I didn't actually need it, but it is a little weird to make it different.
@@ -0,0 +1,31 @@ | |||
/* Copyright 2014 Mozilla Foundation |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
How is this new file used at the moment? I don't see an include of it anywhere. Do you perhaps need to include it in build process like
Line 822 in cd5acf5
gulp.src(FIREFOX_CONTENT_DIR + 'pdfjschildbootstrap.js') |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Yeah, like the pdfjschildbootstrap.js file, I think isn't actually used by the extension. It is a script called directly by Firefox code, in browser/components/nsBrowserGlue.js. But yeah I guess I need to do whatever packaging thing this is doing. Maybe that's how the in-tree version in Firefox gets updated.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
There is difference in few files for firefox extension and mozilla-central. That includes PdfJsTelemetry.jsm and PdfJs.jsm files -- notice that extension "disables" embedded version of pdf.js by adding PdfJs-stub.
mozilla-central is using pdfjschildbootstrap.js+PdfJs.jsm, but firefox extension only bootstrap.js
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
That's good to know. I have some other changes I want to make to avoid loading .jsms when no PDF has been loaded, and it looks like that will help me.
Could you perhaps squash the commits into one commit (see https://github.com/mozilla/pdf.js/wiki/Squashing-Commits)? |
/botio-linux preview |
pdfjschildbootstrap.js will always be run, but pdfjschildbootstrap-enabled.js will only be run if PdfJs.enabled is true. This will let us avoid some work in the child process in the next patch. This will need to be landed in the mozilla-central repository at the same time as a change to nsBrowserGlue.js. See bug 1352218.
If we only invoke the bootstrap-enabled script when PdfJs.enabled is true, then we don't need to check it again in the script. This avoids a sync IPC call to the parent process. It also keeps PdfJs.jsm from importing PdfjsContentUtils.jsm in the child process until it is actually needed, which is one steps towards not loading it until it is really needed.
I folded the fixes into the original two patches. Is that enough, or do you really just want it in one commit? (Each patch should be a separate logical change.) |
I'm fine with having two logically separate commits for this. Thanks! I'll create a new preview for this so we have an XPI file for testing. |
/botio-linux preview |
From: Bot.io (Linux)ReceivedCommand cmd_preview from @timvandermeij received. Current queue size: 0 Live output at: http://107.21.233.14:8877/d88eb0e9ed0951e/output.txt |
From: Bot.io (Linux)SuccessFull output at http://107.21.233.14:8877/d88eb0e9ed0951e/output.txt Total script time: 2.72 mins Published |
https://bugzilla.mozilla.org/show_bug.cgi?id=1352218 Thank you for the patch. |
Thanks for all of the help with my patch. |
One is always run, the other is only run when PdfJs.enabled is true in the parent process. This refactoring enables the next patch. The extensions changes are from: mozilla/pdf.js#8218 MozReview-Commit-ID: HwQ3yk8Jck4 --HG-- extra : rebase_source : 94f1516989685176a95e235f2d3ef8658adaf8b7
This avoids a sync IPC message from child to parent. Changes entirely from: mozilla/pdf.js#8218 MozReview-Commit-ID: 3Egayok3DBZ --HG-- extra : rebase_source : e02829e2508bb75caf44c0a3c86b06fac3bf167f
One is always run, the other is only run when PdfJs.enabled is true in the parent process. This refactoring enables the next patch. The extensions changes are from: mozilla/pdf.js#8218 MozReview-Commit-ID: HwQ3yk8Jck4
This avoids a sync IPC message from child to parent. Changes entirely from: mozilla/pdf.js#8218 MozReview-Commit-ID: 3Egayok3DBZ
One is always run, the other is only run when PdfJs.enabled is true in the parent process. This refactoring enables the next patch. The extensions changes are from: mozilla/pdf.js#8218 MozReview-Commit-ID: HwQ3yk8Jck4
This avoids a sync IPC message from child to parent. Changes entirely from: mozilla/pdf.js#8218 MozReview-Commit-ID: 3Egayok3DBZ
Split pdfjschildbootstrap.js to avoid sync IPC
One is always run, the other is only run when PdfJs.enabled is true in the parent process. This refactoring enables the next patch. The extensions changes are from: mozilla/pdf.js#8218 MozReview-Commit-ID: HwQ3yk8Jck4 UltraBlame original commit: 20def3cc99f49c2682bc69c53f7cac57bdfb7596
This avoids a sync IPC message from child to parent. Changes entirely from: mozilla/pdf.js#8218 MozReview-Commit-ID: 3Egayok3DBZ UltraBlame original commit: 752d857f85cd9374ea28c309b74585c2548a2d7a
One is always run, the other is only run when PdfJs.enabled is true in the parent process. This refactoring enables the next patch. The extensions changes are from: mozilla/pdf.js#8218 MozReview-Commit-ID: HwQ3yk8Jck4 UltraBlame original commit: 20def3cc99f49c2682bc69c53f7cac57bdfb7596
This avoids a sync IPC message from child to parent. Changes entirely from: mozilla/pdf.js#8218 MozReview-Commit-ID: 3Egayok3DBZ UltraBlame original commit: 752d857f85cd9374ea28c309b74585c2548a2d7a
One is always run, the other is only run when PdfJs.enabled is true in the parent process. This refactoring enables the next patch. The extensions changes are from: mozilla/pdf.js#8218 MozReview-Commit-ID: HwQ3yk8Jck4 UltraBlame original commit: 20def3cc99f49c2682bc69c53f7cac57bdfb7596
This avoids a sync IPC message from child to parent. Changes entirely from: mozilla/pdf.js#8218 MozReview-Commit-ID: 3Egayok3DBZ UltraBlame original commit: 752d857f85cd9374ea28c309b74585c2548a2d7a
See the commit messages for a more detailed explanation.
In terms of local testing, I only ran the linter but it doesn't seem like this should really affect the addon.