User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.4a) Gecko/20030328 Build Identifier: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.4a) Gecko/20030328 I can't type in the Note Box anymore. Reproducible: Always Steps to Reproduce: 1. New Event or New Task 2. Type something in Note 3. Actual Results: The underline thing doesn't move. Expected Results: Allow me to type.
Might be the same as Bug 200247 i can see the same with nightly from jesterday on W2k. 1.3 seems to work correct.
This is new, it worked in 1.3. Nothing happens when I try to type in the Notes field.
Summary: Can't type in Note box in New Task and New Calendar → Can't type in Note box in New Task and New Event
The same for me Linux Redhat 8.0 mozilla 1.4a nightbuild 31.march GCC 2.x
Same for me as well. Will add I am able to paste things into the note box on both New Event and New Task boxes; just can't edit them. Win2k: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.4a) Gecko/20030401
*** Bug 201474 has been marked as a duplicate of this bug. ***
Added to Cc.
Cannto type in notes at all. Not when making or editing an event. Never.
Mozilla/5.0 (X11; U; Linux ppc; en-US; rv:1.3) Gecko/20030313 Calendar from CVS. I am unable to reproduce this bug. Note in both task list and calendar are both working correcly for me.
That's because it works in 1.3 but not in 1.4.
It seems this is because of the: onkeypress="event.stopPropagation()" for the textbox element in both eventDialog.xul and todoDialog.xul. These are the log entries when these changes were made to fix a bug of enter closing the dialog: todoDialog.xul revision 1.18 date: 2002/10/29 20:31:32; author: mikep%oeone.com; state: Exp; lines: +1 -1 Fixing problem with dialog capturing return key. eventDialog.xul revision 1.47 date: 2002/10/29 20:31:32; author: mikep%oeone.com; state: Exp; lines: +1 -1 Fixing problem with dialog capturing return key. I'm guessing that this was due to Mozilla 1.2b - Released October 16, 2002 Removing the stopPropogation fixes the problem in 1.4 and still works in 1.3
Created attachment 122682 [details] [diff] [review] Removes the onkeypress from the textfields In my limited testing the fixes the bug for 1.4 and still allows it to work for 1.3 . Pressing return in the textbox does not result in the dialog being closed, but a newline being placed in the textbox.
Applying that patch and running calendar in 1.3 on Linux makes my dialog disappear when I try and type in a note and press return in the note field. Since 1.4 is only beta, and not final, we're not going to take this release for now. When 1.4 goes final, I'll add this back in.
Status: NEW → ASSIGNED
Summary: Can't type in Note box in New Task and New Event → For 1.4 -> Can't type in Note box in New Task and New Event
Actually, never mind. I've fixed this in CVS now. Users with builds newer than 1.4 can still type notes, except they'll only be 1 line long. Users using 1.4 can type notes. This is probably better than what it was. (I'm trusting Matthew on this one, I don't have 1.4 to test with).
Status: ASSIGNED → RESOLVED
Last Resolved: 15 years ago
Resolution: --- → FIXED
Works for me: Mozilla Calendar 2003050815-cal Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.4b) Gecko/20030508
Created attachment 122829 [details] Example HTML that shows the stopPropagation with a textbox. This is a short bit of HTML that contains some form elements, the first ones have stopPropagation on clicks and keypresses (stopped) and the second ones don't. The form displays an alert when it gets a keypress or click. In 1.3 everything works as it should, the select/textbox inputs work correctly with mouse/keyboard input and the form never sees the events because of the stopPropagation. In 1.4 you are unable to type in the stopped textbox (enter and delete are the only keys that work) and the arrow keys don't work. But the select item still works corrently with arrow keys for selecting the item. I am beginning to think this is a mozilla bug rather than a calendar bug and should probably be fixed. The docs for stopPropagation say that is lets the event be handled by the currentl element but prevents it from bubbling up to parent elements (form, body, html in the example). So the textbox should display the entered text just not bubble the event any higher.
The bugspam monkeys have been set free and are feeding on Calendar :: General. Be afraid for your sanity!
QA Contact: gurganbl → general
You need to log in before you can comment on or make changes to this bug.