Closed Bug 1097164 Opened 10 years ago Closed 8 years ago

e10s - Built in PDF viewer - download button doesn't work in version 36


(Firefox :: PDF Viewer, defect, P2)

36 Branch



Tracking Status
e10s + ---


(Reporter: p_mccarthy, Unassigned)



(Whiteboard: [pdfjs-c-integration])


(1 obsolete file)

User Agent: Mozilla/5.0 (Windows NT 5.2; Win64; x64; rv:36.0) Gecko/20100101 Firefox/36.0
Build ID: 20141111030203

Steps to reproduce:

download button should invoke adobe acrobat or acrobat viewer

Actual results:

bar claims acrobat viewer isn't installed

Expected results:

should have invoked existing acrobat or acrobat viewer
If you go into the preferences, on the general tab, is e10s enabled? If it is, does this work correctly with e10s disabled?

If that isn't the issue, can you try to find a regression window using mozregression? ( )
Flags: needinfo?(p_mccarthy)
Component: Untriaged → PDF Viewer
Everything works if I disable e10s
Flags: needinfo?(p_mccarthy)
Blocks: e10s
tracking-e10s: --- → ?
Summary: Built in PDF viewer - download button doesn't work in version 36 → e10s - Built in PDF viewer - download button doesn't work in version 36
Blocks: e10s-addons
No longer blocks: e10s
The download button seems to work fine, do you mean the "Open with a different viewer" button?
Flags: needinfo?(p_mccarthy)
OS: Windows Server 2003 → All
Priority: -- → P2
Hardware: x86 → All
Whiteboard: [pdfjs-c-integration]
We see in the browser cosole: "NS_ERROR_NOT_AVAILABLE: Async version must be used". It's probably related.
I can reproduce this bug with Nightly 36. Firefox auto-downloads PDF links instead of displaying them with the built-in PDF Viewer:
Ever confirmed: true
I am using PDF Viewer 1.0.277.
Flags: needinfo?(p_mccarthy)
The add-on at amo is not e10s compatible -- please uninstall
Are there plans to update the AMO version?
(In reply to Jorge Villalobos [:jorgev] from comment #8)
> Are there plans to update the AMO version?

Updating of the AMO extension is not a priority, and we are trying to eventually disable it. It adds burden of supporting out-of-date inefficient APIs in the chrome code (recent example bug 1069953)

Please notice that the comments 5-8 are not related to the main issue (see STR in comment 0) and shall be placed in a new bug related to pdf.js AMO extension, and not built-in PDF Viewer.
What would be the use case of keeping the AMO extension instead of just using the built in replacement?
See Also: → 1165558
I just tested with a random pdf[1] I found and this works fine. Tested on:
* 46.0a2 (2016-03-07), Linux Ubuntu
* 47.0a2 (2016-03-11), OS X 10.11.3

It's probably save to mark this as resolved.

(In reply to Arash from comment #11)
> It's probably save to mark this as resolved.

This is *not* fixed, since the problem, as mentioned in comment 3, still exists.
The "Open With Different Viewer" button on the Fallback bar still doesn't work with e10s *enabled*, and it fails with (in the Browser Console):
> TypeError: frontWindow is null

The error originates here:

Note: For testing, the Fallback bar can be triggered manually for any PDF document. After opening a PDF document, press <Ctrl>+<Shift>+<K> and run the following in the console:
> PDFViewerApplication.fallback()
This will display the Fallback bar, and clicking on its button fails in e10s.
Comment on attachment 8734120 [details] [diff] [review]
Allow nsIDOMWindow as aContentContext the nsExternalHelperAppService::DoContent.

Bad solution due to bug 1241764
Attachment #8734120 - Attachment is obsolete: true
Closed: 8 years ago
Resolution: --- → DUPLICATE
You need to log in before you can comment on or make changes to this bug.