24947 - After a onblur event has been processed, clicking on the OK (of the dialog) causes a crash.

Status: VERIFIED FIXED

(Core :: DOM: UI Events & Focus Handling, defect, P3)

Description

[Chris Petersen]

Build: Apprunner
Version: 2000012008
Platforms: All
Expected Results: Clicking the OK button (of dialog) should close dialog.

What I got: The application crashes after clicking OK button.

Steps to reproduce: 

1) Open url in appruuner.
2) Highlight a item in the list.
3) With the mouse cursor, click outside of menu on the page.
4) This should cause a dialog to appear.
5) Click the OK button.

Comment 1

[Chris Petersen]

Attachment: A select element with onblur

Comment 2

[leger]

Adding "crash" keyword to all known open crasher bugs.

Comment 3

[leger]

Putting on on PDT+ radar for beta1.

Comment 4

[joki (gone)]

Okay, got a fix for this.  Review pending.

Comment 5

[joki (gone)]

Okay, I've got a fix in.

Comment 6

[Jan Carpenter]

Not fixed.  
tried on
Win98: 2000021408
Linux:  2000021416
MacPPC:  2000021413

This is no longer a crash, however, the dialog box never comes up when onblur is 
called.  Removing "crash" from keywords, and reopening

Comment 7

[joki (gone)]

Okay, well when I put in my fix this was working.  Saari has put in some code 
in this area since mine.  He'll take a look and try to find a likely subject.

Comment 8

[saari (gone)]

Joki, here is the deal. The listbox DOM listener sets PreventDefault on the

event. nsEventStateManager::PostHandle event checks to see if prevent default is

set before setting focus to the thing just clicked on. So if you remove the

check for prevent default in PostHandle, things work fine. I don't know what the

right thing to do here is, but I'm 95% sure that the list box isn't the only

widget with this problem. Personally, I don't think focus should be an event

that you can cancel the default action of, but I don't know. I leave the

fix/problem in your wise hands. (hey, stop swearing, I found the problem didn't

I? ;-)

Comment 9

[joki (gone)]

We don't actually allow you to cancel focus/blur events, we allow you to cancel 
the mouse events that cause them.  Long term the issue is that the current 
PreventDefault system is insufficient for our internal needs and we're expanding 
on it.  But that's probably not an M14 fix.

So currently we have two obvious ways to go on this for M14.  One, we leave it 
as is now and select (anything else?) don't have focus/blur.  Two, we change it 
to make focus/blur setting non-cancelable which fixes this but potentially 
allows other currently cancelled events into the system with unknown results.  
Still thinking on this one.

Comment 10

[joki (gone)]

So we currently lack focus/blur messages at all on select boxes.  However, other 
than that they seem to work just fine.  We're aware of why they don't work but 
don't have an easy fix.  So we can either try a hacky fix which may cause more 
problems or just go out for now without focus/blur events on select boxes.  The 
latter is my vote.

With the lack of machine locking or crashing I vote for knocking this to M15 and 
PDT-

Comment 11

[leger]

Putting on the PDT+ radar for beta1.  Need to verify original bug.  Please write 
a new bug for the remaining problem.

Comment 12

[Jan Carpenter]

Ok.
Verified Fixt, opening new bug for new behavior.