Issue with Chrome

[jonsgreen]

I am using the latest dist from master with the preloadFiles function. My use case is that I am compiling some scss with variables that change when a user selects different styles from a form. They are then able to preview how the css changes will affect their web page.

This is a rails application and I am adding the dist files in my application.js and since I am not using web workers I commented out the importScripts call in worker.js.

Everything works marvelously with Firefox. However in Chrome I get some inconsistent results. If I do a hard refresh of the page everything works. However, often when returning to the page it compiles correctly on page load but then it fails when I try to change the sass variables (note that I am doing a search and replace on the scss before compiling).

I can still read the scss files in the console using Sass.readFile but when I try in the console to compile I get:

     var css = Sass.compile('@import "base"; @import "theme"; @import "modules";')
     undefined
     css
     Object {line: 1, message: "file to import not found or unreadable: ↵Current dir:"}

Have you run into this before? I suppose it has something to do with caching.

Thanks for any advice you might have to offer.

[rodneyrehm]

please have a look at the libsass/3.2 branch

This is a rails application and I am adding the dist files in my application.js and since I am not using web workers I commented out the importScripts call in worker.js.

You really should be using the worker.

Have you run into this before? I suppose it has something to do with caching.

I have not run into anything like that before. From your explanation I don't see what would be going wrong. are you using writeFile() to change the data after your search/replace fun?

[jonsgreen]

I have not worked with web workers and from the little I have read there are complications using the Rails asset pipeline and jQuery. Here is a gist of my code: https://gist.github.com/jonsgreen/105acefdcdca325ac193.

If you have any tips on how to integrate workers or use sass.js more effectively please let me know!

[rodneyrehm]

(The following is talking about the libsass/3.2 branch, as this will be the next version soon)

I have no idea how your pipeline thingie works. The way you can use sass.js in the worker mode is rather simple:

1. make dist/sass.worker.js and dist/libsass.js.mem available somewhere (likely outside of your pipeline), e.g. example.com/sass-files/sass.worker.js and example.com/sass-files/libsass.js.mem
2. in your pipeline load dist/sass.js and execute Sass.initialize('/sass-files/sass.worker.js'); to tell Sass where to find the worker
3. call Sass.compile('your scss', function(result) { console.log('the generated css', result.text) })

---

regarding your code, I think I would not try to read/replace/write an existing file, but rather generate that file from scratch. That said, I can't see anything wrong with your way of using the sass.js file system.

[jonsgreen]

Ok. I am trying out 3.2 and using workers.

In Firefox I am getting this warning:
"SyntaxError: "use asm" is only meaningful in the Directive Prologue of a function body
...(){Dc(30);return 0}function of(){Dc(33)}"use asm";var Gn=u.Int8Array,Hn=u.Int16A..."

Not sure if that matters but when the compilation happens I am getting the following error message:
"expected a variable name (e.g. $x) or ')' for the parameter list for url". I am not sure what the problem is since before the files were being compiled without issue.

[rodneyrehm]

SyntaxError: "use asm" is only meaningful in the Directive Prologue of a function body

that's unfortunate, but not your problem. If you clone the repo, and checkout the libsass/3.2 branch, you can verify functional integrity of the build using sass.worker.html

"expected a variable name (e.g. $x) or ')' for the parameter list for url"

sounds like malformed SCSS. What's the exact input? (feel free to paste to a gist)

[jonsgreen]

Ok here is some debugging that might be helpful. I opened sass.worker.html and the test example worked fine. Here
is a simple version of my code that illustrates the problem:

Sass.preloadFiles('https://s3.amazonaws.com/action-blocks-test/1.0.1/',
      '', ['base.scss', 'theme.scss', 'modules.scss'], function() {
    Sass.readFile('theme.scss', function(scss) { console.log(scss); });
    Sass.readFile('base.scss', function(scss) { console.log(scss); });
    Sass.readFile('modules.scss', function(scss) { console.log(scss); });
    Sass.compile('@import "base"; @import "theme"; @import "modules";', function(css) {
       console.log(css.text);
       console.log(css.message);
    })
});

The console results were again:

