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

VERIFIED FIXED in M15

Status

()

Core
Event Handling
P3
critical
VERIFIED FIXED
19 years ago
19 years ago

People

(Reporter: Chris Petersen, Assigned: joki (gone))

Tracking

Trunk
Points:
---

Firefox Tracking Flags

(Not tracked)

Details

(Whiteboard: [PDT+], URL)

Attachments

(1 attachment)

(Reporter)

Description

19 years ago
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.
(Reporter)

Comment 1

19 years ago
Created attachment 4539 [details]
A select element with onblur

Updated

19 years ago
Severity: major → critical

Comment 2

19 years ago
Adding "crash" keyword to all known open crasher bugs.
Keywords: crash
(Reporter)

Updated

19 years ago
Keywords: beta1

Comment 3

19 years ago
Putting on on PDT+ radar for beta1.
Whiteboard: [PDT+]
(Assignee)

Updated

19 years ago
Whiteboard: [PDT+] → [PDT+], fix or other resolution by 2/15
(Assignee)

Comment 4

19 years ago
Okay, got a fix for this.  Review pending.
Status: NEW → ASSIGNED
Whiteboard: [PDT+], fix or other resolution by 2/15 → [PDT+], fix or other resolution by 2/10
Target Milestone: M14
(Assignee)

Comment 5

19 years ago
Okay, I've got a fix in.
Status: ASSIGNED → RESOLVED
Last Resolved: 19 years ago
Resolution: --- → FIXED

Comment 6

19 years ago
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
Status: RESOLVED → REOPENED
Keywords: crash
Resolution: FIXED → ---
(Assignee)

Comment 7

19 years ago
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.
Assignee: joki → saari
Status: REOPENED → NEW
Whiteboard: [PDT+], fix or other resolution by 2/10 → [PDT+]

Comment 8

19 years ago
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? ;-)

Assignee: saari → joki
(Assignee)

Comment 9

19 years ago
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.
(Assignee)

Updated

19 years ago
Blocks: 27359
(Assignee)

Comment 10

19 years ago
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-
Status: NEW → ASSIGNED
Whiteboard: [PDT+]
Target Milestone: M14 → M15

Comment 11

19 years ago
Putting on the PDT+ radar for beta1.  Need to verify original bug.  Please write 
a new bug for the remaining problem.
Status: ASSIGNED → RESOLVED
Last Resolved: 19 years ago19 years ago
Resolution: --- → FIXED
Whiteboard: [PDT+]

Comment 12

19 years ago
Ok.
Verified Fixt, opening new bug for new behavior.
Status: RESOLVED → VERIFIED
(Assignee)

Updated

18 years ago
No longer blocks: 27359
You need to log in before you can comment on or make changes to this bug.