60419 - Text Editor: ubercaret appears after deleting lines, serious for IME

Status: VERIFIED WORKSFORME

(Core :: DOM: Editor, defect, P3)

Description

[Masaki Katakai]

Please try the following operation. The long long cursor that covers multiple
lines appears. It's very serious for UNIX/Linux IME when input style is
over-the-spot because the height of line (mCursorPosition.height retrieved by
NS_COMPOSITION_QUERY) will be used for size of pre-edit text. In my testing,
size is over 400 is passed in mCursorPosition.height and nsWidget tries to
load font with the size, finally it causes X error.

1) Start Mozilla Mail
2) Set Editor mode is Text
3) Select long message on message list pane
4) Select Reply button
   The contents of the message are quoted by "> "
5) Select top two lines by mouse
6) Hit Back Space key
   Now you can see the long long cursor that covers wbole
   contents appears.

At that time, while over-the-spot input mode, nsWidget
retrieves cursor height to adjust font height of pre-composed
text of IME. But it's very very large, which will cause
X error that the font could not be loaded. See nsWidget::UpdateICSpot()
function,

http://lxr.mozilla.org/mozilla/source/widget/src/gtk/nsWidget.cpp#163

Comment 1

[rubydoo123]

reassign to jfrancis

Comment 2

[Joe Francis]

I'm not sure this problem is avoidable anytime soon in the editor.  In the html 
editor we have some extra smarts to try and minimize the number of times this 
occurs (note that you cant prevent it from ever occurring: between two adjacent 
images, for instance, you expect a long cursor).  However, the text editor 
doens't have these extra smarts, and adding them in will severely bloat the text 
editor.  The real problem is that the quoting is wrapped in  a seperate block (i 
forget if it's a div or a pre now), and the text editor doens't have all the 
extra smarts needed for dealing with blocks.  It just deals with text and breaks.

The only thing that occurs to me is that the caret code might be able to detect 
situations like these and avoid making a large caret unless it was truly in a 
tall text frame, or next to tall image, etc.  Simon?

Comment 3

[Simon Fraser [no longer active]]

Nuther caret bug, sorry dude.

Comment 4

[rubydoo123]

moving to moz0.9.1

Comment 5

[anthonyd]

moving to 0.9.2

Comment 6

[rubydoo123]

is this related to bug 54452?

Comment 7

[anthonyd]

setting to 0.9.3

Comment 8

[anthonyd]

moving to 1.0

Comment 9

[rubydoo123]

--> kin

Comment 10

[kinmoz]

--> Pulling this in to mozilla0.9.8, adding to plain text composer tracking bug.

Comment 11

[Syd Logan]

minusing

Comment 12

[Kevin McCluskey (gone)]

Moving bugs to Mozilla1.1 that are not EDITORBASE+.

Comment 13

[saari (gone)]

Needs testing please. If it still appears we should mark it EDITORBASE+

Comment 14

[Masaki Katakai]

Verified this problem does not happen on Trunk 20030225 build.

Please mark as WFM.

Comment 15

[rubydoo123]

WFM

Comment 16

[rubydoo123]

verified