Build ID: 1999121612 Platform: Linux (can't reproduce on Win32) To reproduce: - At the command prompt, type ./mozilla -installer - Create a new profile - In the new profile wizard, highlight the phrase 'mozProfile' - Start typing. Result: Nothing happens. You must press Delete to delete the text. Expected result: When you start typing, the selected text should be deleted and replaced with what you're typing.

Reassigning to Steve.

akkana, chris, can you reproduce on linux? Is this the only text control that exhibits this problem, or is it all of them? What about the editor app?

akkana just tried this in a current build and it still happens as described.

what about the other questions? some text controls, or all? text controls only, or editor app as well?

When Beth was watching, I was trying it in the profile wizard as described at the beginning of this bug. In the editor: works fine. In a text field in a bugzilla page: works fine. In the urlbar: if I highlight text then type an a, the highlighted text is deleted but the a shows up at the end of the line (i.e. the caret was not set properly after the deletion, which I think is a Joe bug). This may have something to do with focus since it varies so much.

akkana: This does not happen on WinNT or Mac. I don't currently have access to a linux box, so I could use some help debugging this. Could you set a break point in nsTextEditorKeyListener::KeyPress() and see if it gets called when you follow the recipe for this bug? I bet it does not get called for alphanumeric keys, but for some reason it does for delete. Or if it does get called, is it falling into this block: if(dispatchStopped) return NS_OK; ???

Bad news: this seems to be sporadic. I first tried it on my debug build, to make sure I still saw the problem, and I saw it just as described here. Then I ran gdb, set the breakpoint Steve suggested, and it did get to KeyPress and did not get into dispatchStopped ... and the key event got through. I disabled the breakpoint and tried again, and the key event got through again; and now even outside of gdb, I'm no longer seeing this. :-(

For anyone who's still able to reproduce this: one possibility is that there are known to be a lot of problems with repaint (or possibly reflow), which make it look like key events aren't being handled when actually the problem is just that changes aren't repainted or reflowed. I think Pavlov and Kin have bugs on this. Anyone who sees this problem, please try forcing a repaint (cover the window and then uncover it, or something) and see if this is the real problem.

Using the 2000010508 build on Linux, I tried collapsing the window as well as covering it with another window, all to no avail; I still couldn't replace selected text in the Profile Manager by typing after highlighting. So, I don't think it's a drawing/refresh issue... I did notice that if you highlight the text and start typing, it doesn't work at first - but if you then click to the right of the text, type a few characters, and then select part of the text and start typing, it does work then. Curious.

Can you describe in painstaking detail exactly where you're clicking, for the first click (the one that initializes the editor in the text field) and then the subsequent clicks or drags to select all? I've tried clicking in different places and now can't seem to figure out what I was doing to reproduce the behavior before.

I *live* for painstaking detail. - At the command prompt, type ./mozilla -installer - When the Profiles and Migration window appears, click on New... - When the Profile Manager window appears, click on its title bar to select it (I'm using Enlightment; this seems to be a necessary step) - Click the Next button - The window should now have a text input control labeled Enter New Profile name: - Click once to the right of the word 'mozProfile'. This selects (visibly at least) the entire text. If you start typing now, it WILL work as expected (the selected text is replaced). - Now, quit everything and start over again. Do every step exactly the same but for the last one (clicking to the right of the word mozProfile). This time, however, click around in there and eventually wind up selecting all of the text. *This* time, typing does not replace the selected text. If that isn't clear enough, come down to the build cube for a live demo. Thanks!

Actually, it was the "click around in there" part for which I needed the painstaking detail. :-) I just went down for a live demo, and the only way we could get it to happen was when the mouse was on the edge of the window, and the window manager (one of the gnome ones) was showing a tooltip explaining window resizing. Focus still appeared to be in the profile window (at least, the titlebar was still the active color) but perhaps the window manager's tooltip was interfering and not passing key events through. When the mouse was fully in the window, this problem did not occur. But dammit, I use kde and pointer focus, so I know that wasn't what was happening when I saw it earlier today. I think there is a bug here ... but neither of us can reproduce it. All I can suggest is marking it worksforme and then if someone finds a way of reproducing it, reopening it then (and I'll be happy to set breakpoints then and try to track it down more fully).

marking worksforme, as per akkana's comment

Updating QA contact.

worksforme too. tested on linux 2000-09-26-09-MN6 mozilla build. marking verified. I can change the name of the profile fine by highlighting.