Search and Top Navigation
#3863 closed bug (fixed)
Opened January 16, 2009 10:50PM UTC
Closed January 28, 2009 05:13AM UTC
Last modified January 17, 2010 06:03AM UTC
datepicker calendar renders at wrong vertical position
Reported by: | jezaustin | Owned by: | caphun |
---|---|---|---|
Priority: | critical | Milestone: | 1.7 |
Component: | ui.datepicker | Version: | 1.6rc5 |
Keywords: | datepicker position _checkOffset | Cc: | |
Blocked by: | Blocking: |
Description
On Firefox 3.0.5 & IE7, jQuery 1.3, jQuery-UI 1.6rc5, the datepicker calendar is rendered too high up in the document, and I must scroll up to find it. Seems to be going wrong in _checkOffset, where
// now check if datepicker is showing outside window viewpoint - // move to a better place if so. offset.left -= (offset.left + dpWidth > viewWidth && viewWidth > dpWidth) ? Math.abs(offset.left + dpWidth - viewWidth) : 0; offset.top -= (offset.top + dpHeight > viewHeight && viewHeight > dpHeight) ? Math.abs(dpHeight + inputHeight*2 - viewHeight) : 0;
I replaced with these lines, which butt the calendar up against the bottom and/or right edges of the view port if necessary.
if (offset.left + dpWidth > $(document).scrollLeft() + viewWidth && viewWidth > dpWidth) offset.left = $(document).scrollLeft() + viewWidth - dpWidth; if (offset.top + dpHeight > $(document).scrollTop() + viewHeight && viewHeight > dpHeight) offset.top = $(document).scrollTop() + viewHeight - dpHeight;
But I'm not super confident that I understood the purpose of the original code.
Attachments (1)
Change History (8)
Changed January 21, 2009 03:18PM UTC by comment:1
Changed January 23, 2009 11:03AM UTC by comment:2
priority: | major → critical |
---|
Changed January 24, 2009 05:03PM UTC by comment:3
The algorithm makes the incorrect implicit assumption that the page is located top left in the view point. If it is not, then the _checkOffset method will attempt to relocate the calendar upwards and/or leftwards to appear there.
On long pages where the visitor has scrolled down this can result in the calendar being moved so far upwards that it is rendered outside the actual current viewable area.
Changed January 27, 2009 04:58AM UTC by comment:4
owner: | → caphun |
---|---|
status: | new → accepted |
Changed January 27, 2009 10:54PM UTC by comment:5
Was about to submit new ticket when I found this one - I'm adding this link in case it assists in debugging.
Example (with ghastly html, I won't try to explain why!):
http://bookings.premiersport.org/admin/candidates/test-cand.html
Datepickers on date fields lower down the page appear higher than they should, most noticable on the very bottom one.
I've simplified as far as I could the HTML to narrow down testing issues, but as I strip out html, the problem diminishes.
The problem is more noticable on IE(7.0) than FF(3.0).
Changed January 28, 2009 05:13AM UTC by comment:6
resolution: | → fixed |
---|---|
status: | accepted → closed |
Fixed in r1820. Thank you Spir and chrisv for the test cases.
Changed January 16, 2010 12:49AM UTC by comment:7
I'm seeing a problem that may be similar to this, with 1.7.2 on top of jQuery 1.4. My input field is towards the top of an iframe, and the datepicker code gives it a "top" offset of -33 pixels for some reason.
Changed January 16, 2010 01:13AM UTC by comment:8
Replying to [comment:7 pointym5]:
I'm seeing a problem that may be similar to this, with 1.7.2 on top of jQuery 1.4. My input field is towards the top of an iframe, and the datepicker code gives it a "top" offset of -33 pixels for some reason.
No, my problem was different. The code in "_checkOffset" that tries to adjust for the datepicker spilling out of its viewable page area was deciding to slide the top of the datepicker 50 pixels to the north. I'm not sure why that's better than just letting me see the bottom of the datepicker box cut off; that would certainly have been less confusing. However it's not at all related to this issue.
I can confirm this bug with Firefox 3.0.5, jQuery 1.3, an UI 1.6rc5.
Datepicker instances on the top or middle of the page function as expected, but any instances which will clip the bottom of the viewport are placed near the top of the page.