expected a variable name (e.g. $x) or ')' for the parameter list for url

That got me thinking that maybe it was having problems with the comments so I removed those from a few of the files and it did seem to maybe get a bit further:

Sass.preloadFiles('https://s3.amazonaws.com/action-blocks-test/vtest/',
      '', ['base.scss', 'theme.scss'], function() {
    Sass.readFile('theme.scss', function(scss) { console.log(scss); });
    Sass.readFile('base.scss', function(scss) { console.log(scss); });
    Sass.compile('@import "base"; @import "theme";', function(css) {
       console.log(css.text);
       console.log(css.message);
    })
});

That yielded:

Undefined variable: "$spacing-base"

Which seems strange since that is defined and there are plenty other variables in there that are also defined that it doesn't complain about.

Please note that I have no trouble compiling the very same files with almost identical code using the master branch though doing it without the worker.

Also I should note that in Chrome the test example code for the sass.worker.html page bombed for me in the console with:

Uncaught TypeError: Cannot read property 'postMessage' of nullmessage: "Cannot read property 'postMessage' of null"stack: (...)get stack: function () { [native code] }set stack: function () { [native code] }__proto__: ErrorSass._dispatch @ sass.js:44Sass.(anonymous function) @ sass.js:108(anonymous function) @ VM59:2InjectedScript._evaluateOn @ VM41:883InjectedScript._evaluateAndWrap @ VM41:816InjectedScript.evaluate @ VM41:682

Thanks for exploring this with me and I hope this is somehow helping you with your next release.

[rodneyrehm]

try using console.log(css); to get a bit more iinfo about your error (e.g. file and line).

---

expected a variable name (e.g. $x) or ')' for the parameter list for url

there is a BLOB in module.scss, that seems to be causing the problem:

// line 378
src: url(data:application/x-font-ttf;......)

adding quotes to the DataURIs solved that problem

// line 378
src: url("data:application/x-font-ttf;......")

Undefined variable: "$spacing-base"

it is used in base.scss, but declared in theme.scss. Since your import order is base, theme - the variable has simply not been defined yet. Additionally the theme.scss requires the variable $use-theme to be set. Fixing your compile call and it works:

Sass.compile('$use-theme:true; $spacing-base: 123px; @import "base"; @import "theme";', function(css) {
  console.log(css);
});

Uncaught TypeError: Cannot read property 'postMessage'…

It doesn't do that for me with your example code. How did you get there?

---

After fixing your SCSS issues, I get an output:

function fixDataURI(callback) {
  Sass.readFile('modules.scss', function(scss) {
    scss = scss.replace(/url\(data([^\)]+)\)/g, 'url("data\1")');
    Sass.writeFile('modules.scss', scss, callback);
  });
}

Sass.preloadFiles(
  'https://s3.amazonaws.com/action-blocks-test/1.0.1/', '',
  ['base.scss', 'theme.scss', 'modules.scss'], function() {
  fixDataURI(function() {
    Sass.compile('$use-theme:true; $spacing-base: 123px; @import "base"; @import "theme"; @import "modules";', function(css) {
      console.log(css);
    })
  })
});

[jonsgreen]

Thank you so much for all your help and patience with this. It seems so far that this has mostly been my own bugs and misuse of the API.

I think I am getting closer. I can get the sass to compile but I am getting different results than I was when using the master branch. Here is what I have been getting from master branch: https://gist.github.com/jonsgreen/9b4352fa8ee744c6a856. Here is what I get from the libsass3.2 branch: https://gist.github.com/jonsgreen/f007401b686d41daa91d. It seems like somehow the zeroes are not getting lost somehow in the compilation?

[rodneyrehm]

Upon examining the diff I assume you're using different input files - or libsass itself is having a weird problem in 3.2.0-beta.5

3.2.0-beta.6 is out and I'll try to compile it tonight.

meanwhile please try to produce a minimal test case for this problem.

[jonsgreen]

I believe that if you use your test code above with worker.html on master and compare with sass.worker.html on libsass3.2 branch you will get the same diff.

You are probably right that the problem is in libsass; hopefully it is resolved with latest beta.

[rodneyrehm]

