[ 
https://issues.apache.org/jira/browse/WICKET-5154?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13640569#comment-13640569
 ] 

Andrei Badea commented on WICKET-5154:
--------------------------------------

Thanks for the mention of select2. It looks interesting (and visually much more 
pleasant), but I'll have to have a closer look at it.

The attached patch introduces a new flag to AutoCompleteSettings, called 
ignoreBordersWhenPositioning. For backward compatibility it is set to true. 
When set to false, it includes clientLeft and clientTop in position 
computations. This computes the position of the input field correctly in IE9+, 
Firefox 16 and Chrome 22. In IE8 (and, presumably, earlier) it does not: the 
offsetLeft and offsetTop properties of the input field seem to already contain 
the borders of the input field's parent element.

What's the preferred Wicket approach in these situations? Should I try to 
detect the browser and avoid including the borders even though the user asked 
to include them? Or should we expect the user to set the 
ignoreBordersWhenPositioning flag according to the browser vendor and version? 
I will note that the former might still not yield the expected results, because 
I don't fully understand the IE bug.

                
> Positioning of autocomplete popup does not take into account borders
> --------------------------------------------------------------------
>
>                 Key: WICKET-5154
>                 URL: https://issues.apache.org/jira/browse/WICKET-5154
>             Project: Wicket
>          Issue Type: Bug
>          Components: wicket-extensions
>    Affects Versions: 6.6.0
>            Reporter: Andrei Badea
>         Attachments: test.html, wicket-5154.diff
>
>
> In wicket-autocomplete.js function getPosition() is used to compute the 
> position of the input that the autocomplete is attached to. It uses the 
> offsetTop and offsetLeft DOM properties, which does not take the borders into 
> account. This causes the popup to be misplaced in all three browsers I have 
> tested: IE9, Firefox 16 and Chrome 22.
> A possible solution is to take the (non-standard) clientTop and clientLeft 
> properties into account, too.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

Reply via email to