HTTP Web Server configuration

[Christopher Froehlich]

I've pulled the latest source from bitbucket and loaded Tincr as an unpacked extension (I've also tried using the latest version in the Chrome store). I have a very thin HTML page with a single JS include. The HTML page has a button. The JS fetches the button from the DOM and binds a click event which issues an alert('a mutating string').

When I load the HTML page from the file system, I see changes to the JS file in the Sources tab in real time--and my click event is changing dynamically (without a page refresh) as I change the file. All expected.

However, when I try to use HTTP Web Server config option, I get this error in the console:

Content for url http://localhost/test.js matches local file C:\test\test.js

1. Content for url http://localhost/test.js doesn't match local file C:\test\test.js
1. (anonymous function)
2. InjectedScript._evaluateOn
3. InjectedScript._evaluateAndWrap
4. InjectedScript.evaluate

My content is no longer updating. Initially, I had my test.html and test.js content hosted at "localhost/test/test.html" (physically located at c:\test); however, I noticed (by inspecting Tincr and debugging) that the URL parameter passed in was simply "localhost" which could not resolve "test.html". So I moved my test files to the root of my web site, now just "localhost/test.html", but I get the same behavior.

I see this thread started at the original group, but it doesn't resolve the issue.

Any thoughts? I'm on Windows 7x64 using IIS for my webserver and testing in Chrome Canary and Chrome Dev.

[Ryan Ackley]

So live reload isn't working? When you update the file in the
filesystem, it's not changing in devtools or is it vice-versa?

The error message means that Tincr is matching up the file and url
correctly but the contents are different. Is it possible that test.js
is being cached? Can you try going into devtools settings and tick the
Disable Cache checkbox. You can access the devtools settings by
opening the devtools and clicking the gear icon in the lower left
corner.

> --
>
>

[Christopher Froehlich]

Right. To clarify, I'm updating the JS using an external editor (Sublime). If I make and save the edit in Sublime (using the HTTP Web Server config), the change is not replicated in either the Sources or the Resources panel of Inspector. Likewise, if I edit the file inside Chrome in Sources, the change is not replicated to Sublime (unless I use the "Save As" option to explicitly map the file).

I always run with cache disabled when testing, but I double checked--it is disabled.

Live reload works perfectly when using the "file:///C:/test/test.html" as the URL. Of course, I'd rather not have to refactor my actual app to handle cross-domain ajax requests (and remap the pathing for requests) from file:// to http://localhost--so getting the HTTP Web Server config to work would be ideal.

[Gabriel]

Chris, 

Could you post the config file you had used with your tincr?

Thanks

-Gabe

[Christopher Froehlich]

Wacky, I just replied with a screenshot and attachments, but that reply now appears as "This message has been deleted.". So here goes again:

Gabe,

I've attached my two test files, and I'm attaching the screenshot of my config. I don't have an actual config file (tincr.config), because I'm using the HTTP Web Server config option (assuming that none of the predefined configs require additional config files).

-Christopher

[Gabriel]

OK. I see now that I was misreading your email. I'm not using this kind of project type. I've used "Configuration File" instead to have greater control. 

I've created a tincr.json file, put it in the root of my web directory and put the follow content:

{ 

"toFile" : [

{"from": "/my_virtual_root_directory_name/subdir1/subdir2/scripts/j(.+\\.js)",

"to": "C:\\physical_dir\\subdir1\\subdir2\\scripts\\$1"}

],

"fromFile" : [

{"from": "C:\\\\physical_dir\\\\subdir1\\\\subdir2\\\\scripts\\\\(.+\\.js)",

"to": "/my_virtual_root_directory_name/subdir1/subdir2/scripts/$1"}

]

}

This works well when changing the file outside of chrome and having int propagating to the devtools. 

I still couldn't achieve the opposite - change and save in Chrome editor and have it propagate back to the local file system.

Maybe Ryan can chime in an give us a sample how to properly configure this on windows.

Cheers

-Gabe

[Christopher Froehlich]

I started with the Configuration File approach, but I can't seem to get the regex right. I adapted your JSON to my test site (http://localhost/test) [physical contents at c:\test: test.html and test.js]:

{ 

"toFile" : [

{"from": "/test/(.+\\.js)",

"to": "C:\\test\\$1"}

],

"fromFile" : [

{"from": "C:\\\\test\\\\(.+\\.js)",

"to": "/test/$1"}

]

}

With Enable Logging checked, I don't see any output in the console. Maybe it's a simple mistake in my regex? 

Likewise, I really only care about the external edit > Chrome reload as I do all of my editing in either Sublime or VS.

[Ryan Ackley]

I just tested this on my Windows machine at home. It seems to work.

I had a directory C:\projects\test. It has a test.html at the root. There is a subdirectory called static. It has 2 files: site.css and site.js. 

I uninstalled the Tincr version I have installed. I then checked out the latest source from bitbucket. I loaded this in Chrome as an unpacked extension.

I started an http server with c:\projects\test as the docroot using python. "python -m SimpleHTTPServer". I opened http://localhost:8000 and then opened the devtools. I went to the devtools panel, I selected "Http Web Server" from the dropdown. I then clicked browse and selected C:\projects\test for the base directory.

live reload worked for both "static/site.css" and "static/site.js". 

Looking at the steps I've listed, do you diverge from those at any point? It may be a bug that is exposed by the workflow you're following. 

Also, I tested this on Chrome Stable on Windows. I'll test it later on Canary. 

--
 
 

[Christopher Froehlich]

As far as I can tell, there are only 3 differences in my approach:

1. I have a single directory (c:\test) with two files (c:\test\test.html and c:\test\test.js). I do not have a subfolder for the JS file. I will try nesting the JS file one level deeper than the root.
2. I'm using IIS. When I get into the office tomorrow, I'll import my test files into grunt and start a node server at port 8000.
3. The only other difference would be the build of Chrome. I'll downgrade my Chrome Dev instance to Stable and try again.

