sir-dunxalot / ember-tooltips Goto Github PK

Just a quick suggestion: CSS classNames like 'right', 'left', 'in', and even 'tooltip' are pretty broad and can easily conflict with an existing codebase. Fwiw, in our case, many of these classNames are already widely used utility classes in our app. It would be great to have a simple namespace prefixed to all of them, so they become 'ember-tooltips-right', 'ember-tooltips-left', etc., or something similar. Thanks for sharing this cool lib.

Hey, sorry for the drive-by issue opening! Thanks a lot for taking the time to build this addon and put in all the hard work of maintaining it.

I was wondering if you wouldn't mind adding a CHANGELOG.md and document some of the changes? It took me a little time to work through where to find the 2.0.0 release (not in a PR, a separate commit) and the changes associated with it. 2.0.0 is a big bump so some documentation around it would be good.

You can then suggest that new changes to the code base require a corresponding change to the CHANGELOG, and then you can accumulate and reorganize those when you publish releases.

I wish I had time to help more on this issue, so apologies again for making a request for more of your time without helping personally. Feel free to reject this request, but thought it might help!

I have the following element inside a component:

<a class="btn btn--grade has-tooltip"
    {{action "grade"}}
    data-tooltip-content={{gradeTooltipText}}>
  {{!-- button content... --}}
</a>

The component, on didInsertElement, calls this.renderChildTooltips();, which works great. However, when the data-tooltip-content attribute changes, the content of the tooltip itself doesn't change.

Subsequent calls to this.renderChildTooltips() doesn't re-render the existing tooltip - it just creates another tooltip with the new content, the old one still existing.

Is there a method I can call to destroy and re-render (or update) all tooltips? Or is this just a case that isn't covered yet?

I am doing the following:

renderTooltip(element, {
      content,
      effectClass: 'grow',
      hideOn: 'click',
      place: 'top',
      showOn: 'click',
      typeClass: 'light'
    });

However, the tooltip remains the dark 'none' style. Am I doing something wrong? I noticed that the darsain library seems to use classes like light and success but it appears this addon is adding tooltip- in front of the classes maybe?

I can't actually look at the markup for the tooltip because I can't figure out how to keep them open with dev tools open.

tooltipVisibilityDidChange and tooltipContentDidChange should be private methods.

Having an issue using tooltipEvent and tooltipVisibility based on a property... When the property is false (in my case, setting false on deactivate) it does not close the tooltip, and it is stranded on the page.

Is there a method I could call on deactivate to close any tooltips that may be open?

Hey, guys! Is it possible to ember-tooltips does not add the title attr? Or at least, do not show two tooltips. One styled and the default one.

Hi

I try to use addon with ember 1.9.1 ( ember-cli 0.2.7 )
I try both

  "tooltips": {
    "setupInInitializer": true
  },
//and
  "tooltips": {
    "addTo": ["View", "Component"]
  },

