brackets-archive / bracketsIssues

Archive of issues in brackets.
0 stars 0 forks source link

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

Open core-ai-bot opened 3 years ago

core-ai-bot commented 3 years ago

Issue by peterflynn Wednesday Apr 03, 2013 at 06:20 GMT Originally opened as https://github.com/adobe/brackets/issues/3325


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

core-ai-bot commented 3 years ago

Comment by peterflynn Wednesday Apr 03, 2013 at 06:21 GMT


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.

core-ai-bot commented 3 years ago

Comment by peterflynn Wednesday Apr 03, 2013 at 06:30 GMT


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

core-ai-bot commented 3 years ago

Comment by pthiess Monday Apr 08, 2013 at 18:12 GMT


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

core-ai-bot commented 3 years ago

Comment by pthiess Monday Apr 08, 2013 at 18:13 GMT


@redmunds FYI

core-ai-bot commented 3 years ago

Comment by pthiess Monday Apr 08, 2013 at 18:56 GMT


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

core-ai-bot commented 3 years ago

Comment by redmunds Wednesday Apr 10, 2013 at 00:15 GMT


This issue reproduces in Sprint 22.

I opened a slightly different issue (https://github.com/adobe/brackets/issues/3394) that was introduced in Sprint 23.

core-ai-bot commented 3 years ago

Comment by jasonsanjose Wednesday Apr 10, 2013 at 05:01 GMT


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

core-ai-bot commented 3 years ago

Comment by redmunds Wednesday Apr 10, 2013 at 17:15 GMT


Moved to Sprint 24.

core-ai-bot commented 3 years ago

Comment by redmunds Friday Apr 26, 2013 at 17:14 GMT


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.

core-ai-bot commented 3 years ago

Comment by redmunds Friday Apr 26, 2013 at 17:22 GMT


@peterflynn Your thoughts?

core-ai-bot commented 3 years ago

Comment by redmunds Thursday Jun 20, 2013 at 04:06 GMT


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