actions in ember-attacher content dont' work if app customizes rootElement #6

enkol · 2017-05-16T16:27:26Z

If your app sets a custom rootElement in app.js, calling actions within ember-attacher content block doesn't work.

Simplified reproduction scenario:

app.js:

...
  App = Application.extend({
    modulePrefix: config.modulePrefix,
    podModulePrefix: config.podModulePrefix,
    rootElement: '#my-app-root',
    Resolver
  });
...

index.html

...
  <body>
    {{content-for "body"}}

    <div id="my-app-root"></div>

    <script src="{{rootURL}}assets/vendor.js"></script>
    <script src="{{rootURL}}assets/my-app-test.js"></script>

    {{content-for "body-footer"}}
  </body>
...

application.hbs

<button>
Click!
{{#ember-attacher as |emberAttacher|}}
Hello!
<button {{action "customAction"}}>Wave</button>
<button {{action emberAttacher.hide}}>Close</button>
{{/ember-attacher}}
</button>

Both buttons "Wave" and "Close" do not work, if a rootElement was set in app.js.

enkol · 2017-05-16T16:30:44Z

This also may be the reason, why the same doesn't work correctly in ember-twiddle.com.

Example:
https://ember-twiddle.com/0458163455d797c47e4eb9883a2802ec/b8aa112f3e99004fd21311625ef624eeb214cceb?openFiles=templates.components.my-trigger.hbs%2C

kybishop · 2017-05-16T17:14:45Z

Thanks for the report and repro @enkol! I'll look into this later in the afternoon. Very curious that all actions seem borked, not just ember-attacher's.

kybishop · 2017-05-16T22:48:31Z

This is occurring because poppers need to be rendered in the <body> to avoid z-index issues (if we don't render the popper in the body, elements that are less nested than the popper can potentially overlap our popper.

<html>
  <body>
    <div id="some-other-root-element">
      {{#ember-attacher class="popper tooltip"}}Hello!{{/ember-attacher}}
    </div>
    <p>I will overlap the tooltip if it is rendered in #some-other-root-element!</p>
  </body>
</html>

When <body> is no longer the rootElement, the popper's element's no longer recieves events.

Ember-attacher is implemented using ember-popper, where this implicit rendering takes place. Ember-popper already has an option to specify where poppers should be rendered, but I haven't provided a passthrough for said option.

I see two potential fixes:

Expose the popperContainer option. This is the least intrusive, but requires you to input the option every time, at least until Allow user-defined defaults that override the normal defaults #1 is implemented.
Alternatively, we could make popperContainer a computed property in ember-popper, and have it intelligently determine root element. I'm more hesitant to do this because people will likely see the aforementioned z-index issue and not know why it is happening. With option (1), we can at least point toward some documentation that mentions this drawback.

@enkol thoughts on the fixes?

enkol · 2017-05-17T11:39:50Z

After taking a look at the code behind; i found, that you already have the 'renderInPlace' option. Setting it to true re-enables the actions, due to not moving the element outside of embers event scope anymore.
So there is at least already a way to make it work, as long as one takes care of the z-index in his tooltip styles.

I'd let it stay as it is by now and just document 'renderInPlace' as solution alongside a hint to take care of z-index then. In most CSS Frameworks, i.e. Bootstrap, tooltip styles already have proper z-index.

Once #1 is implemented, i'd provide a config option to optionally change the popperContainer and keep document.body as default. People then could set it to popperContainer = ENV.APP.rootElement or a custom value.

PS: Thx for the great addon, really nice work!

kybishop · 2017-05-17T19:30:48Z

Happy you're enjoying it!

re renderInPlace: Just want to make sure you're aware that setting a high z-index on a deeply nested element will not cause that element to overlap elements that are not nested as deeply. Z-index works in an unfortunate way where higher elements in the dom tree take precedence, regardless of z-index values.

For now I'll add documentation to renderInPlace in the dummy app. Will also add a passthrough for popperContainer and get to work on #1.

kybishop mentioned this issue May 17, 2017

pass through popperContainer #10

Merged

kybishop closed this as completed in #10 May 17, 2017

Provide feedback

Saved searches

Use saved searches to filter your results more quickly

actions in ember-attacher content dont' work if app customizes rootElement #6

actions in ember-attacher content dont' work if app customizes rootElement #6

enkol commented May 16, 2017

enkol commented May 16, 2017

kybishop commented May 16, 2017 •

edited

Loading

kybishop commented May 16, 2017 •

edited

Loading

enkol commented May 17, 2017

kybishop commented May 17, 2017 •

edited

Loading

actions in ember-attacher content dont' work if app customizes rootElement #6

actions in ember-attacher content dont' work if app customizes rootElement #6

Comments

enkol commented May 16, 2017

enkol commented May 16, 2017

kybishop commented May 16, 2017 • edited Loading

kybishop commented May 16, 2017 • edited Loading

enkol commented May 17, 2017

kybishop commented May 17, 2017 • edited Loading

kybishop commented May 16, 2017 •

edited

Loading

kybishop commented May 16, 2017 •

edited

Loading

kybishop commented May 17, 2017 •

edited

Loading