Closed
Bug 37262
Opened 24 years ago
Closed 15 years ago
captureEvents method causes handler to trigger twice
Categories
(Core :: XUL, defect, P3)
Core
XUL
Tracking
()
RESOLVED
WONTFIX
People
(Reporter: prass, Unassigned)
Details
Attachments
(1 file)
440 bytes,
text/html
|
Details |
On Linux only, CR on alert() method opens another alert message. Using the mouse click closes the alert as expected. Only Enter key causes this problem. Windows and Macintosh behave as expected. Build:20000426 Platform: Linux Red hat 6.0
Comment 2•24 years ago
|
||
*** This bug has been marked as a duplicate of 29165 ***
Status: NEW → RESOLVED
Closed: 24 years ago
Resolution: --- → DUPLICATE
verifying as dupe. Tracking 29165 as the depends bug.
Status: RESOLVED → VERIFIED
Comment 4•24 years ago
|
||
Reopening this bug (37262) since the dup is fixed, but this is not: On *both* windows and linux builds for today, using *either* the mouse or CR to dismiss the dialog, I get a second instance of the alert dialog thrown up when using the testcase above. Adding dogfood, as prass had requested that review on bug #29162.
Comment 5•24 years ago
|
||
changing product/component
Component: XPFE → XP Toolkit/Widgets
Product: Architecture → Browser
Version: 5.0 → other
Actually with the fix of 29165, the problem for which this bug was opened is also fixed. In AIM, enter key works fine. Marking works for me. Changing QA contact to prass, since I can verify this on linux AIM. Thanks!
Status: REOPENED → RESOLVED
Closed: 24 years ago → 24 years ago
QA Contact: jrgm → prass
Resolution: --- → WORKSFORME
Comment 8•24 years ago
|
||
Well, with a fresh build on linux, as well as with the a.m. verification builds for mac and windows, this demo is still doing two odd things: 1) every key event is processed twice on all three platforms 2) characters in the printable ascii range (e.g. [a-zA-z0-9 etc.]) have a keycode of 0 (zero). Characters like DEL, ESC, TAB have their correct keycodes (although 4.x traps TAB and ESC before the app gets them [win32]) NOTE: this "double event" happens whether the alert is dismissed by CR, or by a mouse click [or if the alert is replaced by a dump()] Removing dogfood(+) designations, since prass was willing to close for his requirements. Prashant -- do you have open DOM 0 bugs for the problems noted here?
Key event processing. Tempted to dump on saari, but this might also be related to 35921. Keeping for now and putting on same milestone.
Target Milestone: --- → M16
Comment 10•24 years ago
|
||
bug 35921 -- 'event notification outlives its event' happens only on linux, though, but this bug is XP. By the way, see also bug 38889 -- 'click on label sends two onclicks to parent' (although that may be specific to the way <label> relates to form controls).
OS: Linux → All
Hardware: PC → All
Comment 11•24 years ago
|
||
Resummarizing from "Enter key on alerts opens multiple alert instead on closing it."
Summary: Enter key on alerts opens multiple alert instead on closing it. → Key press generates two events; key codes are incorrect
Comment 12•24 years ago
|
||
Note to self: read more carefully. John seems to have clinched it as a problem where event notifications are being fired twice. To saari, with compassion.
Assignee: danm → saari
Status: REOPENED → NEW
Target Milestone: M16 → ---
Comment 13•24 years ago
|
||
I believe both behaviors are correct. The attached example sets up both a document.onkeypress and a document.capture. First the document.capture fires *but does not cancel the event* and then the document sees the event as normal and brings up the alert the second time. Prove this to yourself by removing the document.capture and the alert only comes up once. ask for the keycode, I believe that is correct behavior, but I'll double check
Comment 14•24 years ago
|
||
Okay, well, this apparently works in 4.x. Tom, can you comment on how we should fix this?
Updated•24 years ago
|
Target Milestone: --- → Future
When working on firing the select event, I found that if I have the caret in the beginning of the INPUT text field and I press shift+end, I get two keypress events. Also if I have the caret at the end and press shift+home I get two keypress events. Because of this we get two select events.
Comment 16•24 years ago
|
||
Target Mozilla 1.0
Status: NEW → ASSIGNED
Target Milestone: Future → mozilla1.0
Updated•23 years ago
|
Target Milestone: mozilla1.0 → mozilla0.9.9
Comment 17•23 years ago
|
||
This seems to be a bug with the captureEvents method, a deprecated 4.x method. In order to most closely model 4.x behavior, the captureEvents method should translate the event listener registered on the document into a capture-only listener so that it is not triggered a second time in the bubbling phase. This doesn't seem to be working and the listener is triggered twice. As for the keycodes I believe they have all been fixed. The last comment on the bug about them is pretty old and they've worked for a while now. Changing owner, summary and milestone.
Assignee: saari → joki
Status: ASSIGNED → NEW
Summary: Key press generates two events; key codes are incorrect → captureEvents method causes handler to trigger twice
Target Milestone: mozilla0.9.9 → mozilla1.1
Comment 18•22 years ago
|
||
Is it this bug which is causing accesskeys to seemingly cause a function to occur twice. This is a fairly major accessability bug. If this is a different bug, i'll file a new report: To reproduce: 1. Open Edit -> Preferences -> Navigator -> Languages 2. Add a few languages (say 5 to make sure the list is long enough) 3. Select a language and press Alt+U and Alt+D (to move the item up and down) Actual results: the first time after adding, the accesskey works as expected, subsequently, the accesskey causes the item to move two places up or down. Expected: just move one place up or down. (Note, this seems to occur with _every_ accesskey)
Aaron, this seems to affect accessibility (see comment above).
Target Milestone: mozilla1.1alpha → ---
Updated•15 years ago
|
Assignee: joki → nobody
QA Contact: prass → xptoolkit.widgets
Comment 20•15 years ago
|
||
captureEvents no longer does anything
Status: NEW → RESOLVED
Closed: 24 years ago → 15 years ago
Resolution: --- → WONTFIX
You need to log in
before you can comment on or make changes to this bug.
Description
•