1743585 - Can not open PDF in external viewer while writing a message

Status: RESOLVED DUPLICATE of bug 1698140

(Thunderbird :: Preferences, defect)

Description

[jock]

Attachment: Capture1.JPG

User Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:94.0) Gecko/20100101 Firefox/94.0

Steps to reproduce:

Open Write mode for a new Email

Attach a PDF file

Open this PDF files on Thunderbird

Actual results:

Thunderbird can not open this PDF files

I change pdfjs.disable false to true

And I can open the PDF files in write mode.

Expected results:

Open the PDF File

Comment 1

[Lars T Hansen [:lth]]

Attachment: WIP: Bug 1743585 - Table optimization patch from bug 1642412 - DO NOT LAND

Rollup for Ryan's pending work, DO NOT LAND

Depends on D132296

Comment 2

[Lars T Hansen [:lth]]

Attachment: WIP: Bug 1743585 - Change table-of-funcref representation and call-indirect code

Remove the FunctionTableElem struct entirely and replace the
"functions_" array of these structs in the Table with two arrays
"codeptrs_" and "tlsptrs_" that are independently allocated.

The purpose of the change is to enable the call-indirect sequence to
always directly load the code pointer from the table with a BaseIndex
scale-by-pointer on every platform, tightening that code sequence
considerably on all platforms, albeit in slightly different ways.

The change sets us up for at least two future optimizations:

• Calls to constant indices can be optimized further on all platforms
  since the table offset can be precomputed
• Once the null check in the call-indirect sequence is removed,
  the code pointer load can be further folded into the call instruction
  on x86/x64.

Depends on D133475

Comment 3

[Lars T Hansen [:lth]]

Attachment: WIP: Bug 1743585 - Fuse the load and call on x64 + notes (WIP)

This fuses the code pointer load into the call instruction on x64,
which we can do because we have a BaseIndex form of the call.
Performance-wise this does not move the needle on my x64 Xeon system,
though it probably makes the code slightly denser.

Added some notes about what we can do if the index is constant - we
don't need to load it into the index register, and slightly denser
code can be generated for the load + call - but before I go further in
that direction I want to do a corpus analysis of actual wasm code to
see how common this case is. (This also plays into bound check
frequency and BCE strategies.)

Depends on D133476

Comment 4

[Phabricator Automation]

Comment on attachment 9254728 [details]
WIP: Bug 1743585 - Table optimization patch from bug 1642412 - DO NOT LAND

Revision D133475 was moved to bug 1743586. Setting attachment 9254728 [details] to obsolete.

Comment 5

[Phabricator Automation]

Comment on attachment 9254729 [details]
WIP: Bug 1743585 - Change table-of-funcref representation and call-indirect code

Revision D133476 was moved to bug 1743586. Setting attachment 9254729 [details] to obsolete.

Comment 6

[Phabricator Automation]

Comment on attachment 9254731 [details]
WIP: Bug 1743585 - Fuse the load and call on x64 + notes (WIP)

Revision D133477 was moved to bug 1743586. Setting attachment 9254731 [details] to obsolete.

Comment 7

[Thomas D. (:thomas8)]

Thank you jock for reporting this, already on record.
Meanwhile, you could try the workaround along bug 1698140 comment 8.