using 4/7 build of netscape 2000040709 1) launch netscape 2) launch composer 3) enter text 4) do not highlight text, but use color picker to change color(upper left icon) 5) type some more now notice that you don't get your caret back...so you can't see the new color or any text for that matter cause you've lost the caret.. all platforms.

okay I meant that the caret is visible blinking, but you're stuck and can't do anything...

->cmanske

The problem isn't the colorpicker, it's the <popup> that contains the colorpicker. I think it is a box-related problem.

*** Bug 35475 has been marked as a duplicate of this bug. ***

Note that this is causing a crash on UNIX, as reported in 35475.

apparently this occurs in the AIM composer window as well.

Needs more investigation, but colorpicker is horked now because of other problems with XUL <stack>.

updating priority and severity for beta2 radar

Putting on [nsbeta2+] radar.

*** Bug 35947 has been marked as a duplicate of this bug. ***

After talking to Chris and David Hyatt, we realize this problem is because <popup> is stealling keyboard focus and not returning it.

Wait a minute, the popup should only be stealing keystrokes for the period of time that it is popped up. You sould be able to type after using it. Does this happen with normal menus too?

No, there seems to be no problem with <menupopup>, only <popup>.

The popup takes focus when you click on it. I thoght we were creating OS windows that couldn't do that at all?

Neat, this is a stack bug. However, there are 2 different work arounds, both of which are appropriate to do. 1) use ignorekeys="true" for the two colorpicker popups. 2) modifiy the popup listener to set PreventDefault so it cannot open two popups on the same event.

Unfortunately, we do want to have keyboard input in a textfield just under the colorpicker in the <popup>. Will "ignore keys" kill that?

ignorekeys simply kills the keyboard navigation for the popup, which is too specific to menus to work with the colorpicker anyway. So no, this won't kill that, it will actually get you closer to having it work.

I'm still protesting putting a text field in a popup however. You have crossed into the realm of dialogs in my opinion. Plus, there will still be bugs with typing in that field. It doesn't work on my Mac build even with these changes.

This bug is fixed now, the colorpicker will not wedge keyboard events.

Thanks. So should I use ignorekeys="true"?

Yes you should as you will avoid creating the listener that you don't want anyway. Or I can add it once my build is complete.

Thanks - your fix works for not stealing key events, of course. I added the "ignorekeys" and it didn't help with the textfield working, but that's another matter!

verified in 5/11 build.

Charley told me to reopen this one...

*** Bug 39390 has been marked as a duplicate of this bug. ***

Note that 39390 is a subtle variant that is truly weird: Simply mousing-over the colorpicker buttons, which triggers a tooltip, causes the keyboard focus to be lost. Tooltips are <popup>s, correct? But why doesn't this happen with tooltips over other buttons? The only thing different about the colorpicker button is that it *would* launch a popup if clicked on, which isn't the case in 30390.

Fixed this again, but we still need to add "ignorekeys" for the colorpicker popups.

Thanks for fixing this! The colorpicker popups already do have ignorekeys="true"

If they have ignorekeys="true" then there is another bug, because I watched the code fail that test. Well, maybe I seeing the tooltip. Hrm. Nevermind.

will verify using 5/24 build.

will verify after 40324 is fixed

verified in 5/24 build.