You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
{{ message }}
This repository was archived by the owner on Sep 6, 2021. It is now read-only.
Repository navigation
This repository was archived by the owner on Sep 6, 2021. It is now read-only.
Live Preview loads wrong file when changing file quickly #4615
@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.
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.
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().
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.
Activity
njx commentedon Aug 5, 2013
@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 commentedon Aug 5, 2013
@njx acually it opens any file type even js files ^ should have made that more clear
njx commentedon Aug 5, 2013
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 commentedon Aug 5, 2013
will try out.
WebsiteDeveloper commentedon Aug 5, 2013
@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 commentedon Mar 6, 2014
@njx ping.
redmunds commentedon Mar 6, 2014
@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 commentedon Mar 6, 2014
Actually, I disagree with the Expected Results. If you change the selected HTML file in Brackets, then Live Preview should also change, right?
WebsiteDeveloper commentedon Mar 9, 2014
That's right.
redmunds commentedon Mar 15, 2014
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._openDeferredresolves is to verify thatDocumentManager.getCurrentDocument()is the same as_liveDocument. If not, navigate toDocumentManager.getCurrentDocument().njx commentedon Apr 11, 2014
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 commentedon Apr 11, 2014
Marking needs review to reconsider 1.0 in/out question later
peterflynn commentedon Apr 11, 2014
Also note: this might be a dupe of #5110 now that the description has been updated.
redmunds commentedon May 29, 2014
Confirmed. Closing. @WebsiteDeveloper Let us know if this is not fixed. Switching Milestone from
Brackets 1.0toRelease 40