Contextmenu mispositioned when editor in div with scrollbar

[Frederico Caldeira Knabben]

Description: The context menu and dropdowns are mispositioned if the editor is created within a div that has scrolling.

Browser: FireFox (FF) 1.5.0.9

How to reproduce: See attached file. Example is created for a screenresolution 1600x1200.

If you're able to use the editor before scrolling, the context menu is positioned correct. Scroll down and try again; The context menu and dropdowns are now mispositioned.

---

Moved from SF:
​http://sourceforge.net/tracker/index.php?func=detail&aid=1658114&group_id=75348&atid=543653

[Frederico Caldeira Knabben]

How to reproduce - Moved from SF. Original author: geirhelge

[Frederico Caldeira Knabben]

Confirmed with FF2. Attaching a HTML TC.

[Frederico Caldeira Knabben]

HTML Test Case

[Geir Helge Tjøstolvsen-Schmidt]

Here's a useful page about HTML element coordinates that we've used: ​http://www.faqts.com/knowledge_base/view.phtml/aid/1001

I'll let you know if I find a fix for the problem

[Frederico Caldeira Knabben]

I was thinking about playing with getBoxObjectFor and getBoundingClientRect, which could be the definitive solution for it, but I'm afraid with the compatibility with Safari and Opera.

Let's investigate... let us know if you have good results Geir.

[Geir Helge Tjøstolvsen-Schmidt]

One way to fix it

[Geir Helge Tjøstolvsen-Schmidt]

Seems like my suggested fix didn't fix everything. Child panels use the parent panel to get the its position and then it will be wrong to loop through the parent chain. I've modified fckpanel.js and updated fcktools_gecko.js. Couldn't find out how to update/delete the old patch, so I'll upload two new patch files.

[Geir Helge Tjøstolvsen-Schmidt]

fckpanel.js - Added parameter when calling FCKTools.GetElementPosition

[Geir Helge Tjøstolvsen-Schmidt]

fcktools_gecko.js - Added section to loop through the parent chain and a parameter to exclude it for panel children

[Frederico Caldeira Knabben]

After some investigation, I found out that getBoxObjectFor would be the dreamed solution for it... not compatible with Safari and Opera though... therefore unusable.

[Frederico Caldeira Knabben]

No... it seams that getBoxObjectFor is not the way to go definitely:
​http://qooxdoo.org/documentation/general/compute_element_position

[Martin Kou]

I've done some investigation and found the reason to this bug.

The essence of the algorithm in FCKTools.GetElementPosition() is looping through a node's offsetParents, adding the (offset - scroll) vector in each step, till we reached the document root in relativeWindow.

After some experiments, I discovered that the browser seems to return the nearest ancestor node whose offset vector is non-zero as the offsetParent. Problem is... a node with a zero offset vector does not necessarily mean it has a zero scroll vector as well. So hypothetically, if we only retrieve the scroll vector in the offsetParent nodes, we could have ignored some non-zero scroll vectors in some of the nodes in between.

And this is what happened when I traced the code execution in the test case: after looping through the outer <iframe>, the algorithm goes to a <td> cell containing FCKeditor, because the <td> cell is the <iframe>'s offsetParent. However, the <td> cell's scrollTop is always zero, even if you can see a big scrollbar in it, and you scrolled it way down. Why? Because the big scroll bar in the test cases is inside a <div> node between the <td> cell and the <iframe>, and that <div> node, is ignored in the browser's offsetParent calculation.

I've committed a fix [679] which is written based on my hypothesis. It works well under Firefox and Safari for the test cases given. I couldn't get the context menu to appear in Opera though (tried 2.4.3 and various SVN revisions).

[Alfonso Martínez de Lizarrondo]

Hi Martin, the Opera problem is #11 (now with a partial fix), but now I see that the dropdown combos appear displaced in Opera (as well as the contextmenu) and I think that previously they did work fine (although I'm not sure and now I'm tired, so if I test something then I might make a mistake)

You might want to take a look also at #1067

Regards

[Martin Kou]

Opera seems to have factored in the intermediate scrollLeft/scrollTop values to the offsetLeft/offsetTop values of offsetParent already. So my fix is not needed for Opera.

I've disabled the changes in [679] for Opera in [681]. Now the context menus should appear correctly in Opera as well.