Live Preview loads wrong file when changing file quickly

[WebsiteDeveloper]

Steps to reproduce:

1. Open a somewhat larger html file
2. Start Live-Preview
3. Quickly click on another file in your working files

Old Result:

The file opened in step 3 gets shown in Live-Preview

Current Result:
Live Preview does not open and "Unable to load Live Preview page" error is seen.

Expected:
Show the html file from step 3

[njx]

@WebsiteDeveloper - I think this is working as designed; Live Preview is always supposed to switch to show the currently open HTML file, so in this case it should show the file from step 3. We've talked about making it possible to "lock" the live preview to a given file, but that's not implemented right now.

[WebsiteDeveloper]

@njx acually it opens any file type even js files ^ should have made that more clear

[njx]

Oh, that's bad :) Thanks for the clarification.

If you have any earlier sprints installed, would you mind seeing how far back this bug goes? I'm curious whether it's a recent regression.

[WebsiteDeveloper]

will try out.

[WebsiteDeveloper]

@njx it happens even in the oldest version i have currently installed which is Sprint 23 so it seems to be a pretty old regression.

[WebsiteDeveloper]

@njx ping.

[redmunds]

@WebsiteDeveloper Thanks for following up.

I was reviewing Live Preview bugs yesterday and missed this one. I still see this problem in latest code. #5756 is a duplicate of this one. #5110 is similar, but it switches to JS (not HTML) file. I tried to fix this in #6889, but it's still not quite right.

[redmunds]

Actually, I disagree with the Expected Results. If you change the selected HTML file in Brackets, then Live Preview should also change, right?

[WebsiteDeveloper]

That's right.

[redmunds]

Added Brackets 1.0 milestone. Launching Live Preview is still kind of slow, so this is not difficult to hit.

What we need to do when LiveDevelopment._openDeferred resolves is to verify that DocumentManager.getCurrentDocument() is the same as _liveDocument. If not, navigate to DocumentManager.getCurrentDocument().

[njx]

Reviewed. It seems like this isn't likely for many people to hit (because they wouldn't really be switching away right after launching), but the fix seems relatively straightforward. So, if we were to try to fix this, we'd want to timebox it, and bail if it gets complicated.

Moving to low priority. Leaving in the 1.0 milestone for now, but we should delay working on any of these live preview bugs until we know whether we're going to be migrating to the new non-CDT-based architecture for 1.0.

[peterflynn]

Marking needs review to reconsider 1.0 in/out question later

[peterflynn]

Also note: this might be a dupe of #5110 now that the description has been updated.

[redmunds]

Confirmed. Closing. @WebsiteDeveloper Let us know if this is not fixed. Switching Milestone from Brackets 1.0 to Release 40