live development from user-specified base url does not work

[joelrbrandt]

Live development no longer works with a user-specified base url.

83190c9 brought code into LiveDevelopment.js that calls _serverProvider.setRequestFilterPaths on any server provider. However, when the user specifies a base url, a different server provider is used (UserServerProvider, defined in LiveDevelopment.js). This provider does not have the necessary interface.

Based on a really quick read of the code, it seems to me that setRequestFilterPaths code should be specific to the StaticServerProvider. So, I'm exactly sure why this code is in LiveDevelopment.js. But I could easily be misunderstanding something.

Even if I add a no-op setRequestFilterPaths function to UserServerProvider, live development still doesn't work correctly. It never fully connects, and every time I switch files, a new tab is opened in Chrome.

cc @gruehle since it looks like he added the setRequestFilterPaths call to LiveDevelopment.js

[gruehle]

@jasonsanjose can you take a look? I'm sitting on a beach and don't have access to a computer this week. Thanks!

[peterflynn]

Tagging Sprint 23 & assigning so it doesn't slip off the radar

[njx]

Also, we should figure out why there was no unit test failure for this.

[redmunds]

FBNC back to @joelrbrandt.

[redmunds]

@RaymondLim This is probably why you could not get server-side smokes working for PHP file.

[joelrbrandt]

@jasonsanjose This doesn't seem to be fixed for me. I'm on mac using the shell from the Sprint 22 build, and I'm at 3551e40 in Brackets.

Here's what I did to repro (and the results):

1. Set up a local server to serve the contents of the "citrus completed" folder at http://localhost:8080/
2. Opened the "citrus completed" folder in Brackets, and set the Live Development base url to http://localhost:8080/
3. Closed Chrome
4. Clicked the live dev button
5. The correct url (http://localhost:8080/) did indeed open in my browser. However, the live dev connection never fully completed. The lightning bolt stayed half-colored for awhile, then went to grey
6. When I switch to a CSS file, the lightning bolt turns fully solid yellow. However, it doesn't seem to actually be connected (changes do not affect the browser)

Let me know if you need any more info to repro.

[joelrbrandt]

Also, I'm not sure how this bug got closed. I think maybe because the commit message said "Fix" and then the issue number?

[redmunds]

@joelrbrandt I think the bug got auto-closed. I just merged this fix an hour ago, so be sure to pull the latest from master.

[joelrbrandt]

@redmunds Err, I pasted the wrong SHA. I'm on 6f2dabd. But everything I said above is still true. In other words, this bug still repros for me using the Brackets Sprint 22 shell and master in brackets using the steps above.

[jasonsanjose]

Was the URL "http://localhost:8080/" or "http://localhost:8080/index.html"? I don't know how that would happen, but I thought I would check. Also, what Chrome version are you on?

I tried to reproduce using the built-in mac web server and creating a simple index.html at the root and couldn't reproduce.

StaticServerDomain shouldn't be in the picture here since you're using a base URL. If it was, it would have timed out after 5 seconds and reverted to normal static file serving instead of overriding the HTTP response. Was there anything in the console?

[joelrbrandt]

@jasonsanjose "http://localhost:8080/" is the base URL I put in the dialog in Brackets. "http://localhost:8080/index.html" is the URL that showed up in the browser after clicking live development.

I'm on Chrome 27.0.1453.15 beta

Yes, I get lots of errors in the console! See the screen shot below:

Also, I put the citrus cafe website on my machine's built-in Apache server to make sure the port number wasn't screwing up our logic. So, I specified a base URL of "http://localhost/citrus/" and got a URL in the browser of "http://localhost/citrus/index.html". I got exactly the same errors as above.

[joelrbrandt]

@jasonsanjose Aha! I switched to the stable release of Chrome (26.0.1410.63) and I don't experience the problem anymore.

So... looks like we've got trouble headed our way.

What should we do with this bug?

[jasonsanjose]

Let's close this bug assuming the fix looks good to you on Chrome 26 and re-open a new Chrome 27 bug.

[jasonsanjose]

Filed #3402. Will try to reproduce on windows.

[joelrbrandt]

Okay, this bug looks fixed to me. Thanks! Closing.

I'll add repro steps to #3402 as well.