Opened 12 years ago

Last modified 4 years ago

#3272 closed task

ComboBox: standardize dropdown placement — at Version 12

Reported by: bill Owned by: haysmark
Priority: high Milestone: 1.13
Component: Dijit - Form Version: 0.9
Keywords: Cc:
Blocked By: Blocking:

Description (last modified by bill)

The drop down list can flutter between being above and below the <input> box depending on how much room there is on each side _and_ how much data is in the list. As you type the position can switch.

Since our drop downs auto-size to the space available, let's make the drop down always go below the <input> box, unless the space below the input box is really cramped (say, less that 100px).

Change History (13)

comment:1 Changed 12 years ago by bill

Summary: Autocompleter/Select: standardize dropdown placementComboBox: standardize dropdown placement

comment:2 Changed 12 years ago by haysmark

EXT flutters too:

Fluttering is the industry standard; why deviate?

comment:3 Changed 12 years ago by Douglas Hays

I think always going to the largest area will prevent flutter, be easy to program, and minimize user scrolling.

comment:4 Changed 12 years ago by haysmark

Ok, so right now the placement code prioritizes placement based on a first come first serve basis. place is called with the bottom position first so that is why we see fluttering. If we removed that part of the code it would stick to the largest area.

comment:5 Changed 12 years ago by bill

The placement code works correctly for most drop downs, like Calendar or Menus. This is a special case because the drop down list is of a variable height (ie, unlike Calendar, it needs a scrollbar). So let's not change the drop down code for the general case.

As per Doug's suggestion to always go to the largest area, I posted to see what others thing. Like to get some more input on this.

Changed 12 years ago by haysmark

Attachment: 3272.patch added

place.js checks all possible popup positions to see where there is the most viewable space, making popup placement more consistent. Fixes #3272.

comment:6 Changed 12 years ago by haysmark

Bill I changed the patch I sent you. Because I removed the break in place.js I had to make sure tooltip-type popups exit the code with the "best" orientation at the end.

comment:7 Changed 12 years ago by haysmark

You know I'm concerned that my algorithm messes up the Menu test because any submenus that you open on the right half of the page appear to the left no matter what.

comment:8 Changed 12 years ago by haysmark

And similarly I think it would be really arbitrary for submenus to start popping to the left or on top when you still have 100px available to you.

comment:9 Changed 12 years ago by bill

Milestone: 1.02.0

comment:10 Changed 12 years ago by alex

Milestone: 2.01.3

Milestone 2.0 deleted

comment:11 Changed 11 years ago by bill

Milestone: 1.31.4

bumping 1.4 tickets to 1.5, and most 1.3 tickets to 1.4

comment:12 Changed 10 years ago by bill

Description: modified (diff)
Milestone: 1.4future
Note: See TracTickets for help on using tickets.