Hacker News Reader

Comment by bstar77 | Hacker News Reader

Nice, but this constantly crashes Safari when the content goes below the fold. The whole page goes white and then the browser dies.

View on HN

Sad to hear that. I don't use Safari, but maybe it cannot compete with the JS engines of Firefox and Chrome's version of the Webkit engine.

This script reqiures a lot of computation in JS and communication between the website and the webworker (~300kb). Maybe Safari is unable to cope with this in a decent amount of time.

I've seen emscripten-generated JS crash Safari before. It's not a performance issue; jsc is plenty fast and beats SpiderMonkey in most benchmarks. However, emscripten seems to exercise certain corners of JS that pose stability problems for jsc.

Anyone want to test a webkit nightly? I don't have a desktop machine handy tight now to test on :(

Or even just a bug report at bugs.webkit.org

Thanks :)

Just tried it, crashes in the exact same way:

1. Hitting "Compile" does whatever it should do successfully. 2. Then hitting "Open PDF" opens a new tab which stalls out and crashes

I would almost say its actually a PDF thing that is crashing Safari vs a JS thing.

At least, that's what has happened consistently on my machine with latest Safari and WebKit nightly.

Edit: However, taking the generated PDF from Chrome and dropping it into Safari loads it fine, so maybe it is a JS thing.

Edit 2: Upon further inspection it appears the new tab is being opened with just a data URL representing the entire PDF. It wouldn't surprise me if that's the problem (Safari not being able to handle huge data as a URL). I recall running into a similar crash in MobileSafari because of that a while ago.

Yup, that is for sure it. I took the Chrome generated PDF, turned it into a data URL, then copy-pasted the data URL into Safari's URL bar. Crash.

Drag and dropping the file itself into Safari, works fine.

Please file a bug, so they can fix it.

Nice debugging, not a fan of making blanket assumptions when something isn't working as expected.

Which benchmarks are you looking at? And are they actually JSC vs SpiderMonkey or JSC+WebKit vs SpiderMonkey+Gecko? I.e. are they JS benchmarks or DOM benchmarks?

"Beats" might be too strong a word :). I guess the picture from AWFY 64-bit is that both have strengths and weaknesses but overall they're comparable.

Yeah, on that set of benchmarks (the one that everyone is targeting hence not doing anything obviously stupid on), they are.

The problem is that all of the JS engines involved have various failure modes in which they end up way slower than the others, though... We're talking 10x-1000x slower. And the problem with performance is it only takes your script hitting one serious performance bottleneck to make the speed of the rest of it not really matter. :(

Hence my interest in testcases that point out such performance cliffs, so they can be removed.

It crashes my Opera also. And this is a funny comment, Safari actually beats Firefox in most tests.

Strange, seems to work fine on iOS.

Reply on news.ycombinator.com