Opened 10 years ago

Closed 10 years ago

#1019 closed defect (fixed)

Cusor not jumping to editable part of window when clicked in IE7

Reported by: fizix Owned by: gogo
Priority: low Milestone:
Component: Xinha Core Version: trunk
Severity: minor Keywords: IE7
Cc:

Description

When I click the Xinha window in IE7, the cursor does not jump to an editable part of the window. Instead I have to click in the upper-left part of the window after the cursor becomes an "I-beam". This does not happen in Firefox and I have not tested it in IE6.

Change History (12)

comment:1 Changed 10 years ago by ray

  • Resolution set to fixed
  • Status changed from new to closed

should be cured in rev [826]

comment:2 Changed 10 years ago by fizix

  • Resolution fixed deleted
  • Status changed from closed to reopened

I just tested with the nightly build (rev 834) and I'm still having the problem. :(

comment:3 Changed 10 years ago by ray

In my testing it works

comment:4 Changed 10 years ago by FiZiX

That's strange. You can click anywhere in the window and your cursor jumps to the editable area? I'll try it on another computer when I get a chance.

comment:5 Changed 10 years ago by wymsy

  • Milestone Version 1.0 deleted

Can anyone confirm if this is still an issue? In any event, it doesn't seem serious enough to be on the Version 1.0 list.

comment:6 Changed 10 years ago by guest

This is still not working for me. The provided revs are not fixing it either.
It can be simulated in the online example as well.
Even though it's not a serious issue we have clients calling all the time to complain that "Xinha is freezing, cannot write in" (because they are not clicking on the right place.)
Unfortunatelly I cannot fix this by myself, so I hope somebody will fix it soon.

--Thanks

comment:7 Changed 10 years ago by ray

I found this annoying, too, whenever I pulled out IE for testing. I'm quite shure though that it now works even with clicking in the lowest, leftest corner

comment:8 Changed 10 years ago by guest

I just tested this with the latest nightly, still not working...
My IE version is 7.0.5730.11, not sure if this can help, because we have requests about this from multiple IE7 users, so I'm not sure if this can be the issue.
The edited page should be blank, or with short text. If there is text in the "lowest, leftest corner" it will be working, but will NOT work if the area there is blank.
Please let me know if I can be of any help for you to simulate this issue, as it's really annoying, and I hope it can be fixed soon.

--Thanks

comment:9 Changed 10 years ago by wymsy

I can see the problem using IE 6 in the extended example. If you move your mouse up and down over the text and the blank area below it, the cursor changes between a pointer and an I-bar. I suspect that means that the iframe height is not getting set to 100% of the td cell height that contains it. I haven't had time to dig deeper into this, but I think the first place to look would be in Xinha.prototype.sizeEditor.

comment:10 Changed 10 years ago by ray

  • Resolution set to fixed
  • Status changed from reopened to closed

rev [860]: So, now i think I got it.

comment:11 Changed 10 years ago by guest

  • Resolution fixed deleted
  • Status changed from closed to reopened

Hi,


Ray, thanks for the provided fix. I did tested it thoroughly, and it really fixes some part of the problem. Unfortunately, it doesn't fix it entirely.
I'll try to explain what I found.


So now, (in IE7) if the xinha area is not active, and if you click anywhere in the area, the cursor will jump where expected. And this is fixed, as it wasn't working like this before.
However, if the xinha area is already active, it will continue to have the previous behavior.


Therefore, even though a first (activation) click will work correctly, a second click will make the cursor disappear again, and typing after that will have effect.


So, from what I can say, all the fixes that were done affecting this first click (now working correctly), should also be applied for any following clicks (which currently work as before).


I'm reopening this ticket as I hope knowing the problem will now be easier to apply for the other cases as well, so to have this completely fixed.



Thank you

comment:12 Changed 10 years ago by ray

  • Resolution set to fixed
  • Status changed from reopened to closed

fixed rev 863

Note: See TracTickets for help on using tickets.