Wicket
  1. Wicket
  2. WICKET-5154

Positioning of autocomplete popup does not take into account borders

    Details

    • Type: Bug Bug
    • Status: Resolved
    • Priority: Major Major
    • Resolution: Fixed
    • Affects Version/s: 6.6.0
    • Fix Version/s: 6.8.0
    • Component/s: wicket-extensions
    • Labels:
      None

      Description

      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.

      1. test.html
        0.3 kB
        Andrei Badea
      2. wicket-5154.diff
        5 kB
        Andrei Badea

        Activity

        Hide
        Martin Grigorov added a comment -

        Thanks for the patch, Andrei!

        Show
        Martin Grigorov added a comment - Thanks for the patch, Andrei!
        Hide
        Andrei Badea added a comment -

        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.

        Show
        Andrei Badea added a comment - 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.
        Hide
        Andrei Badea added a comment -

        Proposed fix

        Show
        Andrei Badea added a comment - Proposed fix
        Hide
        Martin Grigorov added a comment -

        Yes. A new setting will make it easier for applications in production to adapt.

        By the way, you may want to check https://github.com/ivaynberg/wicket-select2. More and more people use this component.

        Show
        Martin Grigorov added a comment - Yes. A new setting will make it easier for applications in production to adapt. By the way, you may want to check https://github.com/ivaynberg/wicket-select2 . More and more people use this component.
        Hide
        Andrei Badea added a comment -

        I can provide a patch for the clientTop/clientLeft solution if wanted. Since this has the potential of breaking other users due to browser bugs, should there be a new setting for it in AutoCompleteSettings?

        Show
        Andrei Badea added a comment - I can provide a patch for the clientTop/clientLeft solution if wanted. Since this has the potential of breaking other users due to browser bugs, should there be a new setting for it in AutoCompleteSettings?
        Hide
        Andrei Badea added a comment -

        Attaching a HTML file that helps to reproduce the problem. Display in browser and, using Firebug or the Chrome Dev Tools, display the clientLeft and offsetLeft DOM properties of the td element that contains "Test".

        Show
        Andrei Badea added a comment - Attaching a HTML file that helps to reproduce the problem. Display in browser and, using Firebug or the Chrome Dev Tools, display the clientLeft and offsetLeft DOM properties of the td element that contains "Test".

          People

          • Assignee:
            Martin Grigorov
            Reporter:
            Andrei Badea
          • Votes:
            0 Vote for this issue
            Watchers:
            2 Start watching this issue

            Dates

            • Created:
              Updated:
              Resolved:

              Development