[#23244] - Calendar off screen detection broken when window scrolled
- Fixed in Code Base
- 18 Dec 2018
- Medium
- Build: staging
- # 23244
- Diff
- cheesegrits:cheesegrits-patch-1
User tests: Successful: Unsuccessful:
Pull Request for Issue #23243.
Summary of Changes
Fix for bounds detection in the calendar field. Currently, calendar fields at the bottom of the viewport will be opened off screen, if the window has been scrolled down.
See #23243
Testing Instructions
Add a calendar field to a long form, for example the Options fieldset in the com_content backend. Around line 604 in administrator/components/com_content/models/forms/article.xml, just before the close fieldset, add ...
<field
name="foobar"
type="calendar"
label="foobar"
description="foobar"
translateformat="true"
showtime="true"
size="22"
filter="user_utc"
/>
Now edit an article, switch to the Options tab and scroll down so the new 'foobar' date field is at the bottom of the window. Open the calendar widget.
Expected result
Widget should open above the field, fully visible
Actual result
Widget opens below the field, mostly off screen.
Apply this PR, and the widget will open correctly, above the field. No other behavior is changed, dates on non scrolled pages, or near the top of the viewport, are not affected.
Documentation Changes Required
none
| Status | New | ⇒ | Pending |
joomla-cms-bot
- | Category | ⇒ | JavaScript |
| Title |
|
||||||
Please apply the same change to calendar.min.js.
What minifier should I use?
There isn't a standard one for 3.x, the last time I did something with JavaScript on 3.x I used https://jscompress.com/
| Labels |
Added:
?
|
||
OK, I finally took the time to figure out how to minify automagically in PHP Storm. Used uglifyjs which is what I use for my component (although I do it in a Grunt build script, as our paths get a bit too complicated to do on the fly).
The result seems to be a little larger than the original, not sure what it was originally compressed with, but nothing major.
I have tested this item
OK here, although I do not have the issue on Firefox Macintosh.
Before patch:
After patch
This comment was created with the J!Tracker Application at issues.joomla.org/tracker/joomla-cms/23244.
I have tested this item
OK here, although I do not have the issue on Firefox Macintosh.
This comment was created with the J!Tracker Application at issues.joomla.org/tracker/joomla-cms/23244.
Difference with using https://jscompress.com/ is a bit much imho as it is around 4-5KB
@infograf768 OK, I'll redo the minification.
Also, the issue kind of depends on browser and surrounding CSS. The example you posted, your browser has resized the container the calendar is in and made the page longer to accommodate it (and probably auto-scrolled the page to bring it into view). But some browsers won't do that, and some front end site templates (like Gantry) prevent the container being auto-resized, so the calendar literally becomes inaccessible.
I use this one: https://skalman.github.io/UglifyJS-online/
I'm just reluctant to use online minifiers, as there's no way to tell if malicious code is being injected. So I'm dicking around with a few options in PHP Storm, see if I can get the size down a bit.
@infograf768 - OK, back down to 25k, the original size.
I have tested this item
This comment was created with the J!Tracker Application at issues.joomla.org/tracker/joomla-cms/23244.
I have tested this item
This comment was created with the J!Tracker Application at issues.joomla.org/tracker/joomla-cms/23244.
I have tested this item
This comment was created with the J!Tracker Application at issues.joomla.org/tracker/joomla-cms/23244.
I have tested this item
This comment was created with the J!Tracker Application at issues.joomla.org/tracker/joomla-cms/23244.
| Status | Pending | ⇒ | Ready to Commit |
RTC
This comment was created with the J!Tracker Application at issues.joomla.org/tracker/joomla-cms/23244.
| Status | Ready to Commit | ⇒ | Fixed in Code Base |
| Closed_Date | 0000-00-00 00:00:00 | ⇒ | 2018-12-18 02:42:40 |
| Closed_By | ⇒ | mbabker | |
| Labels |
Added:
?
|
||
Thanks, guys 'n' gals.
Just to be clear, the issue is that getBoundingClientRect() returns coordinates relative to top left of the viewport, not the document:
https://developer.mozilla.org/en-US/docs/Web/API/Element/getBoundingClientRect
... so scrollY should not be added to the window's innerHeight when comparing that with the bottom of the calendar's container.