Skip to:

  1. Skip to Jira Navigation
  2. Skip to Side Navigation
  3. Skip to Main Content

TypeError in cljs.core/str using Safari 6.0.5

Description

In some versions of Safari 6 (at least 6.0.4 and 6.0.5) calls to cljs.core/str may throw a very cryptic Type Error: type error. This error has occurred repeatedly in our production cljs app over the last ~3 months but I have not been able to reproduce it locally, or boil it down to a simple test case. This appears to be due to the nature of the bug itself. I was however, able to workaround the issue by patching cljs.core/str to use the '' + x form of coercion instead of calling x.toString directly.

Other js projects have encountered this issue and adopted the same solution:

This shouldn't hurt performance and might actually improve it in some browsers:

I'll submit the patch we are using shortly.

Environment

None

Attachments

1
  • 29 Aug 2014, 11:36 PM

Activity

Francis Avila 
February 3, 2015 at 4:04 PM

I'm not 100% sure either that BrowserStack's code injection magic doesn't somehow mitigate this bug. However, based on the jsperfs I have been running inside it I am sure that it does not disable the higher code optimization levels where this bug would manifest. (This is why console.log calls and opening the developer console mask the bug: both disable code optimization, and this is a bug that only manifests at higher optimization levels.)

So it is at least possible that BrowserStack's Safari 6.0.5 would be able to trigger this bug, or rather I have not seen anything about it yet that absolutely precludes triggering the bug.

Kevin Neaton 
February 3, 2015 at 3:29 PM

I have had no luck reproducing this bug in Safari 6.0.5 on BrowserStack. Others have reported elsewhere that simply logging a message to the console may mask the bug. That said, I am not confident that it is possible to reproduce this bug using BrowserStack.

Francis Avila 
January 20, 2015 at 5:35 AM

Kevin Neaton 
January 19, 2015 at 11:05 PM

Here are the compiler settings from the build that produced the error:

{:output-to "target/main.js" :output-dir "target/main" :optimizations :advanced :output-wrapper true :pretty-print false :preamble ["react/react_with_addons.min.js"] :externs ["react/react_with_addons.js"] :closure-warnings {:externs-validation :off :non-standard-jsdoc :off}}

I had no luck reproducing the issue previously, but I'll take another stab at it later this week and report back here.

Francis Avila 
January 19, 2015 at 3:18 PM

I can talk to my boss about deploying an alternate patch to a subset of our users, but it might be a tough sell. Is that what you had in mind?

We really need to see this bug in a controlled environment. Deploying a test on the open internet and waiting for stacktraces is not a definitive confirmation of a fix. (How many Safari 6.0.x users do you get anyway? They should be very rare.)

If there is a url in your app that you know raises TypeError, this would be the best way to go (and would not require changing your production code):

  1. With app built with unpatched cljs 0.0.2202: hit page with Safari 6.0.5, confirm TypeError.

  2. With your production code (patched cljs 0.0.2202): hit page with Safari 6.0.5, confirm no TypeError.

  3. With some other patch: confirm no TypeError.

BrowserStack is the only browser testing platform I could find which has Safari 6.0.5, and as I said I could not reproduce the error using it.

One more question: what were your cljs compilation settings?

Completed

Details

Assignee

Reporter

Priority

Created August 29, 2014 at 11:27 PM
Updated February 3, 2015 at 4:04 PM
Resolved February 3, 2015 at 4:04 PM

Flag notifications