Avoid triggering plugin list initialization on startup

RESOLVED FIXED

Status

()

Firefox
PDF Viewer
RESOLVED FIXED
4 years ago
4 years ago

People

(Reporter: vladan, Assigned: vladan)

Tracking

(Blocks: 1 bug)

Firefox Tracking Flags

(Not tracked)

Details

(Whiteboard: [pdfjs-c-integration])

Attachments

(1 attachment)

(Assignee)

Description

4 years ago
Pdf.js requests the list of enabled plugins during its initialization which  causes nsPluginHost to stat plugin directories & plugin libraries. This is main-thread I/O which delays startup by roughly 100 ms in my setup.

This patch changes the pdf.js initialization logic to first check if pdf handling by plugins is disabled in prefs before requesting the list of enabled plugins. Pdf.js already disables the pdf plugin via prefs during Firefox migration, so we'll practically never need to consult the list of enabled plugins.
(Assignee)

Comment 1

4 years ago
Created attachment 760678 [details] [diff] [review]
Change order of pdf plugin checks
Attachment #760678 - Flags: review?(bdahl)
(Assignee)

Updated

4 years ago
Assignee: nobody → vdjeric
(Assignee)

Comment 2

4 years ago
https://tbpl.mozilla.org/?tree=Try&rev=2af459dbc000
(Assignee)

Updated

4 years ago
Duplicate of this bug: 880300
Comment on attachment 760678 [details] [diff] [review]
Change order of pdf plugin checks

Review of attachment 760678 [details] [diff] [review]:
-----------------------------------------------------------------

::: browser/extensions/pdfjs/content/PdfJs.jsm
@@ +204,5 @@
>      }
>  
> +    // Check if have disabled plugin handling of 'application/pdf' in prefs
> +    if (Services.prefs.prefHasUserValue(PREF_DISABLED_PLUGIN_TYPES)) {
> +      var disabledPluginTypes =

s/var/let/
Comment on attachment 760678 [details] [diff] [review]
Change order of pdf plugin checks

Review of attachment 760678 [details] [diff] [review]:
-----------------------------------------------------------------

If you're comfortable with github it'd be best to do a pull request against https://github.com/mozilla/pdf.js/blob/master/extensions/firefox/content/PdfJs.jsm . If not I can land the changes upstream in pdf.js.
Attachment #760678 - Flags: review?(bdahl) → review+
(Assignee)

Comment 6

4 years ago
I submitted the pull request: https://github.com/mozilla/pdf.js/pull/3366

I don't need to land on mozilla-inbound, right?
(In reply to Vladan Djeric (:vladan) from comment #6)
> I submitted the pull request: https://github.com/mozilla/pdf.js/pull/3366
> 
> I don't need to land on mozilla-inbound, right?

No - there are periodic pulls of the latest pdf.js into mozilla-inbound :-)

Updated

4 years ago
Whiteboard: [pdfjs-c-integration]
Depends on: 888635
(Assignee)

Comment 8

4 years ago
This was merged with bug 888635. It looks like there was a 2-3% Talos startup improvement on Ubuntu & Mac :)


Improvement: Mozilla-Inbound-Non-PGO - Ts, Paint - Ubuntu HW 12.04 - 2.93% decrease
-----------------------------------------------------------------------------------
    Previous: avg 693.789 stddev 3.600 of 12 runs up to revision 87b5a0591aff
    New     : avg 673.456 stddev 6.887 of 12 runs since revision b4b9098538cb
    Change  : -20.333 (2.93% / z=5.648)
    Graph   : http://mzl.la/12AlyVJ

Changeset range: http://hg.mozilla.org/integration/mozilla-inbound/pushloghtml?fromchange=87b5a0591aff&tochange=b4b9098538cb
Status: NEW → RESOLVED
Last Resolved: 4 years ago
Resolution: --- → FIXED
You need to log in before you can comment on or make changes to this bug.