do nothing. I even can't find addon's code at developing tools ( and that's strange - cause it means that files are not included ) ( Of course I restart my app on config changes )

Can you help?

Thx

npm WARN peerDependencies The peer dependency [email protected] included from ember-tooltips will no
npm WARN peerDependencies longer be automatically installed to fulfill the peerDependency
npm WARN peerDependencies in npm 3+. Your application will need to depend on it explicitly.

Does this mean we should start depending on the dependency explicitly ourselves?

Hi,

I didn't see any demo examples of a clickable link in the content of a tooltip - is this currently possible? I tried adding an anchor tag to the content but it's not clickable, presumably because the focus is not on the tooltip?

Thanks, and great addon!

Hi,

as the "keepInWindow" paramete doesn't work very reliable, how about implementing some more options for the "side" parameter? Something like "bottomleft", "bottomright" etc.
This way it would be possible to position the tooltip inside the window so that it should be completely visible in most cases.

Hi there,

After installing this plugin I'm getting a lot of CSP reports on the console saying:
Refused to evaluate a string as JavaScript because 'unsafe-eval' is not an allowed source of script in the following Content Security Policy directive. tooltip.js:210..

Is there any way to supress these messages without adding unsafe-eval to my CSP configuration?

I'm setting tooltipContent from the translation object (ember-i18n) which returns an SafeString object with the string property, which contains the actual message.

As a result from the tooltip I get an error message: Uncaught TypeError: Failed to execute 'appendChild' on 'Node': parameter 1 is not of type 'Node'. tooltip/index.js:225

As I was up upgrading this (fantastic!) addon, it looks like we have lost some granularity in positioning the tooltip (ie top-left, top-right, bottom-left, bottom-right). I think ember-tether can support these, and I'm happy to take a crack at implementing it in ember-tooltips but I wanted to check in first on your thoughts @sir-dunxalot. Thanks!

Tooltip content is not showing on infinite scrolled content.
it's working on first-page content but when infinite scrolling content comes it's not working on it.

View

import Ember from 'ember';
import TooltipsMixin from 'ember-tooltips/mixins/components/tooltips';

export default Ember.Component.extend(TooltipsMixin, {
    didInsertElement: function() {
        this.renderChildTooltips();
    }
});

and tooltip content structure,

<div class="has-tooltip" data-tooltip-content='test'>Test</div>

First off, this addon looks very promising and is much easier to use with ember than something like bootstrap tooltips. Secondly...I ran into a bunch of visual issues that I was hoping I could get some help with. I hope it's okay that I list several issues here.

1.) keepInWindow doesn't actually try to keep the tooltip inside the window...or maybe it just doesn't try as hard as the bootstrap tooltip addon?
An example: When I resize the window, the tooltip doesn't get resized to try to fit in.
If you look at the bootstrap example ( http://getbootstrap.com/javascript/#tooltips ) while resizing the page, you'll notice that the tooltip overflows to multiple lines and it does a pretty good job, to a certain extent, to stay inside the window.

2.) ember-tooltips don't get re-rendered between model changes
I've noticed that ember-tooltips always display well after I transition between different routes. However, in the case that I stay on the same route and substitute in different models, the tooltips stop showing up all together.
^ I hope this was descriptive enough. I think what I'm looking for is a functionality to force the ember-tooltips to re-init themselves.

