Chrome Browser Fails to load some converted documents

[saiena]

Some of my recently converted documents are not loading properly with the BOX Viewer.

The attached ZIP archive contains one of the problematic document sets (created through the BOX PDF-HTML5 conversion API on 2015-10-07 13:22:54).

• The crocodoc viewer starts working, but hangs after entering pageLoadLoop
• Chrome hangs waiting for the crocodoc viewer
• No errors appear in Chrome's developer console

Tested with Chrome Version 49.0.2623.87 (64-bit) on Mac OS-X 10.10.5

d4b5610b12e94daea95d5df405243897.zip

[saiena]

I just learned that the problematic documents will sometimes load if you wait 5 several minutes.

[saiena]

I also received a report that a user once saw an error that suggested that Chrome had a problem parsing font data in the CSS file. We have not seen this error.

[saiena]

We just learned of a document that does not fully load in firefox (version 33/.11 on Mac OS):
Page 20 of the attached HTML5 docset does not display.

0b93889547fa40b19437a18d13c01e8d.zip

[tonyjin]

Could you provide the original file @saiena? We're also currently seeing some issues with Chrome 49 and viewer.js that are resolved in later versions of Chrome.

[MathTV]

Attached are the PDF files from which the problematic examples were generated.
0b93889547fa40b19437a18d13c01e8d.pdf
d4b5610b12e94daea95d5df405243897.pdf

[tonyjin]

Both files work fine in Chrome Canary (51.0.2693.2) with the Crocodoc viewer. I highly suspect these files are affected by the same class of regressions we've seen with other documents on Chrome 49.

Chrome's release schedule: http://www.chromium.org/developers/calendar

[MathTV]

Thank you for the info regarding chrome!

Since we are seeing some similar issues in Firefox (and because many of our users are not able to upgrade immediately), we are interested in any temporary solution.

Is it possible (through editing of the crocodoc.viewer.js code) to prevent the viewer from rendering the layer containing html text / fonts etc (essentially, we want it to render only the SVG layer and the layer in which our plugin adds DOM elements)?

[tonyjin]

You could try setting enableTextSelection to false in Viewer Config, not sure if that's what you're referring to.

[MathTV]

Ah yes! Thank you. That looks like the solution we need for the next few weeks!

[MathTV]

Upon further testing, it appears that disabling enableTextSelection does not make a measurable difference. We have isolated the chrome compatibility problem to a problem rendering the individual SVG files.

[bpartridge]

We are also experiencing this problem. It seems to be isolated to OS X and not Windows, and the slowdown happens even when opening the SVG files themselves in a new tab. Chrome has been showing major rendering regressions in recent versions, and I don't think this will be an easy bug to fix.

[tonyjin]

@bpartridge Do you see issues with Chrome Beta or Canary? On my end, I saw most of these issues resolved with Chrome 51, which should be stable on 5/31 according to the dev calendar: https://www.chromium.org/developers/calendar

[bpartridge]

Chrome Version 52.0.2720.0 canary (64-bit) on OS X seems to have fixed it; I'll check 51 as well. Thanks for checking! Hopefully they stick to the release schedule; we'll likely disable previews in our application for Chrome versions below 51. Curious what the root cause is, but all's well that ends well I guess!