#135 closed Bug (fixed)
Contextmenu mispositioned when editor in div with scrollbar
Reported by: | Frederico Caldeira Knabben | Owned by: | |
---|---|---|---|
Priority: | Normal | Milestone: | FCKeditor 2.5 Beta |
Component: | UI : Context Menu | Version: | FCKeditor 2.4 |
Keywords: | SF Confirmed | Cc: | geirhelge@… |
Description
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
Attachments (5)
Change History (16)
Changed 18 years ago by
Attachment: | fckeditor.php added |
---|
comment:1 Changed 18 years ago by
Cc: | geirhelge@… added |
---|
comment:2 Changed 18 years ago by
Keywords: | Confirmed added |
---|
Confirmed with FF2. Attaching a HTML TC.
comment:3 Changed 18 years ago by
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
comment:4 Changed 18 years ago by
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.
comment:5 Changed 18 years ago by
Milestone: | → FCKeditor 2.5 |
---|
comment:6 Changed 18 years ago by
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.
Changed 18 years ago by
Attachment: | fckpanel.js.patch added |
---|
fckpanel.js - Added parameter when calling FCKTools.GetElementPosition
Changed 18 years ago by
Attachment: | fcktools_gecko.js.patch added |
---|
fcktools_gecko.js - Added section to loop through the parent chain and a parameter to exclude it for panel children
comment:7 Changed 17 years ago by
After some investigation, I found out that getBoxObjectFor would be the dreamed solution for it... not compatible with Safari and Opera though... therefore unusable.
comment:8 Changed 17 years ago by
No... it seams that getBoxObjectFor is not the way to go definitely:
http://qooxdoo.org/documentation/general/compute_element_position
comment:9 Changed 17 years ago by
Resolution: | → fixed |
---|---|
Status: | new → closed |
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).
comment:10 Changed 17 years ago by
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
How to reproduce - Moved from SF. Original author: geirhelge