[CLOSED] live development from user-specified base url does not work

[core-ai-bot]

Issue by joelrbrandt
Monday Apr 08, 2013 at 14:44 GMT
Originally opened as adobe/brackets#3372

---

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

83190c9c 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

[core-ai-bot]

Comment by gruehle
Monday Apr 08, 2013 at 14:51 GMT

---

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

[core-ai-bot]

Comment by peterflynn
Monday Apr 08, 2013 at 17:08 GMT

---

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

[core-ai-bot]

Comment by njx
Monday Apr 08, 2013 at 17:30 GMT

---

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

[core-ai-bot]

Comment by redmunds
Wednesday Apr 10, 2013 at 03:22 GMT

---

FBNC back to@joelrbrandt.

[core-ai-bot]

Comment by redmunds
Wednesday Apr 10, 2013 at 03:26 GMT

---

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

[core-ai-bot]

Comment by joelrbrandt
Wednesday Apr 10, 2013 at 03:56 GMT

---

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

[core-ai-bot]

Comment by joelrbrandt
Wednesday Apr 10, 2013 at 03:57 GMT

---

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

[core-ai-bot]

Comment by redmunds
Wednesday Apr 10, 2013 at 04:10 GMT

---

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

[core-ai-bot]

Comment by joelrbrandt
Wednesday Apr 10, 2013 at 04:24 GMT

---

@redmunds Err, I pasted the wrong SHA. I'm on 6f2dabd33e67. 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.

[core-ai-bot]

Comment by jasonsanjose
Wednesday Apr 10, 2013 at 04:58 GMT

---

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?

[core-ai-bot]

Comment by joelrbrandt
Wednesday Apr 10, 2013 at 12:38 GMT

---

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

[core-ai-bot]

Comment by joelrbrandt
Wednesday Apr 10, 2013 at 12:41 GMT

---

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

[core-ai-bot]

Comment by jasonsanjose
Wednesday Apr 10, 2013 at 15:30 GMT

---

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

[core-ai-bot]

Comment by jasonsanjose
Wednesday Apr 10, 2013 at 16:23 GMT

---

Filed #3402. Will try to reproduce on windows.

[core-ai-bot]

Comment by joelrbrandt
Wednesday Apr 10, 2013 at 16:24 GMT

---

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

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