Issue 837076  has been merged into this issue.

 Issue 837064  has been merged into this issue.

Able to reproduce the issue on reported version 66.0.3359.117 & on latest chrome 68.0.3406.0 using Ubuntu 14.04, Windows 10 and Mac OS 10.13. 

Below is the Bisect Info:
================
Good build: 65.0.3302.0
Bad build: 65.0.3303.0

You are probably looking for a change made after 526111 (known good), but no later than 526112 (first known bad).

CHANGELOG URL:
https://chromium.googlesource.com/chromium/src/+log/35cc2b256f2598350915742eefcc505ab902b636..1508f4a32a3fb19d6e3599acc0bcc817ebe6c5be

suspect: https://chromium.googlesource.com/chromium/src/+/1508f4a32a3fb19d6e3599acc0bcc817ebe6c5be

@erikchen: Please confirm the issue and help in re-assigning if it is not related to your change.

Thanks!

Since this is a recent regression and also have a clear suspect. Please have a fix during M68 time frame.

When I run this on a local build of Chromium, I get:

"""
Received command DeleteDocument with callbackId 20
terminating with uncaught exception of type N7pdftron6Common9ExceptionE: Exception: 
	 Message: GetDocReference: Document id could not be found
	 Conditional expression: found != m_download_data.end()
	 Version    : 6.8.0.0N
	 Filename   : PNaClWorker.cpp
	 Function   : GetDocReference
	 Linenumber : 1586
"""

This seems like a bug in the PNaCl app rather than chrome?

Is there a reason that this worked fine in every version before Chrome 65? I'm assuming that you are not able to reproduce that error in Chrome 64 for example? The error in the app may be a symptom of the root cause in Chrome.

> The error in the app may be a symptom of the root cause in Chrome.

The app was depending on Chrome implementation details, which changed between Chrome64 and Chrome 65.

Is it possible to elaborate a bit on the implementation details that it was depending on? Is there a workaround that we can apply on our end?

Without knowing more about your app, it's hard to tell exactly what's going wrong.

There's a function called GetDocReference at PNaClWorker.cpp:1586 that is hitting an assertion. 

If I had to throw out a wild guess:

Chrome changed in M65 to no longer make layout objects for children of display:none iframes. "Toggle Visibility" sets display:none on the iframe in question, causing all layout objects to be destroyed. The app is somehow relying on metadata associated with one of those layout objects even in the display:none state, thus hitting the assertion.

I created an updated simpler sample at http://pdftron.s3.amazonaws.com/downloads/webviewer/test/samples/simple/index.html

It sends messages to the worker and the worker returns the last message that was sent. After a timeout it sends another message. I've attached the cpp file.

If you don't toggle the visibility before the timeout then it will send back "I" as expected. If you do toggle visibility it doesn't crash but it also doesn't return the previously stored message, so it seems like all of the memory is wiped out? Is this the expected behavior?

I suspect this is what's happening in the more complicated worker as it's attempting to access its memory as normal, it's not expecting the memory to suddenly be cleared.

Deleted: SimpleWorker.cpp 997 bytes

SimpleWorker.cpp 997 bytes View Download

> If you don't toggle the visibility before the timeout then it will send back "I" as expected. If you do toggle visibility it doesn't crash but it also doesn't return the previously stored message, so it seems like all of the memory is wiped out? Is this the expected behavior?

Yes, that is expected.

When you mark the iframe as display:none, many of the associated resources are released. In this case, that includes the pnacl module. 

erikchen: Are there any more actions required here from our side?

No, closing.