Closed Bug 222954 Opened 21 years ago Closed 20 years ago

Opening Options dialog if there is already a modified dialog open causes crash - FF092 [@ nsXULCommandDispatcher::UpdateCommands]

Categories

(Core :: XUL, defect, P2)

x86
Windows 2000
defect

Tracking

()

VERIFIED FIXED
mozilla1.8alpha2

People

(Reporter: ebenard, Assigned: jst)

References

Details

(Keywords: crash, fixed-aviary1.0, fixed1.7.5)

Crash Data

Attachments

(2 files)

User-Agent:       Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.5) Gecko/20031007 Firebird/0.7
Build Identifier: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.5) Gecko/20031007 Firebird/0.7

The Mozilla Firebird crashes after modification in options dialog with 
multissesion of browser.
all sessions browser crash.

Reproducible: Always

Steps to Reproduce:
1.Open the browser
2.>tools
3.>options
4.>modified one
5.open an second browser session "Ctrl+n" or MozillaFirebird.exe !
6.tools
7.options...
Actual Results:  
all sessions browser crash.

Expected Results:  
1. restriction message on new session Firebird calling or apply change between !?
2.apply button in options dialog box !?

on windows 2000
Xp Pro, XP mce 
...?
Confirming using Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.6a)
Gecko/20031030 Firebird/0.7+

Its a little bit of an edge case, but its a limitation of the modal dialog system.

Someone with appropriate perms needs to remove this as its not security sensitive.
Assignee: blake → bugs
Severity: major → critical
Status: UNCONFIRMED → NEW
Ever confirmed: true
Group: security
Summary: The multissesion Mozilla Firebird crashes → Opening Options dialog if there is already a modified dialog open causes crash
*** Bug 224991 has been marked as a duplicate of this bug. ***
Would my patch to bug 206651 fix this? Specifically, the part I borrowed from
Thunderbird, where it looks for an existing Options window before trying to
create a new one.
Confirm here.
Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.6) Gecko/20040206 Firefox/0.8

Steps to reproduce:
1. Tools->Options...
2. Extensions->Get New Extensions
[
  a new window opens on top, loads extension page (this is critical, as the
  behaviour with the modal options dialog in IE is different)
]
4. Tools->Options...

Actual results:
Firefox crashes

Expected results (my 2 cents):
Options dialog comes back up on top, no reverting/saving of changed settings and
the like needed
What I also notice that when you haven't moodified anything in the options
dialog and then want to open it again in the second instance of firefox, that
nothing seems to happen, because it is already open in the first instance of
firefox.

What should happen is that the options dialog of the first firefox should come
to the foreground.
Keywords: crash
Crash here:Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.7b) Gecko/20040329
Firefox/0.8.0+ on Slackware Current

Talkback ID: TB9348M
Captured at 03/31/04 at 04:26 PM
Attached file stack trace
stack trace from talkback 9348 (note that there are still some issues with
source file / line number data due to the newer compiler)
*** Bug 240820 has been marked as a duplicate of this bug. ***
seems fair to set ?1.0
Flags: blocking1.0?
*** Bug 245215 has been marked as a duplicate of this bug. ***
Assignee: bugs → bryner
Flags: blocking1.0? → blocking1.0+
*** Bug 233818 has been marked as a duplicate of this bug. ***
*** Bug 246690 has been marked as a duplicate of this bug. ***
Flags: blocking-aviary1.0RC1+
This seems to be fixed.
Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.7) Gecko/20040626 Firefox/0.9.1
Assignee: bryner → jst
This has not been fixed.  I just crashed with: Mozilla/5.0 (Windows; U; Windows
NT 5.1; en-US; rv:1.7) Gecko/20040707 Firefox/0.9.2

My steps:

1. start firefox
2. open new window
3. in orginal window goto tools->options and make some change
4. in second window goto tools->options
5. crash
Summary: Opening Options dialog if there is already a modified dialog open causes crash → Opening Options dialog if there is already a modified dialog open causes crash - FF092 [@ nsXULCommandDispatcher::UpdateCommands]
jst: I was able to reproduce the crash with Mozilla/5.0 (Windows; U; Windows NT
5.1; en-US; rv:1.7) Gecko/20040708 Firefox/0.9.0+ as well...same steps.
jst and i were able to reproduce this.  we weren't able to crash changing the
days pref for history, but we did crash by clicking on the default browser check
box in the options window before trying to open the second options window.
Some of this code already checked that EnsureFocusController() did indeed find
a focus controller, but not all places. Make all callers check. This fixes the
crash.
Attachment #152641 - Flags: superreview?(brendan)
Attachment #152641 - Flags: review?(bugs)
Comment on attachment 152641 [details] [diff] [review]
Be consistent about error checking after calling EnsureFocusController()

r=ben@mozilla.org
Attachment #152641 - Flags: review?(bugs) → review+
Comment on attachment 152641 [details] [diff] [review]
Be consistent about error checking after calling EnsureFocusController()

sr=brendan@mozilla.org

/be
Attachment #152641 - Flags: superreview?(brendan) → superreview+
Status: NEW → ASSIGNED
Keywords: fixed-aviary1.0
Moving to Browser since this is a XUL problem, even if only visible in Firefox.
Component: Preferences → XP Toolkit/Widgets: XUL
Product: Firefox → Browser
Target Milestone: --- → mozilla1.8alpha2
Version: unspecified → Trunk
Attachment #152641 - Flags: approval1.8a2?
Comment on attachment 152641 [details] [diff] [review]
Be consistent about error checking after calling EnsureFocusController()

a=asa (on behalf of drivers) for checkin to 1.8a2
Attachment #152641 - Flags: approval1.8a2? → approval1.8a2+
Fixed on trunk too.
Status: ASSIGNED → RESOLVED
Closed: 20 years ago
Resolution: --- → FIXED
For me still NOT FIXED. Just installed 0.9.2 in fresh directory and it crashed 
on the same page as before (https:\\www.pekao24.pl) when jumping to another SSL 
site. The only change is error message - previously only Feedback Agent 
appeared, now also "memory can not be read" showed. See report TB318863Y, 
TB318836M.
This is not in Firefox 0.9.2.  It is in current branch and trunk builds however.
Verified Fixed with Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.7)
Gecko/20040712 Firefox/0.9.1+.  

This was fixed on the Firefox 1.0 (Aviary) Branch and the FirefoxTrunk (so
people will continue to see it in 0.9.2).
Status: RESOLVED → VERIFIED
Comment on attachment 152641 [details] [diff] [review]
Be consistent about error checking after calling EnsureFocusController()

as a potential crash, I'd like to see this in 1.7.x branch.

Please mark fixed1.7.x after checkin.

Thanks
Attachment #152641 - Flags: approval1.7.x+
Fixed on the 1.7 branch.
Keywords: fixed1.7.x
*** Bug 243317 has been marked as a duplicate of this bug. ***
Component: XP Toolkit/Widgets: XUL → XUL
QA Contact: mconnor → xptoolkit.widgets
Crash Signature: [@ nsXULCommandDispatcher::UpdateCommands]
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Created:
Updated:
Size: