Bug 534739 (RHQ-1506) - Operations scheduling calendar widget expands past bottom of browser window
Summary: Operations scheduling calendar widget expands past bottom of browser window
Keywords:
Status: CLOSED CURRENTRELEASE
Alias: RHQ-1506
Product: RHQ Project
Classification: Other
Component: Core UI
Version: 1.2
Hardware: All
OS: All
medium
medium
Target Milestone: ---
: ---
Assignee: Joseph Marques
QA Contact: Corey Welton
URL: http://jira.rhq-project.org/browse/RH...
Whiteboard:
Depends On:
Blocks: rhq_triage
TreeView+ depends on / blocked
 
Reported: 2009-02-09 15:41 UTC by Corey Welton
Modified: 2010-08-12 16:49 UTC (History)
2 users (show)

Fixed In Version: 2.4
Doc Type: Bug Fix
Doc Text:
Clone Of:
Environment:
Linux Firefox 3; 1280x1024 display resolution.
Last Closed: 2010-08-12 16:49:50 UTC
Embargoed:


Attachments (Terms of Use)

Description Corey Welton 2009-02-09 15:41:00 UTC
1.  expand your browser full-screen 
2. Login to Jon;  Resources > Platforms > $platform > Operations > Manual Autodiscovery
3. Scroll to bottom of page; click the calendar icon in the scheduling window to begin selecting a schedule date.
4. View results.

Current results:
Bottom of calendar (with the "clear", "apply", etc., buttons) is cut off and browser cannot scroll below.  User must manually move window, expand browser further, and then select -- and then resize browser once again when s/he is done.

Expected results:
User can access all items in calendar.

Other notes:
This doesn't seem to happen in resolutions greater than 1280x1024 - but I don't think we should be limiting our webapp designs to such resolutions.

Comment 1 Corey Welton 2009-02-09 16:10:48 UTC
[11:01] <@joseph> yes, it doesn't depend on resolution, it's the fact that a browser does not make additional room (or 
                  autoscroll) for popup divs that are (i'm guessing) absolutely positioned


Comment 2 Joseph Marques 2009-02-09 16:50:40 UTC
rev2979 -  move the "other options" section below the scheduling section, to prevent the calendar from being cut off; 

Comment 3 Corey Welton 2009-02-17 14:13:53 UTC
Unfortunately, I found a new way to make this fail; same issue, although a variation on the theme.  There's a second calendar deeper in some of the pages that use the widget that expands below the bottom of the browser.

Try the following:
1. $platform > Operations > Manual Auto-discovery.
2. In section "Start", click the radio button for the calendar option
3. In section "Recur", click the radio button for 'Every (x) Days'
4. In section "Recurrence End", click the calendar icon.

You'll note that the bottom of the calendar again gets cut off.

Comment 4 Joseph Marques 2009-02-20 05:37:28 UTC
corey, unfortunately i know of no way to fix this.  this is how the richfaces component works.  the only thing i could do is add some extra padding to the bottom of the form.  however, this is not perfect either.  if the input field is close to the bottom of the page (let's assume you're not scrolled all the way to the bottom of the page), then when you click on the icon the calendar will get cut off again.  regardless, i've attempted a fix at this again...

rev3110 - try to prevent calendar pop-up from being cut-off by adding extra whitespace at the bottom of the form

Comment 5 Corey Welton 2009-03-24 16:58:41 UTC
I don't like that this still happens when you're scrolled all the way to the bottom.  That said, I fully understand that it's an issue with the richfaces component.  I am just gonna move this to the usability queue so that we can revisit it in the future, perhaps find a different way of doing it.


Comment 6 John Sefler 2009-10-28 14:40:57 UTC
I think this issue is very fixable:
The html that renders the pop-up calendar widget looks like this:

<table id="newScheduleForm:startDate" class="rich-calendar-exterior rich-calendar-popup" cellspacing="0" cellpadding="0" border="0" onclick="$('newScheduleForm:startDate').component.skipEventOnCollapse=true;" style="position: absolute; z-index: 3; left: 530px; top: 171px;">

By removing the 'position: absolute' from the html table tag, the calendar will initially render at the same spot, but will scroll with the page underneath.  This behavior is much preferred.  you can test/try it out using Firebug.

Requested fix for HTML:
<table id="newScheduleForm:startDate" class="rich-calendar-exterior rich-calendar-popup" cellspacing="0" cellpadding="0" border="0" onclick="$('newScheduleForm:startDate').component.skipEventOnCollapse=true;" style="z-index: 3; left: 530px; top: 171px;">

Comment 7 Red Hat Bugzilla 2009-11-10 20:34:34 UTC
This bug was previously known as http://jira.rhq-project.org/browse/RHQ-1506


Comment 8 wes hayutin 2010-02-16 16:58:53 UTC
Temporarily adding the keyword "SubBug" so we can be sure we have accounted for all the bugs.

keyword:
new = Tracking + FutureFeature + SubBug

Comment 9 wes hayutin 2010-02-16 17:03:38 UTC
making sure we're not missing any bugs in rhq_triage

Comment 10 Jay Shaughnessy 2010-04-16 21:30:37 UTC
Fixed (I think) b46489e0addcc3516a169ba6f94aa7f4d956a793

I'm fairly sure this is fixed but perhaps I missed the point. Please verify.

Comment 11 Joseph Marques 2010-04-19 02:54:13 UTC
John, in this case the table was automatically generated by the richfaces library, so we are restricted the rich:calendar component and whether or not they let us directly manipulate the style attribute on that generated table.

However, now that we've upgraded to a more recent version of richfaces, Jay took advantage of two attributes ('join-point' and 'direction') which makes the calendar interaction better.  From the richfaces documentation:

* joinPoint - Set the corner of the button for the popup to be connected with (top-left, top-right, bottom-left (Default), bottom-right, auto). Default value is "bottom-left".
* direction - Defines direction of the calendar popup ("top-left", "top-right", "bottom-left", "bottom-right" (Default), "auto"). Default value is "bottom-right".

Jay set both of these to "auto".  The net effect is that the calendar pop-up will anchor itself to the corner of the input box that most makes sense and from that anchor point will choose vertical and horizontal display directions that make the most sense.

Comment 12 Corey Welton 2010-05-04 18:37:43 UTC
QA Verified.  Glad to see this one finally fixed.

Comment 13 Corey Welton 2010-08-12 16:49:50 UTC
Mass-closure of verified bugs against JON.


Note You need to log in before you can comment on or make changes to this bug.