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.

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

Rendering htmlSafe'd falsey value as first thing in root loading template causes entirety of loading template content to permanently displace/replace root app outlet. #16172

Closed
kennethdavidbuck opened this issue Jan 23, 2018 · 7 comments

Comments

@kennethdavidbuck
Copy link
Contributor

kennethdavidbuck commented Jan 23, 2018

Entering the root loading route on first load, where the loading template only renders an htmlSafe falsey value (undefined etc), results in the root application outlet being permanently rendered out of order with respect to adjacent dom. Please see the attached twiddle for a minimum recreation of the issue. Toggle between double stash and triple stash in the loading route to see the issue appear and disappear. The issue first results when I switch from 2.9.x to 2.10.x. The issue is still present in my 2.18.x app.

Twiddle: https://ember-twiddle.com/516a41613293d3dc55c31a06009a45f7?openFiles=templates.loading.hbs%2C

Update The issue is actually a little bit worse than I thought. It turns out that the loading template content is getting permanently rendered where the main application outlet should be. I have updated the twiddle to demonstrate this. You will see that the content placed after {{{foo}}} in the loading template ends up being permanently placed where the main application outlet should be.

@kennethdavidbuck kennethdavidbuck changed the title Rendering falsey htmlSafe in root loading template puts outlet/dom out of order Rendering falsey htmlSafe in root loading template puts outlet/dom permanently out of order Jan 23, 2018
@kennethdavidbuck kennethdavidbuck changed the title Rendering falsey htmlSafe in root loading template puts outlet/dom permanently out of order Rendering htmlSafe'd falsey value in root loading template puts outlet/dom permanently out of order Jan 23, 2018
@kennethdavidbuck kennethdavidbuck changed the title Rendering htmlSafe'd falsey value in root loading template puts outlet/dom permanently out of order Rendering htmlSafe'd falsey value in root loading template puts application outlet/dom permanently out of order Jan 23, 2018
@kennethdavidbuck kennethdavidbuck changed the title Rendering htmlSafe'd falsey value in root loading template puts application outlet/dom permanently out of order Rendering htmlSafe'd falsey value as first thing in root loading template causes entirety of loading template content to permanently displace/replace root app outlet. Jan 24, 2018
@rwjblue
Copy link
Member

rwjblue commented Feb 24, 2018

Would you mind updating the demo to use 3.1? This may have been addressed by the glimmer-vm update...

@kennethdavidbuck
Copy link
Contributor Author

kennethdavidbuck commented Feb 24, 2018

Hi @rwjblue , I created a temporary repo with emberjs 3.1.0-beta.2 installed and the bug is still present. https://github.com/kennethdavidbuck/emberjs-issue-16172-recreate

screen shot 2018-02-24 at 10 34 00 am

@rwjblue
Copy link
Member

rwjblue commented Feb 24, 2018

Thank you! Sorry for the delays here. I’ll try to carve out some time to dig in and at least figure out where things are going wrong...

@kennethdavidbuck
Copy link
Contributor Author

All good, and thanks! I just wrote a failing test as well. I'll push that up in the next couple minutes here.

@mongoose700
Copy link
Contributor

I ran into what's probably the same issue in a component: https://ember-twiddle.com/b132a59b1ec18c91c45547b395ba10d6

It will trigger only if the component is tagless, I have an HTML-safe empty string at the start of the template, and the component is used with a block that includes at least one newline.

@mongoose700
Copy link
Contributor

This issue also duplicates #14924

chancancode added a commit to glimmerjs/glimmer-vm that referenced this issue Sep 24, 2018
Likely related:

emberjs/ember.js#14924
emberjs/ember.js#16172
emberjs/ember.js#16314

Closes #791

Co-authored-by: Michael Peirce <msp700@gmail.com>
chancancode added a commit that referenced this issue Sep 25, 2018
chancancode added a commit to glimmerjs/glimmer-vm that referenced this issue Sep 25, 2018
Likely related:

emberjs/ember.js#14924
emberjs/ember.js#16172
emberjs/ember.js#16314

Closes #791

Co-authored-by: Michael Peirce <msp700@gmail.com>
chancancode added a commit that referenced this issue Sep 25, 2018
chancancode added a commit that referenced this issue Sep 25, 2018
chancancode added a commit that referenced this issue Sep 25, 2018
chancancode added a commit that referenced this issue Sep 25, 2018
(cherry picked from commit 830d766)
chancancode added a commit that referenced this issue Sep 25, 2018
Fixes #14978, #14924, #16172, #16314

(cherry picked from commit 283dcd1)
chancancode added a commit that referenced this issue Sep 25, 2018
(cherry picked from commit 830d766)
chancancode added a commit that referenced this issue Sep 25, 2018
Fixes #14978, #14924, #16172, #16314

(cherry picked from commit 283dcd1)
@chancancode
Copy link
Member

Sorry it took so long, this is fixed in 3.4.3 (#17003)

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

4 participants