This is the place to report bugs and get support. When posting in this forum, please always provide as much detail as possible.
Please do not report problems with a custom build or custom code in this forum. If you are producing your own build from the source code and have problems or questions, ask in the developer forum, do not report it as a bug.
When posting in this forum, please try to provide as many relevant details as possible. Particularly the following:
Closing a CKEditor dialog such as the link dialog in the blog causes the content to be scrolled to the top of the page. I've confirmed that this occurs in the mojoportal demo site and does not occur on the CKEditor demo page.
Steps to reproduce:
When adding links to the content, this becomes very frustrating as I'm sure you can imagine since you have to scroll back to where you were before if you want to add additional links further down in the page.
Since this does not occur in the CKEditor demo site, my guess is that there is some event.preventDefault() call within mojoportal that is needed to keep the anchor element that makes up the OK or Cancel buttons from doing what they normally do.
I've tried this in both Firefox and IE and it happens in both browsers.
Interestingly, I tried to duplicate this problem in this forum post and it does not happen, so perhaps this has something to do with whatever extra script the Blog/EditPost.aspx or the HtmlEdit.aspx pages use that is causing the problem. Hopefully, this will help you narrow down the cause of the problem.
Thanks for any help you can provide with this.
I've just tried this on a site running 184.108.40.206 and cannot replicate the issue (editing a long HTML Content article). On cancelling the Link dialogue the user is taken back to view the cursor location, which seems good behaviour.
What aspx page were you using to edit the html content? For me, it occurs in the Blog/EditPost.aspx and HtmlEdit.aspx pages. I'm not sure if it occurs in other pages that use the CKEditor, but it doesn't occur in the Forums/EditPost.aspx page as I had mentioned.
Have you tried to duplicate this on the demo site using the steps I described? It's also running 220.127.116.11 and I was able to duplicate the problem again. I'm also running with 18.104.22.168 locally and it happens when I edit a blog post.
I've tried this using Firefox (v 34) and IE so perhaps you are using a different browser, which could be the cause, but that seems unlikely.
Try editing the home page on the demo site and hopefully you'll be able to reproduce the problem.
Sorry, no, I cannot replicate this on the demo site. I've tested in IE11.
Well that's frustrating. I was able to duplicate the problem in IE 11 as well so I did some more testing to try and narrow it down and found that there are some browser differences and it also depends on where the cursor is located in the content editor. I did some tests in both IE and Firefox on both the MojoPortal and CKEditor demo sites and the results are included below.
IE - MojoPortal Demo Website
The CKEditor demo site works the same way. This all makes sense since you would expect the link to be inserted wherever the cursor is. However, just simply closing a dialog shouldn't cause the content to be scrolled up, but since the CKEditor demo site works the same way, it is what it is.
Firefox - MojoPortal Demo Website
For Firefox, the content is always scrolled up which is pretty frustrating when you are trying to add links.
Firefox - CKEditor Demo Website
My original post didn't include the cursor position since I didn't know that was a factor and I was trying to keep the steps as simple as possible. Hopefully now you can duplicate these steps using IE and Firefox. I'm not sure how Chrome would work but I suspect it would be similar to how Firefox works.
It looks like I can use IE as a work-around but perhaps this issue has been fixed in the latest version of CKEditor. I'm not sure how up to date MojoPortal is with the latest version of CKEditor but if they are using the same version then there is something in MojoPortal that is causing this problem for Firefox users (and perhaps Chrome users).
Hopefully this will help you track this down.