-
Notifications
You must be signed in to change notification settings - Fork 6.7k
Position of select element not determined correctly #5354
Comments
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. |
@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 |
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. |
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. |
@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_ Just let me know which property you prefer to check and I can create a PR. |
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
The text was updated successfully, but these errors were encountered: