Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Sign up for GitHub

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Jump to bottom

[Live HTML]: Live Preview can never update if initially launched with syntax error #12390

Open
core-ai-bot opened this issue Aug 31, 2021 · 19 comments
Open

[Live HTML]: Live Preview can never update if initially launched with syntax error #12390

core-ai-bot opened this issue Aug 31, 2021 · 19 comments

Comments

@core-ai-bot
Copy link
Member

Issue by julieyuan
Wednesday Sep 25, 2013 at 09:32 GMT
Originally opened as adobe/brackets#5338

Steps:

  1. Launch Brackets and new a html file.
  2. Input some content between tag body: < abc.
  3. Live preview this html file.
  4. Delete the space between < and abc, or just make any change in this file. The tooltip of Live preview icon will show "not updating due to syntax error".
  5. Delete < to make sure that there isn't syntax error in this file.
  6. Edit this file and save it.

Result:
Live preview cannot updating the file at step6. I have to reload the webpage through chrome browser.

Expected:
At step6, Live preview should work well for there isn't any syntax error.

ENV: MAC10.8 and Win8.1 English OS.
Build: 0.32.0-9618

Snapshots:
Please refer to snapshots for details:
Step3:
1
Step4:
2
Step5:
3
Step6:
4
@core-ai-bot
Copy link
Member Author

Comment by redmunds
Wednesday Sep 25, 2013 at 14:46 GMT

Thanks for the detailed recipe. When whitespace occurs following a <, seems like Live Dev should interpret that as content and not a starting tag delimiter.

@core-ai-bot
Copy link
Member Author

Comment by dangoor
Wednesday Sep 25, 2013 at 15:03 GMT

@redmunds I'm not sure that < abc is valid. Also, the problem is reproducible even if you start with <abc. The real problem here is that we serve up invalid HTML from the get go and then expect to be able to update it.

It seems to me that the best solution here is to have a new state in which live development starts in the "invalid" state. Once the document becomes valid for the first time, then it is sent to the browser.

What do you think,@njx?

(marking this medium priority)

@core-ai-bot
Copy link
Member Author

Comment by redmunds
Wednesday Sep 25, 2013 at 15:35 GMT

Sounds like there are 2 separate cases.

As for the < abc case, that may be invalid in XHTML, but "valid" is a pretty vague term in HTML :) All browsers seem to render the '<' char as content, and I suspect people expect Brackets to behave as browsers do.

@core-ai-bot
Copy link
Member Author

Comment by njx
Wednesday Sep 25, 2013 at 19:27 GMT

I think we need to fix the problem@dangoor pointed out in any case (I had had a vague feeling earlier that there might be a bug here but never actually tested it). But I'm a little confused about how that comes up with these steps, since in the bug case the file doesn't start out invalid, if I'm reading the steps correclty.

Regarding whether we decide to be more lenient about the < abc case, it would probably be a fairly small change to the tokenizer to allow this, but the flipside is that if someone were to type that temporarily by mistake (adding a space after an existing tag open), it could result in a very disruptive DOM diff. That doesn't really matter while we're dealing with static HTML, but it would be more of an issue when we get to dealing with HTML that's modified at runtime. In general, the reason we try to stick with valid HTML is not because we want to strictly enforce it, but because we want to avoid updating while the DOM structure isn't clear.

If this were a common type of invalid HTML that people want to preserve, then I think we should consider allowing it, but I don't have a good sense of that.

@core-ai-bot
Copy link
Member Author

Comment by dangoor
Thursday Sep 26, 2013 at 01:27 GMT

@njx The file does start out invalid, assuming our tokenizer currently gets stuck in the open tag state for < abc, because the steps say not to turn on live development until after that initial document (with the invalid bit) is typed.

My main concern is less about whether < abc is considered valid and much more about recovering from an invalid state when live dev is started. As@njx says, it's an easy change to the tokenizer for the < behavior.

@core-ai-bot
Copy link
Member Author

Comment by njx
Thursday Sep 26, 2013 at 01:33 GMT

Ah, I missed that. But yes, we definitely need to fix it.

@core-ai-bot
Copy link
Member Author

Comment by istudiomobile
Thursday Sep 26, 2013 at 14:28 GMT

The same happens to me. While editing html file, delete two rows (list elements) I wasn't using. then live preview stopped 'cause "syntax error", but there´s no syntax error. I've to stop and start over.

Hope this helps. Thank you.

@core-ai-bot
Copy link
Member Author

Comment by dangoor
Thursday Sep 26, 2013 at 15:04 GMT

