bad placing of dijit.popup when page takes almost the whole viewport height

[guest]

Hi,

Steps to reproduce

Have a page with any Dojo widget which opens some popup (let say TimeTextBox?). Put some other content into this page so that it uses almost the whole height of your browser window, but not the whole. The vertical scrollbar should not appear. Center all the content of the page (I guess right-aligning would do the job as well).
Make the popup open, in TimeTextBox? you do it by clicking on the input box. Popup position is wrong, it's 8px moved to the left, but should be exactly under the input box.
A screenshot showing it: http://img230.imageshack.us/img230/6076/dojopopupbugjl2.png
The problem appears on both IE and FF. Version of the browsers doesn't seem to be of big importance, but I use:

Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.8.1.11) Gecko/20071127 Firefox/2.0.0.11

My guess on where the bug is

If you look at the open function in dijit/_base/popup.js, I mean lines 58-76, you can see:
1. A wrapping block for the popup content is being created (58-65),
2. It's added to the DOM tree (66) and the content is put into (69).
3. Then it's placed around the element (75).

The problem is that after placing the popup content on the output (i.e. after step 2), the content of the page does not fit the viewport height any more, so the browser is forced to show the vertical scrollbar. Since the content of the page is centered and width of the viewport is changed, all the content is moved to the left by 8px (half of the scrollbar width?). Then the wrapper is being placed on this 'changed' screen with dijit.placeOnScreenAroundElement(). And since placing it just under the component does not make the page longer any more, the browser hides the vertical scrollbar. The content goes back to its previous place, but the popup remains in its wrong position.

My suggestion how to solve it

For my purposes I just did a workaround of adding:

wrapper.style.left = "1px";
wrapper.style.top = "1px";	

in lines 62-63, just before

wrapper.style.visibility = "hidden";

... so that the browser doesn't have to show the vertical scrollbar between adding the popup to the DOM tree and placing it around the input box.

Regards, Grzegorz Olędzki

[guest]

Screenshot of TimeTextBox? with popup in a wrong position

[guest]

I've added a similar but not the same ticket #5777.

[bill]

Hi Grzegorz. Great description. But why does adding the drop down cause a scroll bar to appear? It seems like it wouldn't affect things since the wrapper is position: absolute. Do you know where on the page the wrapper is initially being placed? (is it at the bottom?)

BTW adding a scroll bar to the viewport could also have a bad effect because it would shift some elements down. Since the page is narrow, it may become taller.

[guest]

Hi,

Sorry, maybe my description was not precise enough. The scrollbar is not really visible at all, it's only my guess that the calculations are being done taking the scrollbar into consideration. I believe so, because the problem appears only on pages taking almost the whole viewport and the shift is always the same, i.e. 8px. And the problem doesn't appear on pages originally taking more than browser window height.

When it comes to the wrapper initial position... I just did a check. When I turn off the placing (calling placeOnScreenAroundElement() around line 75 in popup.js). The wrapper (and the whole popup content) is printed after all the page content on my page. In DOM it appears as a last child of the body element. In terms of positioning it indeed has position:absolute, but no left, nor top set, so I guess this is the reason it appears at the bottom.

Hope it helps.

Best regards, Grzegorz

[bill]

(In [13803]) Fix problem where popup appears too far to the left. Apparently, popup was momentarily being positioned at bottom of screen, and even though it's position:absolute, it caused a scrollbar to appear, which affected the position of the target element for a split second, thus the popup ends up too far to the left. Thanks to Grzegorz for tracking this down. Fixes #5776 !strict

[bill]

modified version of test_TimeTextBox.html that shows problem on FF2/win (but not FF2/mac or IE6)