Opened 10 years ago

Closed 9 years ago

Last modified 9 years ago

#135 closed Bug (fixed)

Contextmenu mispositioned when editor in div with scrollbar

Reported by: fredck 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)

fckeditor.php (1.1 KB) - added by fredck 10 years ago.
How to reproduce - Moved from SF. Original author: geirhelge
cm_position.html (1022 bytes) - added by fredck 10 years ago.
HTML Test Case
fix.patch (1.1 KB) - added by geirhelge 9 years ago.
One way to fix it
fckpanel.js.patch (418 bytes) - added by geirhelge 9 years ago.
fckpanel.js - Added parameter when calling FCKTools.GetElementPosition
fcktools_gecko.js.patch (1.6 KB) - added by geirhelge 9 years ago.
fcktools_gecko.js - Added section to loop through the parent chain and a parameter to exclude it for panel children

Download all attachments as: .zip

Change History (16)

Changed 10 years ago by fredck

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

comment:1 Changed 10 years ago by fredck

  • Cc geirhelge@… added

comment:2 Changed 10 years ago by fredck

  • Keywords Confirmed added

Confirmed with FF2. Attaching a HTML TC.

Changed 10 years ago by fredck

HTML Test Case

comment:3 Changed 9 years ago by geirhelge

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 9 years ago by fredck

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.

Changed 9 years ago by geirhelge

One way to fix it

comment:5 Changed 9 years ago by fredck

  • Milestone set to FCKeditor 2.5

comment:6 Changed 9 years ago by geirhelge

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 9 years ago by geirhelge

fckpanel.js - Added parameter when calling FCKTools.GetElementPosition

Changed 9 years ago by geirhelge

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

comment:7 Changed 9 years ago by fredck

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 9 years ago by fredck

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

comment:9 Changed 9 years ago by martinkou

  • Resolution set to fixed
  • Status changed from new to 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 9 years ago by alfonsoml

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

comment:11 Changed 9 years ago by martinkou

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.

Note: See TracTickets for help on using tickets.
© 2003 – 2016 CKSource – Frederico Knabben. All rights reserved. | Terms of use | Privacy policy