ember-popper component is ember component and use didRender,
ref modifier is not expected work usually, component only set ref dom Node after didRender, not the dom inserted .

so, when didRender execute in https://github.com/kybishop/ember-popper/blob/master/addon/components/ember-popper-base.js#L163 , _popperElement is undefined , if we use #in-element (for example tooltip ui), it will show in a default position (maybe the top left corner)， after ref modifier install , _popperElement set run , it relocation to right position.

the old version https://github.com/kybishop/ember-popper/blob/v0.9.2/addon/components/ember-popper-base.js#L272 is work well

This line in ember-popper-base.js triggers deprecation warnings in Ember 3.4.

Can we change it to this.registerAPI(this._getPublicAPI()), given that closure actions are the way now and sendAction is deprecated?

I note the eslint-disable ember/closure-actions currently applied, not sure if there was a rationale for this though.

We should have a test for each option that we can pass into ember-popper. For things already heavily tested in popper.js, like placement, a simple smoke test to ensure that the option is passed through correctly should suffice.

Caveat: No jquery please.

• eventsEnabled (smoke test) [#26]
• modifiers (smoke test) [#25]
• placement (smoke test) [#22]
• popperClass (smoke test is acceptable for this since it is so simple) (nixing this since we plan to use class instead of popperClass)
• popperContainer [#21]
• renderInPlace [#21]
• target [#24]

If you'd like to tackle one of these tests, leave a comment mentioning that you are working on it

To prevent things like #64

Hi, and thank for this ember wrapper of the lib.

At the moment it works nicely, except I was wondering how can I add preventOverflow with boundaries (.ember-application in our case)?

Thanks.

See:

• https://travis-ci.org/kaliber5/ember-bootstrap/jobs/275222245
• 

Looks as if the use of ES6 classes extending from Ember.Component is not working here. Not sure why, maybe even some general issue outside the scope of ember-popper?

Ember 2.11

While invoking <EmberPopper> with Angle Brackets works ootb, applying arbitrary attributes (<EmberPopper role="menu">) to the wormholed element does not. Currently only a few selected attributes are supported, and only when passing them as props (see https://github.com/kybishop/ember-popper/blob/master/addon/templates/components/ember-popper.hbs#L8). Supporting the former would require the use of splattributes (...attributes) here.

This in turn requires the use of https://github.com/rwjblue/ember-angle-bracket-invocation-polyfill, which would enable support, but only back to Ember 2.12. So the question is if/when ember-popper should properly support Angle Bracket Invocation?

The ember-try test matrix only goes back to Ember 2.16, but IIRC this addon is supposed to support version back to Ember 1.13 (should be documented!). Or can we introduce a new version (breaking change) to add support and drop those older Ember versions?

I use Ember 2.18.1,

WARNING: ember-decorators (used in ember-popper): You have not installed @ember-decorators/babel-transforms. It has been extracted to a separate addon. See instructions for installation: https://github.com/ember-decorators/babel-transforms#readme

I install in my App

ember install @ember-decorators/babel-transforms

But warning show again.

Good morning,

Stack

+- ember: 2.4.6
+- ember-attacher: 0.13.0
    +- ember-popper: ^0.8.2,

Description

I suspect that ember-popper is not working on Safari 9.

The following code raises an exception in Ember:

function() {
    function e(e, t) {
        return !t || "object" != typeof t && "function" != typeof t ? e : t
    }
    function t(e, t) {
        e.prototype = Object.create(t && t.prototype, {
            constructor: {
                value: e,
                enumerable: !1,
                writable: !0,
                configurable: !0
            }
        }),
        t && (Object.setPrototypeOf ? Object.setPrototypeOf(e, t) : e.__proto__ = t)
    }
    var n = Ember.Mixin.create({
        extend: function() {
            if (Object.getPrototypeOf(this) === Function.prototype)
                return this._super.apply(this, arguments);
            var n = function(n) {
                function r() {
                    return e(this, (r.__proto__ || Object.getPrototypeOf(r)).apply(this, arguments))
                }
                return t(r, n),
                r
            }(this);
            Object.defineProperty(n, "name", {
                value: this.name || this.toString()
            });
            for (var r = 0; r < arguments.length; r++)
                Object.assign(n.prototype, arguments[r]);
            return n
        }
    });
    Ember.Object.reopenClass(n),
    n.apply(Ember.Component),
    n.apply(Ember.Service),
    n.apply(Ember.Controller),
    void 0 !== window.DS && void 0 !== DS.Model && n.apply(DS.Model)
}(),

The exception is on the defineProperty méthod. It says n already has the name property and that we are "Attempting to change value of a readonly property"

Digging deeper

When digging deeper into ember-popper I've seen that the components ember-popper and ember-popper-base are written with the ES6 extend word instead of using the typical Ember.Component.extend({ ... })

Interesting

My app includes tones of addons and popper is the only one using this notation for components.
There are other addons using the class Foo extend Bar syntax but never for components.
Maybe we should look into this.

1. Are you aware of any issue running ember-popper in Safari 9?

Hi, first of all thanks for this awesome plugin!

I have a project which needs sourcemaps in production builds.
It was working fine in [email protected] but stopped after upgrading to [email protected].
The build fails if I build for production with sourcemaps enabled (in ember-cli-build.js):

$ ember build -e production
cleaning up...
Build failed.
The Broccoli Plugin: [Fingerprint] failed with:
Error: ENOENT: no such file or directory, open '/Users/.../popper-test/tmp/uglify_writer-input_base_path-1o0lRxYB.tmp/assets/popper.js.map'
    at Error (native)
    at Object.fs.openSync (fs.js:642:18)
    at Object.fs.readFileSync (fs.js:510:33)
    at UglifyWriter.processFile (/Users/.../popper-test/node_modules/broccoli-uglify-sourcemap/index.js:101:41)
    at /Users/.../popper-test/node_modules/broccoli-uglify-sourcemap/index.js:65:16
    at Array.forEach (native)
    at /Users/.../popper-test/node_modules/broccoli-uglify-sourcemap/index.js:55:25
    at Array.forEach (native)
    at UglifyWriter.build (/Users/.../popper-test/node_modules/broccoli-uglify-sourcemap/index.js:54:19)
    at /Users/.../popper-test/node_modules/broccoli-plugin/read_compat.js:93:34

I have a reproduction here: urbany/ember-popper-sourcemaps-error
You can see the error with: ember build -e production

This reproduction is a new ember app with just these changes: urbany/ember-popper-sourcemaps-error@9926b34

I also added an issue here, not sure if this problem is on emper-popper or on the ember-cli pipeline: ember-cli/ember-cli-terser#29 (comment)

Thanks in advance!

EDIT:
After a closer look I can see that in /Users/.../popper-test/tmp/uglify_writer-input_base_path-1o0lRxYB.tmp/assets/vendor.js still has this: //# sourceMappingURL=popper.js.map, this should probably be stripped since the popper.js.mapis already concatenated in the vendor.map

I have disabled the optional application-template-wrapper feature like so in my optional-features.json:

{
  "application-template-wrapper": false
}

When I then try to trigger a popper dropdown with renderInPlace=false, I get this error (only in test mode, via ember-bootstrap):

Uncaught Error: Assertion Failed: ember-popper with popperContainer selector "#ember-bootstrap-wormhole" found 0 possible containers when there should be exactly 1

The DOM is not getting the wormhole container element appended to it in tests, though everything works fine in my app in dev / production. I have to do renderInPlace=false because otherwise the menu is positioned incorrectly, which might be another issue (shown here ember-bootstrap/ember-bootstrap#570 (comment))

It turns out removing the RAF wrapper from this._updatePopper() in didUpdateAttrs has an unintended consequence of running this._updatePopper() before a rerender.

This is only an issue when toggling renderInPlace, which causes this._getPopperElement to return the about-to-be-destroyed <div> instead of the one being created due to the toggling.

Similarly, the public API returned from registerAPI returns the incorrect popperElement.

Quite obnoxious that a number of tests keep losing their determinism....

Hope to investigate this so I can stop pressing the restart button in Travis.

I have nested overlays:

{{#my-context-menu as |menu|}}
  {{#menu.button}}
    Download
    {{#ember-popper-targeting-parent class='tooltip'}}
      Download the thing
    {{/ember-popper-targeting-parent}}
  {{/menu.button}}

  {{#menu.button}}
    Delete
    {{#ember-popper-targeting-parent class='tooltip'}}
      Delete the thing
    {{/ember-popper-targeting-parent}}
  {{/menu.button}}
{{/my-context-menu}}

When the page first renders, all of those elements are in the DOM but hidden. That mean that this._initialParentNode is well defined, but this._initialParentNode.offsetParent is null. This causes the tooltip (popper content) to be aligned to the top-left of the screen.

If I open the context menu and then scroll or resize the viewport then the tooltip pops right into place.

There's no good way for the parent to inform the {{ember-popper-targeting-parent}} that its "rendering state" has changed. I also don't love the idea that calling contexts should be responsible for knowing about this limitation.

Unfortunately, the only solution I've come up with is to have {{ember-popper-targeting-parent}} (or ember-popper-base) call popper.scheduleUpdate() every X ms, which is wasteful for most cases.

It might be possible to do this with a mutation observer on the _initialParentNode, but I'm not sure that such an observer would fire if an ancestor of that element changes an attribute or style.

Possibly related: floating-ui/floating-ui#537

Popper v2 was officially released a week or two ago. I'm just opening this as a tracking issue to see if/when ember-popper would support it.

Hi, seems like there is a problem with the latest 0.10.0 release.

On my app, I always get that api._popperElement is undefined. I think this is because the API tries to get the _popperElement computed property before it returns.

1. the REF modifier sets the computed prop _popperElement in ember-popper-base.
2. Before that set returns, _updatePopperis called
3. at the end of _updatePopper, registerAPI is called with _getPublicAPI
4. Inside _getPublicAPI you are calling _getPopperElement which returns _popperElement.
5. Since the SET of _popperElement (point 1 abose) hasn't returned yet, it is still null.

Tested on [email protected] or even @3.9.

I am trying to figure out how to use @ember-decorators in a project consuming this addon. Because the import is still import { tagName } from 'ember-decorators/components, I am getting a build error because in my project, I am importing it like so: import { tagName } from '@ember-decorators/components (2.0.0-beta.1). Is there any way to resolve this other than forking and updating this addon to use the beta version of ember-decorators?

I think it would be a nice addition to support tagless components:

export default Ember.Component.extend({
  tagName: '',
});

Do you mind officially deprecating this project in favor of ember-style-modifier and ember-popperjs? I feel it would ease discovering up-to-date and actively maintained solutions.

One currently has to read the source to see how ember-popper works... we should really fix this.

Before I start working on a PR I wanted to discuss this here with you folks. I played a bit recently with this -in-element thing, and did this one: https://github.com/kaliber5/ember-in-element-polyfill. This together with https://github.com/DockYard/ember-maybe-in-element would allow to simplify the code base quite a bit.

Especially I think it would allow to drop all the special legacy handling here (effectively moving it to upstream dependencies), so we have just a single unified component that works with Ember 1.13+. The missing hash helper could be polyfilled with https://github.com/cibernox/ember-hash-helper-polyfill btw.

This however does not work all the way down to Ember 1.11. So before hitting stable, I wonder if the minimum Ember version could be raised to at least 1.13 (which is already quite antique! 😬). Some 0.x version could still be supported for Ember 1.11 (probably bug fixes only).

What do you think?

Oh no, me again with this crappy IE issues... 😬

As I said, I updated to the latest ember-popper, and things worked out well so far, but I see tests for IE11 (Saucelabs) failing with Types must either be a primitive type string, class, validator, or null or undefined, received: [object Element]. See https://travis-ci.org/kaliber5/ember-bootstrap/jobs/296004049#L2388

I have not digged deeper so far, but I assume the exception is thrown here, caused by type decorators like this. Seems IE11 is behaving differently here, probably Element is not of type "function"!?

One potential approach from @pzuraq:

https://github.com/pzuraq/liquid-wormhole/blob/master/addon/components/liquid-wormhole.js#L20-L32
https://github.com/pzuraq/liquid-wormhole/blob/master/addon/components/liquid-wormhole.js#L44

We're going to be using Popper.js for our app, but since we're on a legacy version of Ember at the moment we can't use this addon (and probably won't be able to use it until that Glimmer render-in-place helper arrives). However, we would like to match the external API of this component with our internal implementation so that when that time comes, we can swap it out and start contributing back.

The current API is pretty simple and not really easy to use with pre-Ember 2.4(?) apps - basically any without the hash helper, because options is difficult to specify declaratively otherwise. We can't even really polyfill the hash helper because in 1.8/1.11, single word helpers are a bit of a pain 😕

I don't think it would be too unreasonable to follow ember-tethers pattern of adding the top level options as properties of the component, but requiring them to be passed in as objects below that. So a configuration currently like so:

{{#ember-popper options=(hash placement="top" modifiers=(hash offset=(hash offset="10px")))}}

Would become:

{{#ember-popper placement="top" modifiers=(hash offset=(hash offset="10px"))}}

There are only 3 top level options for Popper, so this would be a pretty minimal API to maintain. If Popper decides to change its public API dramatically, we could follow suite with a major/minor version bump. I also think this would be a lot better for developer ergonomics - the bottom example is much easier to read and understand.

do you need maintainers here as well?

Wanted to start a discussion on 1.0. There is no rush on this, but it seems like we have a pretty solid API and, as a result, 1.0 shouldn't be far off.

Things I see as blockers:
1. Discuss and come to a final decision on closure actions vs sendAction approach for onFoundTarget.
2. A barebones github.io dummy app (maybe steal something similar to kybishop/ember-attacher?)
3. Update the README.md

EDIT: We will go to v1.0.0 once we go 2 months without a breaking change or major concern. From there we will follow strict semver.

Ember-popper relies on Glimmer's {{#-in-element}} component, which only exists in 2.10 and up.

I'd like to add legacy support via a similar strategy as ember-tether uses, where elements are manually moved to the document body.

The legacy implementation must not affect performance of the standard implementation. This means having two separate implementations and conditionally requiring the correct one at build time.

#80 dropped support for node 4, at least it declared so in its package.json. While EOL is just in a few days, any addons building on top of ember-popper that follow SemVer and have reached a stable version (>1.0) would have to do a major version bump to drop support for it, which is not always desirable.

This currently at least breaks installation of this addon and any other having it as a dependency under node 4 (without the --ignore-engines flag), e.g here: https://travis-ci.org/simplabs/ember-validated-form-buffer/builds/370595623#L531

Is there any good reason for requiring node 6? At first sight, I don't see any code in node-land requiring node 6 features, not here and also not in ember-decorators, which as of 2.0 also requires 6+. So a fix could be as simple as updating engines (and probably travis.yml).

/cc @pzuraq @Turbo87

Great addon 👍

Any chance y'all have played with this + Ember Animated yet? Or what the animation story might be?

Hi,

According to the Popper.js doc and some tests, popper.js handle some placement like bottom-start.

https://codepen.io/anon/pen/Ozrrmr

In your source you limit the placement to the main value

Placement of the popper. One of ['top', 'right', 'bottom', 'left'].

Is there a reason? Are these placement values should work even if it's undocumented?

Thanks

Instructions

1. Clone ember-popper
2. npm install
3. npm install ember-cli-fastboot --save-dev
4. ember serve (depreciated ember fastboot --serve-assets)

ReferenceError: navigator is not defined
    at /home/swerner/development/ember-popper/tmp/src/popper/utils/debounce.js:7:20
    at nativeHints (/home/swerner/development/ember-popper/tmp/broccoli_merge_trees-output_path-G2ltQSK1.tmp/assets/vendor.js:62757:19)
    at /home/swerner/development/ember-popper/tmp/broccoli_merge_trees-output_path-G2ltQSK1.tmp/assets/vendor.js:62758:2
    at ContextifyScript.Script.runInContext (vm.js:32:29)
    at VMSandbox.eval (/home/swerner/development/ember-popper/node_modules/fastboot/src/vm-sandbox.js:14:14)
    at /home/swerner/development/ember-popper/node_modules/fastboot/src/ember-app.js:142:15
    at Array.forEach (native)
    at EmberApp.loadAppFiles (/home/swerner/development/ember-popper/node_modules/fastboot/src/ember-app.js:139:21)
    at EmberApp.retrieveSandboxedApp (/home/swerner/development/ember-popper/node_modules/fastboot/src/ember-app.js:187:10)
    at new EmberApp (/home/swerner/development/ember-popper/node_modules/fastboot/src/ember-app.js:50:21)
    at FastBoot._buildEmberApp (/home/swerner/development/ember-popper/node_modules/fastboot/src/index.js:114:17)
    at new FastBoot (/home/swerner/development/ember-popper/node_modules/fastboot/src/index.js:52:10)
    at app.use (/home/swerner/development/ember-popper/node_modules/ember-cli-fastboot/index.js:233:29)
    at Layer.handle [as handle_request] (/home/swerner/development/ember-popper/node_modules/express/lib/router/layer.js:95:5)
    at trim_prefix (/home/swerner/development/ember-popper/node_modules/express/lib/router/index.js:317:13)
    at /home/swerner/development/ember-popper/node_modules/express/lib/router/index.js:284:7
    at Function.process_params (/home/swerner/development/ember-popper/node_modules/express/lib/router/index.js:335:12)
    at next (/home/swerner/development/ember-popper/node_modules/express/lib/router/index.js:275:10)
    at err (/home/swerner/development/ember-popper/node_modules/ember-cli/lib/tasks/server/middleware/broccoli-watcher/index.js:54:11)
    at watcher.then.errorHandler.buildError (/home/swerner/development/ember-popper/node_modules/broccoli-middleware/lib/watcher-middleware.js:35:7)
    at tryCatch (/home/swerner/development/ember-popper/node_modules/rsvp/dist/lib/rsvp/-internal.js:216:12)
    at invokeCallback (/home/swerner/development/ember-popper/node_modules/rsvp/dist/lib/rsvp/-internal.js:231:13)
    at /home/swerner/development/ember-popper/node_modules/rsvp/dist/lib/rsvp/then.js:29:16
    at flush (/home/swerner/development/ember-popper/node_modules/rsvp/dist/lib/rsvp/asap.js:85:5)
    at _combinedTickCallback (internal/process/next_tick.js:73:7)
    at process._tickCallback (internal/process/next_tick.js:104:9)

References

• Build Hooks for FastBoot
• Fastboot Addon Author Guide Depreciated in RC/1.0 EMBER_CLI_FASTBOOT

I am working on a pull request for ember-popper and ember-attacher to eliminate errors thrown in fastboot sandbox.

@pzuraq I've bisected this down to #61:

V0.7.3

➜  ember-popper git:(5d031c5) ember b -prod
WARNING: ember-legacy-class-transform: this transform is not needed for Ember >= 2.13.0
ember-hash-helper-polyfill is not required for Ember 2.3.0 and later, please remove from your `package.json`.
ember-hash-helper-polyfill is not required for Ember 2.3.0 and later, please remove from your `package.json`.
ember-hash-helper-polyfill is not required for Ember 2.3.0 and later, please remove from your `package.json`.
ember-hash-helper-polyfill is not required for Ember 2.3.0 and later, please remove from your `package.json`.
ember-hash-helper-polyfill is not required for Ember 2.3.0 and later, please remove from your `package.json`.
ember-hash-helper-polyfill is not required for Ember 2.3.0 and later, please remove from your `package.json`.
cleaning up...
Built project successfully. Stored in "dist/".
File sizes:
 - dist/assets/dummy-0498d5344068281ae25a84205deabf7c.js: 8.63 KB (2.55 KB gzipped)
 - dist/assets/dummy-04ad0b8807db6a44a4fbc070768fcf27.css: 1.39 KB (432 B gzipped)
 - dist/assets/dummy-fastboot-5bad6a103a3f7783d3db00e9f1787319.js: 1.32 KB (677 B gzipped)
 - dist/assets/vendor-9cd6ee7f80b6324e550180c1c094ec30.js: 546.9 KB (138.52 KB gzipped)
 - dist/assets/vendor-d41d8cd98f00b204e9800998ecf8427e.css: 0 B

v0.8.0

➜  ember-popper git:(5751335) ember b -prod
WARNING: ember-legacy-class-transform: this transform is not needed for Ember >= 2.13.0
ember-hash-helper-polyfill is not required for Ember 2.3.0 and later, please remove from your `package.json`.
ember-hash-helper-polyfill is not required for Ember 2.3.0 and later, please remove from your `package.json`.
ember-hash-helper-polyfill is not required for Ember 2.3.0 and later, please remove from your `package.json`.
ember-hash-helper-polyfill is not required for Ember 2.3.0 and later, please remove from your `package.json`.
ember-hash-helper-polyfill is not required for Ember 2.3.0 and later, please remove from your `package.json`.
ember-hash-helper-polyfill is not required for Ember 2.3.0 and later, please remove from your `package.json`.
cleaning up...
Build failed.
The Broccoli Plugin: [BroccoliMergeTrees: Addon#compileAddon(ember-popper) ] failed with:
Error: ember-popper/components/ember-popper-base.js: Cannot find the path for removal, please open issue with code example and the stack trace on Github: https://github.com/ember-cli/babel-plugin-filter-imports
    at findReferenceRemovalPath (/Users/kybishop/github/ember/ember-popper/node_modules/babel-plugin-filter-imports/lib/findReferenceRemovalPath.js:19:9)
    at /Users/kybishop/github/ember/ember-popper/node_modules/babel-plugin-filter-imports/lib/removeReferences.js:34:62
    at arrayEach (/Users/kybishop/github/ember/ember-popper/node_modules/lodash/lodash.js:537:11)
    at Function.forEach (/Users/kybishop/github/ember/ember-popper/node_modules/lodash/lodash.js:9359:14)
    at removeReferences (/Users/kybishop/github/ember/ember-popper/node_modules/babel-plugin-filter-imports/lib/removeReferences.js:33:20)
    at /Users/kybishop/github/ember/ember-popper/node_modules/babel-plugin-filter-imports/lib/index.js:51:49
    at arrayEach (/Users/kybishop/github/ember/ember-popper/node_modules/lodash/lodash.js:537:11)
    at Function.forEach (/Users/kybishop/github/ember/ember-popper/node_modules/lodash/lodash.js:9359:14)
    at PluginPass.ImportDeclaration (/Users/kybishop/github/ember/ember-popper/node_modules/babel-plugin-filter-imports/lib/index.js:50:26)
    at newFn (/Users/kybishop/github/ember/ember-popper/node_modules/babel-traverse/lib/visitors.js:276:21)

The broccoli plugin was instantiated at:
    at BroccoliMergeTrees.Plugin (/Users/kybishop/github/ember/ember-popper/node_modules/broccoli-plugin/index.js:7:31)
    at new BroccoliMergeTrees (/Users/kybishop/github/ember/ember-popper/node_modules/ember-cli/node_modules/broccoli-merge-trees/index.js:16:10)
    at Function.BroccoliMergeTrees [as _upstreamMergeTrees] (/Users/kybishop/github/ember/ember-popper/node_modules/ember-cli/node_modules/broccoli-merge-trees/index.js:10:53)
    at mergeTrees (/Users/kybishop/github/ember/ember-popper/node_modules/ember-cli/lib/broccoli/merge-trees.js:85:33)
    at Class.compileAddon (/Users/kybishop/github/ember/ember-popper/node_modules/ember-cli/lib/models/addon.js:1092:12)
    at Class.treeForAddon (/Users/kybishop/github/ember/ember-popper/node_modules/ember-cli/lib/models/addon.js:746:26)
    at Class.treeForAddon (/Users/kybishop/github/ember/ember-popper/index.js:111:37)
    at Class.superWrapper [as treeForAddon] (/Users/kybishop/github/ember/ember-popper/node_modules/core-object/lib/assign-properties.js:34:20)
    at Class._treeFor (/Users/kybishop/github/ember/ember-popper/node_modules/ember-cli/lib/models/addon.js:557:33)
    at Class.treeFor (/Users/kybishop/github/ember/ember-popper/node_modules/ember-cli/lib/models/addon.js:517:21)

I'll dig into this tomorrow if you don't snag it first.

I feel like we've been bitten by this kind of thing before, but don't end up seeing it because it is contained in production-only code. I'll see about having some kind of clever test that sets a specific env which just makes sure production builds don't error.