Skip to content
This repository has been archived by the owner on May 29, 2019. It is now read-only.

Position of select element not determined correctly #5354

Closed
PascalK opened this issue Jan 27, 2016 · 5 comments
Closed

Position of select element not determined correctly #5354

PascalK opened this issue Jan 27, 2016 · 5 comments

Comments

@PascalK
Copy link

PascalK commented Jan 27, 2016

This behaviour exposed itself when i was using the popover functionality but i believe it is caused by the position module.

When i place a popover on an select element, the position of the popover is not determined correctly.
See this demo:
In chrome / IE: When you hover over the select element the popover is placed in the top left corner of the (absolute positioned) form element.
In FireFox: it is placed differently but still not in the correct position.

After some investigation it looks like this is caused by the position module. The getRawNode function tries to get the first array element of the parameter which works in most cases because if it is a jq object this will get the raw element but for (raw) select elements this will get the first option element within the select element. After that the position of this option element can not be determined correctly.

An easy fix would be to make the getRawNode function aware of this exception but since this is a function in the core of this framework which is called quite often i can imagine there might be a better approach in solving this.

When i overwrite the getRawNode with a (naive) fix the position is determined as expected as can be seen in this demo

@wesleycho
Copy link
Contributor

Thanks for this clear reproduction!

@RobJacobs any thoughts on where to fix this best? I don't think modifying the getRawNode function is a great idea, but perhaps a check afterwards to see what type of element it is before traversing to the parent may be appropriate.

@RobJacobs
Copy link
Contributor

@wesleycho I'm not opposed to adding that check although I find it odd that there is a problem with that approach. Angular material (among several other libraries) uses the same implementation:

https://github.com/angular/material/blob/master/src/core/util/util.js#L751

@wesleycho
Copy link
Contributor

They seem to have a restriction that tooltips can only be nested under the element it describes, so they can avoid this problem completely by never encountering the scenario.

@wesleycho
Copy link
Contributor

One workaround for now is to wrap the select element in a div and use the tooltip on that.

We should probably figure out how to fix this in the service though.

@RobJacobs
Copy link
Contributor

@wesleycho I think adding the extra check is acceptable. @PascalK proposed fix looks for the tagName property to be present where angular checks the nodeName property:

https://github.com/angular/angular.js/blob/master/src/Angular.js#L697

So I would lean towards following what angular is doing.

_EDIT_
Relevant SO post on tagName vs nodeName: http://stackoverflow.com/questions/4878484/difference-between-tagname-and-nodename

Just let me know which property you prefer to check and I can create a PR.

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

No branches or pull requests

3 participants