Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Already on GitHub? Sign in to your account

live development from user-specified base url does not work #3372

Closed
joelrbrandt opened this Issue Apr 8, 2013 · 15 comments

Comments

Projects
None yet
6 participants
Member

joelrbrandt commented Apr 8, 2013

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

Member

gruehle commented Apr 8, 2013

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

Member

peterflynn commented Apr 8, 2013

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

@ghost ghost assigned jasonsanjose Apr 8, 2013

Member

njx commented Apr 8, 2013

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

@redmunds redmunds added a commit that referenced this issue Apr 10, 2013

@redmunds redmunds Merge pull request #3392 from adobe/jasonsanjose/issue-3372
Fix #3372 check for valid server
6f2dabd

@ghost ghost assigned joelrbrandt Apr 10, 2013

Contributor

redmunds commented Apr 10, 2013

FBNC back to @joelrbrandt.

Contributor

redmunds commented Apr 10, 2013

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

@joelrbrandt joelrbrandt reopened this Apr 10, 2013

Member

joelrbrandt commented Apr 10, 2013

@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.

Member

joelrbrandt commented Apr 10, 2013

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

Contributor

redmunds commented Apr 10, 2013

@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.

Member

joelrbrandt commented Apr 10, 2013

@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.

Member

jasonsanjose commented Apr 10, 2013

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?

@ghost ghost assigned jasonsanjose Apr 10, 2013

Member

joelrbrandt commented Apr 10, 2013

@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:

Screen Shot 2013-04-10 at 5 29 47 AM

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.

Member

joelrbrandt commented Apr 10, 2013

@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?

Member

jasonsanjose commented Apr 10, 2013

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

Member

jasonsanjose commented Apr 10, 2013

Filed #3402. Will try to reproduce on windows.

Member

joelrbrandt commented Apr 10, 2013

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

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

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment