Skip to content
This repository has been archived by the owner on Sep 6, 2021. It is now read-only.

[Core][Live Preview HTML changes]: Incorrect behavior when live preview non-dafault sample HTML changes. #5176

Closed
julieyuan opened this issue Sep 12, 2013 · 7 comments
Closed

[Core][Live Preview HTML changes]: Incorrect behavior when live preview non-dafault sample HTML changes. #5176

julieyuan opened this issue Sep 12, 2013 · 7 comments
Assignees
@julieyuan
Labels
high priority IQE
Milestone
Sprint 31

Comments

@julieyuan
Copy link

Steps:

  1. Launch Brackets and new a html files.
  2. Save this file and live preview it.
  3. Input some content into the <body> tag, like string "first", and observe the changeson the webpage.
  4. Delete the string "first" character-by character , and obeserve the changes on the webpage.

Result:
The changes on the webpage are wired.
At step3, it previews as "f","f fi" "f fi fir"...while I input "first"
At step4, it doesn't delete the character, actually, it seems to add the string behind the previous strings.

Expected:
it should preview as "first" at step3, and it should only preview the string after deleting at step4.

ENV: MAC10.7 and Win8 English OS
Build: 0.31.0-9414

Notes:
This issue not reproduces to default sample file: index.html.

Snapshots;
Please refer to snapshots for details:
Step3:
3
Step4:
4
@njx
Copy link
Contributor

njx commented Sep 12, 2013

High pri to me for sprint 31.

@ghost ghost assigned njx Sep 12, 2013
@njx
Copy link
Contributor

njx commented Sep 12, 2013

Looks like this has been happening since we turned live HTML on in master, so this isn't an injection from the recent changes.

@njx
Copy link
Contributor

njx commented Sep 12, 2013

I wrote a unit test for this case and it passes, so it's not clear why it fails in the browser (since we test to make sure that RemoteFunctions seems to be doing the right thing as well). Looking into it further.

@njx
Copy link
Contributor

njx commented Sep 12, 2013

Aha. The issue is that in the actual browser DOM, there's an injected <div> for live highlighting that's screwing things up. I'm guessing we never saw this before because in cases where we were testing typing in an empty document, we would probably first create a tag element and then type text in that, and the tag id would get us to the right place. So this is really specific to text directly inside <body>.

@njx njx mentioned this issue Sep 12, 2013
Merged
@ghost ghost assigned julieyuan Sep 12, 2013
@jasonsanjose
Copy link
Member

FBNC @julieyuan

@julieyuan
Copy link
Author

Thanks! Changes has not been merged into latest build 0.31.0-9426. Will check it with next build.

@julieyuan
Copy link
Author

Fixed in build 0.31.0-9479. So closing it. Here is the snapshot:
screen shot 2013-09-15 at 9 57 42 pm

@core-ai-bot core-ai-bot mentioned this issue Aug 29, 2021
Open
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Assignees

@julieyuan julieyuan

Labels
high priority IQE
Projects
None yet
Milestone
Sprint 31
Development

No branches or pull requests
3 participants
@njx @jasonsanjose @julieyuan