[Ryan Ackley]

Hi Christopher,

I just tried Canary and it works. I'll try putting the resources at the root and see what happens. I'll also try setting up IIS locally.

-Ryan

--
 
 

[Christopher Froehlich]

Ryan,

I'm stumped. I moved my JS resource down into a 'static' folder, but no dice. I nuked my Chrome Dev installation and installed a fresh Chrome stable. Cache is disabled, and the only extension loaded is Tincr (loading unpacked with latest source). Caching is explicitly disabled at the IIS level. Reload is sadly unresponsive to file changes.

Could you post your test files? If reload doesn't work on that as a target, there must be something in my environment that is different from yours?

-Christopher

[Christopher Froehlich]

Maybe it is an IIS thing. When I open the inspector on Tincr, I now see some meaningful errors:

• In the console:
  1. GET http://localhost/static/test.js?r=1559696 406 (Not Acceptable) zepto1.0rc1.js:2
  1. $.ajaxzepto1.0rc1.js:2
  2. (anonymous function)FileWatcher.js:55
  3. Array.asyncEachfile_utils.js:41
  4. FileWatcher.fileChangedFileWatcher.js:41
  1. XHR finished loading: "http://localhost/static/test.js?r=1559696"
• From IIS: 

  HTTP Error 406.0 - Not Acceptable

  The resource cannot be displayed because the file extension is not being accepted by your browser.

  
  

I'll see if I can muck about with MIME types and fix this error.

[Christopher Froehlich]

Ryan,

This may not be the right solution, but this if I remove line 57 of FileUrlProject.js (dataType: 'text'), Tincr begins working right away. I think the problem is that when zepto receives a datatype of 'text', it incorrectly scopes the Accept Headers of the request.

You're also not trapping on ajax error or ajax complete, and the console output you see in inspecting Tincr is not euphemized and communicated back to Chrome proper. 

-Christopher

[Ryan Ackley]

I can't think of any drawbacks to your approach. If you want to create pull request or a patch, I'll incorporate your changes into Tincr.

--
 
 

[Christopher Froehlich]

Ok. I've never used git or bitbucket, but I gather that it's semantically similar to mercurial. I'll take a whack at submitting a patch.

[Christopher Froehlich]

That was a journey. Following bitbucket's instructions, I couldn't get a functional repo using Mercurial--so I dived into Git. 

The patch itself is trivial. I took a stab at the 2 other issues: a.) communicating ajax failure messages across the extension divide and b.) accommodating URLs more complex than root + resource. 

In the case of a.), there is some black box behavior that I don't understand with Chrome extensions. I see your call to logMessage in ResourceChecker.js, but I'm unable to locate it in the Dev Tools, nor can I break on it. While I can instrument the ajax error method with more expressive content, it gets translated down to "Auto-Reloaded http://localhost/static/test.js" (which obfuscates the actual error). 

In the case of b.) live reload works great when I position my content at the root: http://localhost/test.html; however, when I reposition it at http://localhost/test/test.html, line 36 of FileWatcher.js (var urls = this.project.urlsForFilePath(path)) resolves to null, as the path cannot be fetched from the urls array. Again, I can't find a way to instrument the extension for debugging.

At any rate, with the dataType fix I can at least work around the other issues.

[Ryan Ackley]

Thanks for submitting a pull request! I got the notification. Can't wait to check it out when I get home from work a little later. 

I'm curious about your problem now with subdirectories. If you notice my previous post, I was able to get it working with a subdirectory under the root. I wonder if it's IIS specific. 

Debugging is a little tricky. Let me see if I can break it down for you. There are 3 distinct components,

1.  The Tincr panel in the devtools, this handles configuration and interacting with the devtools. This handles the logic of updating the scripts and stylesheets in the browser and listening for when someone edits something in devtools.
2.  The background page, this handles the logic of when and where to do native file operations. This is where the logic of the configuration you choose in the Tincr devtools panel actually happens. 
3. NPAPI File API. This is the native (C++) dll that actually reads and writes files from your local filesystem. It talks exclusively to the background page. 

To debug #1, you will need to debug the devtools. You can do this by opening the devtools from inside the devtools. On Mac OS X, I do this by either hitting CMD+SHIFT+I (maybe ctrl+shift+I for Windows) or going to View->Developer Tools. 

To debug #2, you can inspect the background page from the extensions panel if you have developer mode turned on. 

To debug #3, you will need Visual Studio (C++). You probably don't want to worry about this piece. 

One problem you may be running into is that the background page and devtools panel run in separate processes. Therefore, to follow the complete code path, you would need to have 2 debuggers open. The background page and devtools panel communicate in a way similar to ajax requests. I didn't choose to implement it this way. This is a result of the security restrictions of the Chrome platform. 

While debugging, you should be able to "Step Into" a function call to follow the code path across multiple files.  The only times you should be running into a black box situation is where it makes calls to the NPAPI dll. These calls are easily recognizable because they are all made on the "nativeFileSupport" object. 

--
 
 

[Christopher Froehlich]

Fantastic explanation. That clears things up quite a bit. I'll take another look when I get home from work. I had figured out #2, but I was missing #1. I have VS if I need to get into #3, but as you suggest it probably won't be necessary.

[Ryan Ackley]

Hi Christopher,

I've updated Tincr (v1.2) in the Chrome web store and it should be working with IIS. I've tested it locally.

One small issue I ran into is that by default, anything under the IIS wwwroot directory is read-only. I had to manually go into folder permissions and enable write permissions for the Users group. I tested against a simple static website so if you're using Visual Studio, it may handle this already.

-Ryan