Live Preview status indicator never shows "complete" even though it's connected for this node project

[njx]

1. Clone and set up https://github.com/njx/repoman according to the README (or send me email and I can send you some self-signed certs)
2. In the repoman folder, do node index.js
3. In Brackets, open the "client" folder as a project
4. In the Project Settings, set the Live Preview Base URL to https://localhost:8080
5. Click the Live Preview button

Result: The lightning bolt only goes halfway, even though it actually connects fine. If you switch to another file (e.g. styles.css), the lightning bolt becomes complete and is fine thereafter.

[njx]

Marking low priority. Not clear if there's something specific about my project that's causing this problem.

[njx]

Note that this breaks live development features that occur in the editor you start Live Preview from (e.g. CSS highlighting from an inline editor) until you switch to another document and then switch back.

[njx]

Bumping to medium priority since this does actually break functionality.

[njx]

Reviewed, assigning to @redmunds. Not for this sprint.

[njx]

Nominating for sprint 18 to investigate and figure out whether this is an isolated issue with my specific project or might be something more general.

[njx]

One more data point: you can actually see the same bug occur at around 15:15 in the nettuts+ tutorial video that was posted recently: http://net.tutsplus.com/tutorials/tools-and-tips/a-peek-at-brackets/ -- that looks like a much simpler PHP example that doesn't have the HTTPS weirdness going on with my example. Maybe we could try reproducing that?

[redmunds]

I do not yet have a reliable recipe, so I think we need to push this one out of sprint 18.

[redmunds]

In general, the problem is that onload never gets called for the page. Here's what I'm seeing in the console:

Could not load source file at https://localhost:8080/index.html
Object
/Users/randyedmunds/github/brackets/src/LiveDevelopment/LiveDevelopment.js:402
_onError /Users/randyedmunds/github/brackets/src/LiveDevelopment/LiveDevelopment.js:402
f.Callbacks.n jquery-1.7.min.js:2
f.Callbacks.o.fireWith jquery-1.7.min.js:2
f.Callbacks.o.fire jquery-1.7.min.js:2
f.Callbacks.n jquery-1.7.min.js:2
f.Callbacks.o.fireWith jquery-1.7.min.js:2
f.Callbacks.o.fire jquery-1.7.min.js:2
onError /Users/randyedmunds/github/brackets/src/LiveDevelopment/Agents/DOMAgent.js:192

GET https://localhost:8080/index.html /Users/randyedmunds/github/brackets/src/LiveDevelopment/Agents/DOMAgent.js:194
_onFinishedLoadingDOM /Users/randyedmunds/github/brackets/src/LiveDevelopment/Agents/DOMAgent.js:194
_onSetChildNodes /Users/randyedmunds/github/brackets/src/LiveDevelopment/Agents/DOMAgent.js:226
f.event.dispatch jquery-1.7.min.js:3
f.event.add.h.handle.i jquery-1.7.min.js:3
f.event.trigger jquery-1.7.min.js:3
f.fn.extend.triggerHandler jquery-1.7.min.js:3
_onMessage /Users/randyedmunds/github/brackets/src/LiveDevelopment/Inspector/Inspector.js:182

This call is initiated in _onFinishedLoadingDOM() function at line 177 of LiveDevelopment/Agents/DOMAgent.js

[njx]

Okay, I think there are two separate issues here.

The case in the "nettuts" tutorial video is an edge case. I was able to reproduce it easily by doing the same thing he does in the video: create a simple PHP file with <?= 'hi there'; ?> in it, run a server (only works in php > 5.4) using php -S localhost:8888, then connect to it from Brackets. In that case, you see the lightning bolt half-complete, but all the live development stuff works fine. The issue here is that setChildNodes() never gets called back from WebInspector, so _onDOMFinishedLoading() is never called. I'm guessing this is because in this PHP file, there are no actual HTML tags, so it doesn't get treated as a DOM--it's just rendered as text or something. If I wrap HTML tags around the PHP, the lightning bolt completes. So this seems like a real edge case that we probably don't need to worry about (especially since live development works okay afterwards--we don't actually reject the promise, we just never complete it, and other stuff continues to work). That said, we might want to be more robust to this not getting called back.

For my original bug, I'm guessing that what's happening is that the Brackets shell is refusing to load the https:// URL because the certificate used by my Node app is a fake self-signed cert. (If you open the URL directly in the browser, you get a cert warning that you can bypass.) As evidence for this, if I just open dev tools in Brackets and try to do window.location.href="https://localhost:8080/index.html", it doesn't do anything, whereas I can go to other https URLs fine.

In theory we could work around this by disabling cert checks--there's a Chromium command-line switch to do this, but it doesn't appear to be exposed through CEF.

What's odd is that in master as of now, this defeats live development completely--it just shuts off. It used to be that the behavior was the same as in the PHP case above--the lightning bolt would half-complete, but live development would still work. I'm not sure why this changed--the changes we made a month or so ago to fix up the error handling shouldn't have affected the behavior here, I think.

Popping up a level, I'm not sure we're even using DOMAgent right now--I believe it's only for the experimental mapping of HTML to DOM nodes. So I wonder if we should just comment it out.

[njx]

I tried just commenting out the DOM agent and live development broke, so I guess we're using it for something :)

If the only real issues here are the ones I mentioned above (file with no HTML tags and fake cert), then I don't think this is a high priority to address. I do think other devs might run into the same issue, where they're creating a dev server with a fake cert in advance of getting a real one; but perhaps they might just use HTTP while in development. In any case, it's probably not a high-hit use case.

So we should consider bumping this down to low priority and removing the milestone.

[njx]

(Also, it turns out I didn't really need to use HTTPS anyway...I could just use HTTP on my side and still proxy to the HTTPS server on github.)