3.) ember-tooltips don't always get displayed under the correct element even when setting a target
Consider the block like
{{#if yelpData.haveReviews}} <a id="yelp-anchor" href="{{yelpData.url}}" target="_blank" rel="noopener noreferrer"> <img src="{{yelpData.rating_img_url_large}}" id="yelp-rating" /> </a> {{#tooltip-on-element class="ember-tooltip" target="#yelp-anchor"}}{{yelpData.rating}} based on {{yelpData.review_count}} reviews{{/tooltip-on-element}} {{/if}}

where the tooltip is attached to #yelp-anchor. When I hover over the element the tooltip correctly comes up, but its position is way off.


Any help debugging this would be appreciated

Test helpers in some component integration tests should be exported from modules so consuming app developers can use the tooltip test helpers in their own apps.

• assertPosition
• assertVisibility
• Other options?

Hi guys,

First of all, thanks for this cool addon. Really easy to use unlike other addons I tried before.
I don't know if this really is an issue or a feature request, but I hope it's okay anyway.

My problem:
I'm rendering a table (100% width) with a varying amount of cells inside. Let's assume I have 5 cells and in each cell there is a {{#tooltip-on-element ...}} attached to an element.
As each row starts to render the cells one by one, the cells are growing after the tooltip inside was already rendered, so they are slightly moved to the side. If a resize the window, repositioning is taking effect and everything is fine.

Does anybody has a solution for this problem that comes out of the box?

Thanks in advance for having a look at my message! =)

I use ember liquid-fire which allows smooth transitions between routes. I have an action attached to input fields so that when a user presses the enter key within an input field, it takes them to a new route.

Unfortunately, the old tooltip for the input field (that no longer is present) remains on the screen and requires a hard refresh to remove.

If there could be a way to trigger a tooltip clear on transition change, that would solve this issue.

Hello,
The current build fails on canary. As the ember team is working towards the final 2.0.0 release, it would be good if we had support for canary.

Thanks,
Michael

Will there be an update of ember-tooltips suitable for Ember 2.0?

We have a massive codebase and are migrating to ember-tooltips for all our tooltip needs. In the past people have created tooltip classes for their one-off tooltip components. This means that a plain inclusion of this library will introduce many style conflicts to existing tooltips, and vice-versa. Right now our options are...

1. Fork our own PR with a temporary fix (extended the components, additional className for specificity, and add this in the library's styles .ember-tooltip.tooltip). We would need to keep this fork until we've deprecated all of our existing .tooltip class reliant components and instance.
2. Upgrade this library to use .ember-tooltip classes everywhere instead of .tooltip.

It seems that more specificity in naming conventions is better and that if this library were to use .ember-tooltip there would be less chance of similar roadblocks for large companies hoping to use it.

If this is an acceptable solution I can address it.

@MiguelMadero ^

Awesome component. Is it possible to position the pointer somewhere other than the center? Assuming I had a longer list, I'd prefer to have the arrow closer to the top of the tool tip box as opposed to the center.

Hi! First off, thanks for your work maintaining this addon.

Currently we're stuck on 0.7 until some of the parity loss from the old tooltips plugin (like #82) is regained. Hopefully we'll have a chance to help out with that stuff when time permits, but in the meantime we're having to monkey patch our way around deprecations and incompatibilities in Ember 2.8.

Would you be open to maintaining an 0.x branch for a while for folks stuck in the same boat as us? No new features or anything, just avoiding errors/deprecations as new Ember releases come out. If you're not opposed to the idea, I'd be happy to open up a PR to kick if off.

Hi,

We were using 0.5.9 and just upgraded and found that renderTooltip is no longer available. Is there an equivalent in 2.x? We're using the tooltips for event in FullCalendar, so there is no handlebars template for us to work with; we need an the option to use it programmatically.

Thanks for your hard work!

Hey, was a little perplexed as to why clicking on my target element was causing my tooltip visibility to toggle, given that I had set the visibility of the tooltip to manual.

After a combing through the code (very well written btw, great documentation) I found that ember-tooltips toggles visibility on focus for any event not set to "focus"; a little counter-intuitive, but the comment above made it clear that this was specifically for accessibility.

While I think the intent is clear and fair, the primary use case for "manual" is to have explicit control for when a tooltip needs to be present and I think this undermines the use case.

Might I suggest we change that line to:

if (event !== 'focus' && event !=='manual' && event!=='none') {

After installing it gives the following build error when ember s is run:

Merge error: file app.scss exists in /mnt/EmberCliRamdisk/ember-client/broccoli_merge_trees-input_base_path-RxstezkD.tmp/39 and /mnt/EmberCliRamdisk/ember-client/broccoli_merge_trees-input_base_path-RxstezkD.tmp/42
Pass option { overwrite: true } to mergeTrees in order to have the latter file win.

Removing the addon resolves it. So it's obvious that the above error happens due to this addon.

Ember-cli: 1.13.8
Ember: 1.13.10

If I add a tooltip to a link:

{{link-to "Somewhere" "some.where" tooltipContent="Go Somehwere"}}

then the tooltip shows up when I hover over the link (yay!). When I click the link, the tooltip disappears (yay!). But when I then move the mouse, it reappears (boo!).

I've set a debugger on Tooltip.prototype.show. It turns out that the mouseover event is getting fired on the <a> when it no longer is in the DOM. I think the simple solution is to guard in either Tooltip.prototype.show (an upstream library unfortunately) or in renderTooltip:

var willShow = tooltip.hidden && jQuery.contains(document, tooltip.element);

Hi

I like this library but would prefer that it didn't load code on every single one of my components and views. The code in the 'didInsertElement' is run for every element inserted in my app - all the time. This shouldn't be the default behaviour - or it should at least be able to be turned off.

Also - I see that you've actually got the code that is inserted on every view/component in the initializer - it would be better if this was a Mixin that could be imported separately.. Allowing the initializer to be turned off and providing a mixin would allow people to put the tooltip only on components they want..

If you are open to these suggestions I may spend time implementing them and doing a PR - let me know your thoughts.

It looks like the files concatenated together into vendor/tooltip/tooltip.js contain a deprecated sigil for sourcemap comments (@ vs #) which is producing the following warnings Chrome and similar ones in Firefox:

Having read through darsain/tooltip#28, it looks like the upstream author's stance amounts to:

"I'm not going to work on this until someone magically fixes package management, and I'm also not going accept PRs either because everyone else should also refuse to do work until that happens."

😒

Given that, would you consider just swapping in #s for the @s in the vendored file in this repo (or removing the comments entirely, since they don't actually point anywhere)?

Need to investigate why ember-beta tests are failing and fix them before 2.7 is released. Once fixed, we need to revert #84

cc: @sir-dunxalot @a15n @andrew-zenefits

When hovering immediately from one to another tooltip the show / hide functionality is not working properly. Sometimes the hide / show is reversed, so hovering over a tooltip hides the tooltip and when I'm not hovering it shows the tooltip.

Our application runs on Ember 1.13.10 and I tried ember-tooltips 0.5.2 and 0.4.0 but I'm seeing this behaviour in both versions. It doesn't matter if I use the tooltips as data-* attributes or as components / tooltip-on-parent component.

Looks like the addon is hiding the new tooltip when hovering immediately from one tooltip to another and the hide() method is triggered after the show() method.

It should be possible to set tooltips to close automatically after a certain duration

someProperty: Ember.computed(function() {
  return Ember.String.htmlSafe('some text');
})

{{link-to .... tooltipContent=someProperty}}

Then I get

Uncaught TypeError: Failed to execute 'appendChild' on 'Node': parameter 1 is not of type 'Node'.

This is notable because ember-i18n returns all translated strings as SafeStrings.

I have two ideas:

1. just stringify anything that comes in: tooltip.content('' + tooltipContent)
2. try to understand HTML safety and HTML-escape tooltipContent unless it's a SafeString

I think (2) is more correct than (1), but it may break some apps.

Hello and thanks for ember-tooltips. Any plans to bring in a Popover component?

Thank you.

The first if statement has backwards logic. Currently it is...

if (tooltip.hidden === shouldShow) { return; }

...when it should be...

if (tooltip.hidden !== shouldShow) { return; }

This is not causing issues because the ember-tooltips mixin is setting hidden to an integer (i.e. 1) in the vendor/tooltip.js file, so the if statement is never true. However, if it were using the updated tooltip JS file from https://github.com/darsain/tooltip (where it is set to true), this logic will break because of the triple equals.

Has anyone else came across this issue where something is requesting for /assets/ember-tooltips.css.map? I am using Ember-cli-rails by the way.

Started GET "/assets/ember-tooltips.css.map" for 127.0.0.1 at 2016-06-08 02:14:41 -0500
02:14:41 web.1  | 
02:14:41 web.1  | ActionController::RoutingError (No route matches [GET] "/assets/ember-tooltips.css.map"):
02:14:41 web.1  |   /usr/lib/ruby/vendor_ruby/action_dispatch/middleware/debug_exceptions.rb:21:in `call'
02:14:41 web.1  |   /usr/lib/ruby/vendor_ruby/action_dispatch/middleware/show_exceptions.rb:30:in `call'
02:14:41 web.1  |   /usr/lib/ruby/vendor_ruby/rails/rack/logger.rb:38:in `call_app'
02:14:41 web.1  |   /usr/lib/ruby/vendor_ruby/rails/rack/logger.rb:20:in `block in call'
02:14:41 web.1  |   /usr/lib/ruby/vendor_ruby/active_support/tagged_logging.rb:68:in `block in tagged'
02:14:41 web.1  |   /usr/lib/ruby/vendor_ruby/active_support/tagged_logging.rb:26:in `tagged'
02:14:41 web.1  |   /usr/lib/ruby/vendor_ruby/active_support/tagged_logging.rb:68:in `tagged'
02:14:41 web.1  |   /usr/lib/ruby/vendor_ruby/rails/rack/logger.rb:20:in `call'
02:14:41 web.1  |   /usr/lib/ruby/vendor_ruby/action_dispatch/middleware/request_id.rb:21:in `call'
02:14:41 web.1  |   /usr/lib/ruby/vendor_ruby/rack/methodoverride.rb:22:in `call'
02:14:41 web.1  |   /usr/lib/ruby/vendor_ruby/rack/runtime.rb:18:in `call'
02:14:41 web.1  |   /usr/lib/ruby/vendor_ruby/active_support/cache/strategy/local_cache_middleware.rb:28:in `call'
02:14:41 web.1  |   /usr/lib/ruby/vendor_ruby/rack/lock.rb:17:in `call'
02:14:41 web.1  |   /usr/lib/ruby/vendor_ruby/action_dispatch/middleware/static.rb:120:in `call'
02:14:41 web.1  |   /usr/lib/ruby/vendor_ruby/rack/sendfile.rb:113:in `call'
02:14:41 web.1  |   /usr/lib/ruby/vendor_ruby/rails/engine.rb:518:in `call'
02:14:41 web.1  |   /usr/lib/ruby/vendor_ruby/rails/application.rb:165:in `call'
02:14:41 web.1  |   /usr/lib/ruby/vendor_ruby/rack/content_length.rb:15:in `call'
02:14:41 web.1  |   puma (3.4.0) lib/puma/configuration.rb:224:in `call'
02:14:41 web.1  |   puma (3.4.0) lib/puma/server.rb:569:in `handle_request'
02:14:41 web.1  |   puma (3.4.0) lib/puma/server.rb:406:in `process_client'
02:14:41 web.1  |   puma (3.4.0) lib/puma/server.rb:271:in `block in run'
02:14:41 web.1  |   puma (3.4.0) lib/puma/thread_pool.rb:114:in `block in spawn_thread'
02:14:41 web.1  | 
02:14:41 web.1  | 
02:14:41 web.1  |   Rendered /usr/lib/ruby/vendor_ruby/action_dispatch/middleware/templates/rescues/_trace.html.erb (0.9ms)
02:14:41 web.1  |   Rendered /usr/lib/ruby/vendor_ruby/action_dispatch/middleware/templates/routes/_route.html.erb (4.2ms)
02:14:41 web.1  |   Rendered /usr/lib/ruby/vendor_ruby/action_dispatch/middleware/templates/routes/_table.html.erb (6.1ms)
02:14:41 web.1  |   Rendered /usr/lib/ruby/vendor_ruby/action_dispatch/middleware/templates/rescues/_request_and_response.html.erb (0.9ms)
02:14:41 web.1  |   Rendered /usr/lib/ruby/vendor_ruby/action_dispatch/middleware/templates/rescues/routing_error.html.erb within rescues/layout (40.1ms)

Let me know if there is any other information I can provide! Also, the Source Code is open source, and accessible at Deovandski/Fakktion

#36 fixed a bug causing tooltips to remain in the DOM after transitions.

We were unable to produce a consistently failing test for the bug before the PR was merged. Instead, we had to rely on manual testing. Whilst some test coverage for transitions was added, the tests passed before and after the PR.

We should have at least one test that fails at 0a8842e and passes at 31ab114.

In our app, we have a template that is binding to a component property that returns variable string values using Ember i18n. ember-tooltips works correctly with SafeStrings the first time the string is rendered, but if the property updates and returns a different value, the tooltip crashes. The first half of this issue was fixed in #30. I have a PR forthcoming...

This plugin adds a destroyTooltip: on('willDestroyElement', function () { method that is in the mixin that gets injected everywhere.

Inside there it says:

var tooltip = this.get('tooltip');

if (tooltip) {
  .... DO SOME CRAY STUFF THAT ONLY MY TOOLTIP RESPONDS TO
}

So, if you have a tooltip property, or worse yet, you are using someone else's add-on who has a tooltip property, your app will come to a screeching halt when you navigate away from that view.

The fix should be that this plugin uses a more specific name for that property that is less likely to conflict AND checks to see if the tooltip it gets back is, in fact, the type of tooltip you are expecting.

At the moment the remove-vendor-css branch breaks on render because ember-tether doesn't get installed. I believe that by making it a peer dependency that npm will warn the user to install it.
I could be wrong, who knows with npm sometimes ;P

Documentation could be expanded to include the renderTooltip util and other such parts that operate under the hood.

We need section 508 compliance for the tooltips (keyboard navigation to focusable elements in the tooltip). This requires support for:

1. clicks/hover
2. touchscreen taps
3. screen reader / keyboard navigation

Proposed solution:

The tooltip itself becomes a property on the ember component as well as an element in the DOM page. So we just need an event listener on focus [or above event] of the original element and then call this.get('tooltip').show() and focus on the tooltip element that was just shown

Hi there,

I'm just upgrading from version 0.7. Really enjoying what you've done with version 2! Feels so much more ember-y :)

We're using a number of tooltips that show on hover. Previously in v0.7, I was using the mixin and just wouldn't render the tooltips on mobile, but I was just wondering how I could set all of the tooltips not to show on mobile?

Is there something I could do to stop all tooltips from being created in mobile (my app knows when it is mobile) other than wrapping all of the {{#tooltip-on-element}} in {{#if}} blocks?

Maybe by extending the tooltip component?

I have an addon ui-button which I'd really like to use your addon for tooltips rather than Bootstrap's. I have added it to my template like this:

<button type="button" class="ui-button btn btn-{{mood}} {{_size}}">
  {{#if hasBlock}}
    {{yield}}
  {{else}}
    <span class="content">
      {{#if tooltip}}
        {{#tooltip-on-parent}}{{tooltip}}{{/tooltip-on-parent}}
      {{/if}}
      {{#if icon}}
      <span class="icon">
        {{ui-icon icon=icon spin=iconSpin pulse=iconPulse}}
      </span>
      {{/if}}
      {{#if title}}
      <span class="title">
        {{title}}
      </span>
      {{/if}}
    </span>
  {{/if}}
</button> 

However when add a tooltip I suddenly get two DEPRECATIONS (with rubbish debugging info):

If I take it out of the conditional {{#if}} block then I get 15 deprecations of the same variety. Furthermore my tooltip does not display though I did check and the parent element and it does indeed have the Tooltip object attached and with a config that looks good to me:

I think I can help with the DEPRECATIONS part, i'll send you a PR which I've already tested and it does indeed remove the deps. WRT, to the lack of a popup, however, I defer to your wisdom. Am I missing something?

Hey There,

Trying to use tooltips inside a Modal however they're not showing up consistently. If I open the modal and then hover over a tooltip, the tooltip isn't getting attached to the target element. However, when I open the inspector and then 'click' on the tooltip it gets activated next to the element. Do you know how I can get this to activate within the modal correctly every time?

      <div class='col-xs-12'>
        <label>Title</label>
          <span id='event_title' class='icon icon-question-mark'>
            {{#tooltip-on-element target='#event_title' side='right' spacing=20}}Enter a short, descriptive event title.{{/tooltip-on-element}}
          </span>
        {{focused-input value=model.title type="text" placeholder="Trip to the Mountains!" required=true}}
      </div>

And a couple images showing the two tooltips getting initialized:

addon/utils/render-tooltip takes an element as its first argument.

addon/mixins/components/tooltips#renderTooltip always passes this.get('element') as that argument.

I'd like to have a tooltip appear on something like this.$().closest('.tooltip-target') to have it appear on a parent element that isn't itself an Ember.Component that mixes in the TooltipsMixin:

<div class='tooltip-target'>
  {{my-component tooltip-content="Hello"}}
</div>

MyComponent = Ember.Component.extend({
  tooltipTarget: Ember.computed(function() {
    return this.$().closest('.tooltip-target');
  });
});

The title attribute is causing duplicate tooltips to show up.

In 0.6 I used ember-tooltips/utils/render-tooltip for my own custom component. It would parse text and render HTML which was injected through a computed property. I then used your renderTooltip using a jQuery .each().

With 1.0 this concept was completely removed. How can we attach a tool tip to elements that were injected directly into the DOM?

Use case: Server sends text, Ember wishes to decorate the text so I compiles the text into HTML with span tags in it. Component then attaches the tooltip to each span tag after it being rendered into the template with {{{compiledHtml}}}:

export default Ember.Component.extend({
  compiledHtml: Ember.computed('text', function() {
    return myCustomCompiler(this.get('text')).htmlSafe();
  }),
  didInsertElement() {
    this._super();
    this.$('span').each((index, el) => {
      renderTooltip(el, {…});
    });
  }
});