@brickyenne Was Live HTML working and then stopped working? If so, that may be a different problem. Brackets should highlight where it thinks there's an error in the file.

If you continue to have problems, if you can share some or all of your HTML file with us (possibly in a new issue on GitHub) that may help.

@core-ai-bot
Copy link
Member Author

Comment by istudiomobile
Thursday Sep 26, 2013 at 15:17 GMT

Strange thing is there’s no error visible, no pink tag. Just deleted a couple of

  • list ítems and every stopped working. Just pink live editing icon (switches back to orange after saving but page does not gets updated).

    Every now and then receive an alert box saying: Cannot load page. Error in live editing”

    Do you thing I should post this as a bug?

    Thank you.

    Enviado con Correo de Windows

    De: Kevin Dangoor
    Enviado el: ‎jueves‎, ‎26‎ de ‎septiembre‎ de ‎2013 ‎10‎:‎05
    Para: adobe/brackets
    CC: brickyenne

    @brickyenne Was Live HTML working and then stopped working? If so, that may be a different problem. Brackets should highlight where it thinks there's an error in the file.

    If you continue to have problems, if you can share some or all of your HTML file with us (possibly in a new issue on GitHub) that may help.

    —
    Reply to this email directly or view it on GitHub.

    @core-ai-bot
    Copy link
    Member Author

    Comment by dangoor
    Thursday Sep 26, 2013 at 16:41 GMT

    @brickyenne From your description, it sounds like you may be encountering this bug, but you may also be encountering something different. I would recommend opening a separate bug just to be sure that we're correctly diagnosing what you're seeing without getting confused with the problem reported here. Please be sure to include the steps you took and when specifically live HTML worked and didn't work for you. (It's not clear to me right now if you had seen any changes come through to the browser). Any example HTML that reproduces the problem will be a big help.

    @core-ai-bot
    Copy link
    Member Author

    Comment by njx
    Monday Sep 30, 2013 at 18:19 GMT

    Medium pri to@dangoor

    @core-ai-bot
    Copy link
    Member Author

    Comment by peterflynn
    Tuesday Oct 15, 2013 at 20:45 GMT

    Changing title to clarify that the bug only occurs when Live Development is started with a syntax error (was: "[Core][Live HTML]: Live preview cannot continue to update if the orginal html file ever has syntax error.")

    @core-ai-bot
    Copy link
    Member Author

    Comment by peterflynn
    Tuesday Oct 15, 2013 at 20:48 GMT

    Although@dangoor it seems like there is a secondary bug here: in the first screenshot, the file supposedly has syntax we consider invalid (< abc) and thus Live Preview is broken, but the lightning bolt is still the regular golden color. It should be magenta any time we're unable to push updates, right?

    @core-ai-bot
    Copy link
    Member Author

    Comment by redmunds
    Saturday Mar 08, 2014 at 01:30 GMT

    In the scenario described in #7126, I am able to open a page with invalid syntax, then fix formatting of page, and Live HTML resumes.

    #7126 also describes the problem where icon returns to yellow when there is still a syntax error in page.

    @core-ai-bot
    Copy link
    Member Author

    Comment by pthiess
    Monday Apr 14, 2014 at 20:10 GMT

    reviewed - 1.0 milestone.

    @core-ai-bot
    Copy link
    Member Author

    Comment by njx
    Monday Apr 14, 2014 at 20:11 GMT

    Reviewed, leaving open for 1.0.

    @core-ai-bot
    Copy link
    Member Author

    Comment by busykai
    Friday Dec 12, 2014 at 14:33 GMT

    Would we want a behavior that prevented Live Preview from opening if the HTML cannot be understood by instrumentation?

    @core-ai-bot
    Copy link
    Member Author

    Comment by redmunds
    Friday Dec 12, 2014 at 16:15 GMT

    I think the desired behavior would be the same as if the user opened a page with valid syntax and then edited page so that syntax was no longer valid. In this case, the first line with a syntax error has a red line number and HTML is not updated until syntax error is fixed. This would be consistent with current behavior.

    One problem with this approach is if the syntax error is on a line that's not in the current view port -- let us know if you can think of a way to inform user of that case.

    @core-ai-bot
    Copy link
    Member Author

    Comment by marmistrz
    Wednesday Jul 20, 2016 at 18:19 GMT

    The problem persists in 1.7.

    Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
    Assignees
    No one assigned
    Labels
    None yet
    Projects
    None yet
    Milestone
    No milestone
    Development

    No branches or pull requests
    1 participant
    @core-ai-bot