Last Comment Bug 37262 - captureEvents method causes handler to trigger twice
: captureEvents method causes handler to trigger twice
Product: Core
Classification: Components
Component: XUL (show other bugs)
: Trunk
: All All
P3 normal (vote)
: ---
Assigned To: Nobody; OK to take it and work on it
: Neil Deakin
Depends on:
  Show dependency treegraph
Reported: 2000-04-26 11:48 PDT by prass
Modified: 2009-10-30 07:53 PDT (History)
14 users (show)
See Also:
Crash Signature:
QA Whiteboard:
Iteration: ---
Points: ---
Has Regression Range: ---
Has STR: ---

Created test case for alert problem on linux (440 bytes, text/html)
2000-04-26 11:49 PDT, prass
no flags Details

Description User image prass 2000-04-26 11:48:52 PDT
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.

Platform: Linux Red hat 6.0
Comment 1 User image prass 2000-04-26 11:49:59 PDT
Created attachment 8006 [details]
Created test case for alert problem on linux
Comment 2 User image Jesse Ruderman 2000-04-26 16:02:01 PDT

*** This bug has been marked as a duplicate of 29165 ***
Comment 3 User image prass 2000-04-26 18:15:27 PDT
verifying as dupe. Tracking 29165 as the depends bug.
Comment 4 User image John Morrison 2000-05-08 21:57:24 PDT
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 User image John Morrison 2000-05-08 21:59:05 PDT
changing product/component
Comment 6 User image leger 2000-05-10 14:19:52 PDT
Putting on [dogfood+] radar.
Comment 7 User image prass 2000-05-10 18:05:23 PDT
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.

Comment 8 User image John Morrison 2000-05-10 22:37:36 PDT
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 
Comment 9 User image Dan M 2000-05-24 10:13:05 PDT
Key event processing. Tempted to dump on saari, but this might also be related to 
35921. Keeping for now and putting on same milestone.
Comment 10 User image John Morrison 2000-05-24 11:39:09 PDT
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).
Comment 11 User image John Morrison 2000-05-24 11:42:25 PDT
Resummarizing from "Enter key on alerts opens multiple alert instead on 
closing it." 
Comment 12 User image Dan M 2000-05-24 12:43:57 PDT
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.
Comment 13 User image saari (gone) 2000-05-24 15:24:18 PDT
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 User image saari (gone) 2000-06-07 10:59:29 PDT
Okay, well, this apparently works in 4.x. Tom, can you comment on how we should 
fix this?
Comment 15 User image Heikki Toivonen (remove -bugzilla when emailing directly) 2000-09-12 11:30:08 PDT
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 User image saari (gone) 2000-10-26 16:42:14 PDT
Target Mozilla 1.0
Comment 17 User image joki (gone) 2002-01-30 14:42:25 PST
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.
Comment 18 User image piers 2003-01-29 05:10:51 PST
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)
Comment 19 User image Heikki Toivonen (remove -bugzilla when emailing directly) 2003-01-29 09:51:53 PST
Aaron, this seems to affect accessibility (see comment above).
Comment 20 User image Neil Deakin 2009-10-30 07:53:57 PDT
captureEvents no longer does anything

Note You need to log in before you can comment on or make changes to this bug.