Live development: Switching between iframe outer & inner pages shows unexpected content

[peterflynn]

Old Title: Live development: Switching between iframe outer & inner pages shows wrong content

1. Open an HTML file with an iframe that includes another HTML file in the project
2. Launch Live Preview
3. In Brackets, switch to the HTML file that the iframe points at
4. Toggle Live Preview off, then back on again
5. Switch back to the outer HTML file

Result:
3 - page in browser does not change; console shows error "Couldn't find the tag information for (filename of inner file)"
4 - tab opens showing inner file as expected
5 - tab changes to show outer file, but the content in the iframe is a nested copy of the outer file (it actually seems to recurse twice, then stops -- so the outer file's iframe contains a copy of the outer file, whose iframe in turn includes another copy of the outer file, whose iframe in turn is blank) Fixed.

Expected:
3 - browser page switches to inner HTML file
5 - browser page switches back to outer HTML file, but it looks exactly the same as in step 2

[peterflynn]

I'm guessing this broke due to the Node static server stuff, not the new HTML highlighting... but assigning to this sprint just in case.

[peterflynn]

Once you're in this state, it's stuck that way until you either restart the Node server or quit & relaunch the entire Brackets process. (Refreshing Brackets alone is not enough -- so something on the Node side is getting stuck in a bad state).

[pthiess]

@peterflynn - reviewed - if this is too complicated we may punt on it in this sprint, certainly a medium priority.

[pthiess]

@redmunds FYI

[pthiess]

@peterflynn @redmunds In case this turns out as a legacy from earlier sprints - should we add this to our bug card too?

[redmunds]

This issue reproduces in Sprint 22.

I opened a slightly different issue (#3394) that was introduced in Sprint 23.

[jasonsanjose]

After #3392 merged, step 3 reproduces but not step 5.

[redmunds]

Moved to Sprint 24.

[redmunds]

The worst part of this bug (Step 5) is fixed. The behavior in Step 3 is desirable in some workflows, so this needs more research. Moving out of Sprint 24.

Details: We continue to show top-level HTML page when included files (such as .css and .js) are selected, so they can be edited in the context of the top-level HTML page. It can also be beneficial to edit an "included" .html file in this same manner.

Currently, user can use LiveDev both ways. The workflow is to view the "included" file as a top-level HTML page is to stop and restart LiveDev. If we "fix" this problem as described in the bug report, then we block this workflow.

Even if we keep this as it is, we need to review the workflow for possible improvements. Needs research.

[redmunds]

@peterflynn Your thoughts?

[redmunds]

I think this behavior might be preferred, so changing to low priority.