Details
-
Type:
Bug
-
Status: Closed
-
Priority:
Minor
-
Resolution: Fixed
-
Affects Version/s: EE-3.3.0.GA_P01, 4.0.BETA
-
Fix Version/s: EE-3.3.0.GA_P02, 4.0
-
Component/s: ACE-Components
-
Labels:None
-
Environment:HideICEfaces trunk rev# 36979 / 37828
EE-3.3.0.GA Maintenance Branch
Server: Tomcat7
Browser: all
Test app: http://server.ice:8888/svn/repo/qa/trunk/Regression-Icefaces2/Sparkle/Nightly/dateTimeEntryShowICEfaces trunk rev# 36979 / 37828 EE-3.3.0.GA Maintenance Branch Server: Tomcat7 Browser: all Test app: http://server.ice:8888/svn/repo/qa/trunk/Regression-Icefaces2/Sparkle/Nightly/dateTimeEntry
-
Assignee Priority:P2
Description
These issues cannot be reproduced in showcase.
1) when multiple dateTimeEntry pages are displayed (popup or inline component) - screen shot 1.png.
2) when the dateTimeEntry component is displayed inline for a single month (pages=1) - see attached 2.png.
Steps to reproduce:
- build and deploy the dateTimeEntry test application located here: http://server.ice:8888/svn/repo/qa/trunk/Regression-Icefaces2/Sparkle/Nightly/dateTimeEntry
- issue1) can be reproduced by loading in any browser http://localhost:8080/dateTimeEntry/calendarAttribute.jsf and opening the popup calendar on the demo page, without changing any of the attributes.
- issue2) can be seen by loading in any browser: http://localhost:8080/dateTimeEntry/calendarOnly.jsf
Last revision number where both issues pass is trunk rev# 36978.
On rev# 36979 only issue 1) dateTimeEntry with multiple pages - fails; issue 2) passes.
On rev# 37062 both issues 1) and 2) fail, but the wrong styling is different from what it is now with the current revision #
Activity
- All
- Comments
- History
- Activity
- Remote Attachments
- Subversion
Committed fix to trunk at revision 38041. Added display:inline-block styling to calendar and removed code from jQuery-UI to programmatically set datepicker width.
Icefaces3 trunk revision #38050
The popup calendar has styling issues in IE7 when it is rendered that are different to what was initially reported here. The calender is the size of the page, the hour/minute sliders are not being rendered correctly, and the cursor in the popup input can be seen flashing on top of the rendered calendar. See screenshot.
This can be reproduced on the Attribute test page in the same test app.
Committed fixes at revision 38060: added inline-block hacks for IE7; re-applied width calculations for IE7 only, using a longer width.
Minor styling issue still exists when calendars are side by side. Chrome, IE 9. Headers with dropdowns are vertically smaller, calendars are too close together. see screen: dateTimeChrome.PNG
Added more space between calendars at revision 38291.
Couldn't reproduce header height issue on any browser. Please check if you still see it.
The header that contains the select box is vertically smaller than the other 2 headers when 2 or 3 calendars are displayed side by side.
This can be seen in all browsers and has been reproduced on ICEPC4 as well as on my local machine by following the steps in the JIRA . see attached screenshot dateTimeEntryAlign.PNG
Committed fix for header issue to 3.3 EE maintenance branch at revision 40895. I could never reproduce this issue with the 4.0 trunk.
Modified the datepicker code to add a span with an "invisible" character (non-breaking space) to the first calendar header in order to align its height with the other headers that contain text. Also slightly reduced the width of the month-year drop-downs in order to make this character fit.
Confirmed fixed Icefaces ee-3.3.0 maintenance branch r40900. Tomcat 7, all browsers.
Attaching before-after screenshot.
The cause of the first issue is that revision 36979 (
ICE-9143) introduced some localisation changes, and the weekdays went from being displayed as "Su Mo Tu We Th Fr Sa" to being displayed as "Sun Mon Tue Wed Thu Fri Sat", taking more width, while the width of the container remained the same, as seen in the before-after screenshot.This issue is easily fixed with custom app styling, but this is prone to change depending on the locale. The names of the week and other labels could take more or less space. Perhaps, we could programmatically set the width of the container, based on the width of its inner elements. We could make this behaviour configurable as well.
The second issue started at revision 37048, when the fixed width of the container was removed from the CSS file, making the calendar take as much space as possible. Again, this is easily fixed at the app level, and if can also be fixed with the approach described in the previous paragraph.