Extlib dialog appears to be pinned to the right window border

3
votes

I'm having this strange phenomenon with an extlib dialog which I've never encountered before. The scenario is pretty much straight-forward: there's a link control calling the dialog.show() method through it's serverside conclick event. As soon as the dialog appears, however, it somehow is glued to the right edge of the browser's window. Dragging the dialog to the left doesn't actually move it but increases its width instead!

I can't see anything special at all looking at the source code through firebug. AFAIK there's only one thing special about this application: the Xpage in question is running inside a classical frameset, due to the fact that this a 10 year old Domino web application, and there's simply no budget to completely transform it to XSP logic, so I'm doing it one by one I'm asked for some adjustments.

Up to now this combination runs just great, no flaws so far until now, and I'm not at all sure if the one has something to do with the other.

Happens in both Firefox and MSIE. I tried this on servers of version 8.5.3 UP1 as well as 9.0.1. Designer version is 9.0.1.

Currently, I worked around this by adding some right margin to the dialog, so at least it appears somewhere inside the frame from where it is called. But it still is pinned to some right edge.

Any hint is more than welcome.

EDIT:

Meanwhile I tried a tooltip dialog instead of a standard one: again the resulting control appears is pinned to the right edge, but it also spans across the entire parent frame. And the tooltip marker that should be pointing to the evoking link also is pointing to the rightmost possible position. So it's obviously for me now that those controls don't like to be called in the context of a frameset. Or could that be so?

EDIT #2:

Thanks to Patrick and Michael I had a few more ideas what I could try. It's still not working as expected, but at least I can now say for sure that the surrounding frameset is not the reason for this all: in a blank db with frameset and all the dialog works as expected. Whereas the dialog doesn't work in my project db even if I call the page by its own.
Weirdest thing I just found out is if I run the page in firefox AND with the firebug split window open then the dialog behaves just normally as I can drag it around like I want to.

1
xpagesxpages-extlib
Have you tried this with a blank NSF? – Patrick Sawyer
I have seen this with the first XPinC and it was caused by the elder Gecko engine in it. Never saw it again.My guess for your case is a css issue possibly caused by your css overlapping with the definitions from extlib. Have you tried tracing the computed style with firebug? – Michael Gollmick
I have seen this problem with older versions of IE, and Domino 8.5.2. But have seen other problems with dialogs when I decided to become fancy and apply styles to things. Have you tried the xpages extension library demo to verify correct functionally? – Patrick Sawyer
Sorry for the late answer - thanks both for your suggestions; I'll see what comes out of fiddling with computed css. - @Patrick: not sure what you mean by "verify correct functionality": I know the extlib dialog control to be working fine in "standard" environments as I use it quite frequently. – Lothar Mueller

1 Answers

0
votes

Finally I found the solution; the reason was the dialog's content:

in my case the dialog contains fixed text only structured through some native html "p" and "ul" tags. The resulting text content is rendered as one long string per structure tag; word-wrapping occurs where the dialog container reaches the right window border, but in fact the text would like to stretch out for the entire string's length. So the dialog appears to be pinned to the right edge, and if I drag it to the left it simply increases its width. If my screen was wide enough the dialog finally would become draggable at some point, but unfortunately the text is too long for that (hope I could make myself clear).

Solution is as simple as it can be: giving the dialog container control a style attribute restricting its initial width to say 60% solves the mystery.