Closed Bug 35100 Opened 25 years ago Closed 25 years ago

can't type after using <popup>, e.g., the colorpicker

Categories

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

Product:
Core
Component:
DOM: Editor
Type:
defect

Tracking

()

Status:
VERIFIED FIXED

People

(Reporter: sujay, Assigned: saari)

References

Details

(Whiteboard: [nsbeta2+] will verify after 40324 is fixed)

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...
Summary: lose caret after chaning color of text → lose caret after changing color of text
->cmanske
Assignee: beppe → cmanske
Summary: lose caret after changing color of text → can't type after changing color of text
Target Milestone: --- → M16
The problem isn't the colorpicker, it's the <popup> that contains the colorpicker. I think it is a box-related problem.
Summary: can't type after changing color of text → can't type after using <popup>, e.g., the colorpicker
*** 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.
Keywords: beta2
Needs more investigation, but colorpicker is horked now because of other problems with XUL <stack>.
Status: NEW → ASSIGNED
Keywords: nsbeta2
updating priority and severity for beta2 radar
Severity: normal → major
Keywords: beta2
Priority: P3 → P1
Putting on [nsbeta2+] radar.
Whiteboard: [nsbeta2+]
*** 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.
Assignee: cmanske → saari
Severity: major → critical
Status: ASSIGNED → NEW
Whiteboard: [nsbeta2+] → [nsbeta2+] blocker
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?
Status: NEW → ASSIGNED
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?
Blocks: 38110
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.
Status: ASSIGNED → RESOLVED
Closed: 25 years ago
Resolution: --- → FIXED
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.
Status: RESOLVED → VERIFIED
Charley told me to reopen this one...
Status: VERIFIED → REOPENED
Resolution: FIXED → ---
*** Bug 39390 has been marked as a duplicate of this bug. ***
Blocks: 40158
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.
Status: REOPENED → RESOLVED
Closed: 25 years ago → 25 years ago
Resolution: --- → FIXED
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.
Whiteboard: [nsbeta2+] blocker → [nsbeta2+] will verify using 5/24 build.
will verify after 40324 is fixed
Whiteboard: [nsbeta2+] will verify using 5/24 build. → [nsbeta2+] will verify after 40324 is fixed
verified in 5/24 build.
Status: RESOLVED → VERIFIED
You need to log in before you can comment on or make changes to this bug.