-
Bug
-
Resolution: Timed out
-
Low
-
4.1.1, 5.9
-
Firefox 7,8, Chrome 16
-
3
-
Severity 3 - Minor
-
To Reproduce
1) Fill page with a few lines of text. I.e.:
this
page
has
text
2) click after the word page
3) drag image so cursor is position after the word text (and drop)
4) The image will be pasted after page instead of after text.
In Chrome, the same behaviour is exhibited, however the cursor stays stationary when you are dragging an image into a page.
[CONFSERVER-24153] Firefox appears to ignore the position of the cursor when you drag and drop an image
Our customer had the same issue. (Please see my internal comment.)
I asked pcurren about my reopening this issue and he allowed me to do.
So I've spent some time implementing a fix for (1) which basically involves setting contenteditable false for certain drag events. This of course prevents the cursor moving around.
Then when the drag is cancelled or dropped you set contenteditable back to true.
This works well as far as I can test on Firefox 8. However, Firefox 3.6 is "funny" in it's firing of the 'dragleave' event. It is really quirky and it's pretty easy to have a situation where contenteditable is never set back to true.
I think unless we get customer complains about this issue which I haven't seen yet it is safest just to leave things as they are for now.
Regarding point (2). It will have the same quirkyness but probably more so because the logic will apply across multiple browser so again until it becomes a "real" issue I would say we just park this for now.
I'm closing the issue but please re-open if you disagree.
The Firefox and IE behaviour is the same as Chrome which is a win for consistency.
The problem is that Firefox is alone in moving the editor cursor around as you drag which gives the visual impression that you are controlling where you are going to drop the attachment.
This should be fixed in one of two ways -
1) Prevent Firefox moving the cursor around on drag events. (I think this will be hard or impossible.)
2) Actually position the attachment where Firefox visually indicates it is going to go. (Might be hard since TinyMCE certainly doesn't know about the new cursor position.)
I will investigate (2) further since I at least have a few ideas around that area.
Additionally, the IE and Chrome behaviour while consistent and understandable, isn't great. You can easily lose track of where your cursor was before you started the drag and drop and so it would be nice to indicate some kind of drop zone during the operation. Introducing this is probably out with the scope of this bug fix given the possibility of accidentally leaving 'temporary' markup in the edited page.
The Chrome behaviour is as expected. This was implemented in CONFDEV-3794. Regardless of where on the Editor you drop the image, it will be inserted where the cursor is.
Thank you for taking the time to raise, comment or vote on this Bug. We regret to inform you that due to a limited number of reports and based on our current backlog of higher impact issues that we are closing this issue as Timed Out.
If this issue is still impacting you on a recent version please feel free to comment with the affected version. Any further details you may be able to provide regarding reproduction or impact of this issue may help us better address this issue.
Thanks again.
Regards,
Confluence Development