Go for it.. :)

Andrew Robinson wrote:
If the popup is not placed in the form, but in the document body, then
submission of the form will not include any form controls in the
popup. The problem seems to be that in IE7, if the form is not right
under the BODY tag, especially if it nested in any element that has
scrolled overflow, the position is inaccurate. The problem seems to be
from the IE7 specific code to target where on the page the X and Y
coordinates of the mouse event were. In FF, events are page relative,
in IE they are client relative. The problem here is that I know of no
built in way in IE to get page coordinates using a client X and Y. The
code that I changed it to is not taking into account scroll offsets
that are not on the document.body and therefore appearing in the wrong
location on the page.

This JS is really a pain in the rear to debug on each platform. If
someone has the desire to fix the IE specific code for calculating the
location and submitting the patch, that would be best.

On Tue, Jun 17, 2008 at 3:57 AM, Carsten Pieper
<[EMAIL PROTECTED]> wrote:
Hi,

probably this is related and might help: In some cases (portal environment,
but
browser-independent...) we also experienced problems with popup positioning
(using tr:panelPopup...).

We introduced a local patch for the trinidad-impl file
/src/main/javascript/META-INF/adf/jsLibs/PanelPopup.js
which fixed our positioning problem. The only change we made was in the
_getOffsetParent() function.

This is the original (please note: We're on Trinidad 1.0.5) method:

/**
 * Get the element to add to the dialog to, to ensure dialog
 * positioning
 */
TrPanelPopup.prototype._getOffsetParent = function()
{
 for (var elem = this.getContent(); elem != null;
   elem = elem.parentNode)
 {
   if (elem.tagName && 'form' == elem.tagName.toLowerCase())
   {
     return elem;
   }
 }
 return document.body;
}

And this is our patched version (we just omitted the for-loop)

/**
 * Get the element to add to the dialog to, to ensure dialog
 * positioning
 */
TrPanelPopup.prototype._getOffsetParent = function()
{
 return document.body;
}

As we don't know, what the for-loop was for (perhaps anyone could give a
hint...)
we can't claim this to be a general solution, but probably it's a hint that
might be useful...

Best regards, Carsten


Andrew Robinson-5 wrote:
The popup code is a bit complex and a pain to work with in a cross
browser space. The best thing is to use firebug on firefox and
visualstudio 2008 with IE to debug the TrPopup  JavaScript code. In
there you can step through and watch the calculations being made.

Otherwise, you can try to reproduce the problem on the demo page then
create a Jira ticket and attach the patch/file so a developer can have
a look. Danny Robinson created the panelPopup and I have made some
positioning changes. I have not seen Danny around on the list anymore
unfortunately and I am behind on open source work (burned out lately)
so getting work done on this code may be slow going.

If you can debug the code (BTW you only need the free version of
VS2008 to debug JS) that would go a long way.


--
View this message in context: 
http://www.nabble.com/-TRINIDAD--panelPopup-positioning-tp17735420p17881667.html
Sent from the MyFaces - Users mailing list archive at Nabble.com.



Reply via email to