Sebastian (and others): I think that Westor has uncovered a critical bug
to do with coordinates in qooxdoo 0.7.1. It will affect anyone embedding
qooxdoo in a page. It appears that you have done some work on this in 0.8
(from http://qooxdoo.org/documentation/general/development_0_8 ) but in
the meantime anyone using 0.7.x with embedded qooxdoo is going to have a
big problem.
Please take time to read my conclusions at the bottom. I won't raise bugs
until this has been clarified.
Westor, to reproduce your layout, I had to turn off
qx.enableApplicationLayout. I hacked this by qx.ui.core.ClientDocument
and changing the settings:
"qx.enableApplicationLayout" : false,
If I didn't do this, the scrollbars were turned off on the <html> element.
If there's an easier way to do this, please note it in your sample code.
> > Firefox:
> > If you scroll the browser (not the table widget), the selected
> > row is not the row where the mouse pointer is. Instad a row is
> > selected,
> > which is [scrolled pixel] below mouse pointer.
> > This works well in IE - at least in IE6. (Please could someone
> > give
> > feedback, if the application runs in IE7?)
>
> I found, this FF bug has something to do with calculating of row
> position in
> ui/table/pane/Scroller.js in function _getRowForPagePos.
> There is used the paneClipperTopY variable to calculate variable
> tableY
>
> var tableY = scrollY + pageY - paneClipperTopY;
> var row = Math.floor(tableY / rowHeight);
>
> But paneClipperTopY becomes negative if the top of the table
> scrolls out of
> visible browser, so the result is incorrect.
> May be this could help to fix the bug?
I added a line to Scroller.js after line 1732 (for 0.7.1):
this.debug("PageY = " + pageY + "; row = " + row);
It appears that pageY is wrong. In FF, it always is 101 in my case for
the top of the first row. That's true even if the whole page is scrolled
a little bit. But in IE7, it becomes less when the whole page is scrolled.
This is all determined from qx.event.type.MouseEvent.getPageY where there
is specific code to distinguish between browsers and add scroll values
for IE7.
In FF this fixed value is then compared with the absolute DOM position of
the table which, of course, changes as the document is scrolled. Hence
the disparity in the selected row vs click. In IE it's OK as the mouse
position decreases when the doc is scrolled, compensating for the changed
position of the table.
But, I think that the IE7 behaviour is wrong. The pageY coordinate should
be the same regardless of if the whole document is scrolled. Any code in
qooxdoo should be protected from scrolling of the document; otherwise
there would be tests and so on throughout the code to compensate for it.
Having said that, in this example there is a calculation from mouse
position to actual position of a DOM element so the DOM element position
would have to be compensated as well. So that might further complicate
things, unless of course qx.html.Location.getClientBoxTop also took
document scrolling into account.
If I'm correct there are going to be fundamental fixes throughout the
qooxdoo code for this (horizontal as well as vertical scrolling). See,
for example, the problem with the original page
(http://www.fitnesswelt.com/fitness-shop/ ) and combo-box drop down
position when scrolled.
Sebastian, what's the best way forward?
Hugh
-------------------------------------------------------------------------
This SF.net email is sponsored by: Microsoft
Defy all challenges. Microsoft(R) Visual Studio 2005.
http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/
_______________________________________________
qooxdoo-devel mailing list
qooxdoo-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/qooxdoo-devel