I believe that if you use your test code above with worker.html on master and compare with sass.worker.html on libsass3.2 branch you will get the same diff.

yeah, but that's not a minimal test-case…

You are probably right that the problem is in libsass; hopefully it is resolved with latest beta.

I still need a minimal test case to figure that out…

[jonsgreen]

Gotcha. How about this?

Sass.writeFile('test.scss', 'div {line-height: 20px;}', function() {
  Sass.compile('@import "test";', function(css) {
    console.log(css.text);
  });
});

I get 20px compiled into 2px

[rodneyrehm]

hehe, that's what I'd call the minimalist minimal test case :D

I'll have a look later

[rodneyrehm]

I just compiled the few hours old, official release of libsass 3.2 and can happily report the problem to be gone :)

[jonsgreen]

Great! Just let me know when you have pushed it to the branch and I will try it out on my code.

[rodneyrehm]

I've actually just released v0.7.0 :)

[jonsgreen]

We are definitely closer but try this one out:

Sass.writeFile('test.scss','$line-height: 20px; div {line-height: $line-height;}', function() {
  Sass.compile('@import "test";', function(css) {
    console.log(css.text);
  });
});

I am still getting 2px when using variables like that. Let me know if you want me to file a bug with libsass.

[rodneyrehm]

Just to confirm it's got nothing to do with the file system stuff, the following produces the same output

Sass.compile('$line-height: 20px; div {line-height: $line-height;}', function(css) {
  console.log(css.text);
});

btw, I see the same result for 0.1px, 210px.

---

I've tried reproducing the issue with node-sass using libsass 3.2.0-beta.6 (npm install node-sass@beta), but I'm getting the expected result of 20px:

var sass = require('node-sass');

sass.render({
  data: '$line-height: 20px; div {line-height: $line-height;}',
}, function(error, result) {
  if (error) {
    console.log(error.status); // used to be "code" in v2x and below
    console.log(error.column);
    console.log(error.message);
    console.log(error.line);
  } else {
    console.log(result.css.toString());
  }
});

---

To sass.js the content that's being compiled is opaque. It's a string. it doesn't do anything with it. I have no idea where that 0 is getting lost…

Currently building the latest emscripten version to see if that does anything. If it's not that, my next bet would be on sass_compile_data_context() (libsass C-API) behaving differently than the API node-sass is using…

[rodneyrehm]

I've tracked down the root of the problem to precision being the problem: sass/libsass#1140. You can work around the problem by setting the precision first:

Sass.options({ precision: 5 });
Sass.compile('$line-height: 20px; div {line-height: $line-height;}', function(css) {
  console.log(css.text);
});

I'm not sure if this is an issue with libsass, or if sass.js simply needs to update the initial default value for the precision option.

---

For the record: I've tracked this down by creating a small C programm:

#include <stdio.h>
#include <cstdlib>
#include <cstring>
#include "sass_context.h"

int main() {
  char *source_string = strdup("$line-height: 20px; div {line-height: $line-height;}");

  printf("compiling \n%s\n", source_string);

  struct Sass_Data_Context* data_ctx = sass_make_data_context(source_string);
  struct Sass_Context* ctx = sass_data_context_get_context(data_ctx);
  struct Sass_Options* ctx_opt = sass_context_get_options(ctx);

  // configure context
  sass_option_set_precision(ctx_opt, 16);

  int status = sass_compile_data_context(data_ctx);

  if (status == 0) {
    printf("result: \n%s\n", sass_context_get_output_string(ctx));
  } else {
    printf("error: \n%s\n", sass_context_get_error_message(ctx));
  }

  return status;
}

# prepare libsass
git clone https://github.com/sass/libsass.git libsass
cd libsass
git checkout 3.2.0 && git submodule init && git submodule update
make install-shared

# build and run the demo
gcc -Wall mini.cpp -lsass -o mini && ./mini

(no, this is not relevant to anyone. only to me, should I need to do something similar again)

[jonsgreen]

Once again I am grateful for your help. Everything seems to be working as expected.

I hope you got something out of this as well!

[rodneyrehm]

The problem with precision has been resolved in v0.7.2