Closed Bug 311234 Opened 19 years ago Closed 19 years ago

Clicking 'Done' after customize toolbars exits Firefox

Categories

(Toolkit :: Toolbars and Toolbar Customization, defect)

Product:
Toolkit
Component:
Toolbars and Toolbar Customization
Type:
defect
Priority:
Not set
Severity:
critical

Tracking

()

Status:
RESOLVED FIXED

People

(Reporter: AmboyGuy, Assigned: benjamin)

References

Details

(Keywords: dataloss, regression)

Attachments

(1 file)

Dont call close too often
725 bytes, patch
mconnor
: first-review+
Details | Diff | Splinter Review 
User-Agent:       Mozilla/5.0 (Windows; U; Win98; en-US; rv:1.8b5) Gecko/20051005 Firefox/1.4.1
Build Identifier: Mozilla/5.0 (Windows; U; Win98; en-US; rv:1.8b5) Gecko/20051005 Firefox/1.4.1

When you click done in the customize window Firefox exits.

Reproducible: Always

Steps to Reproduce:
1.right click toolbar, click customize
2.Click done.
3.

Actual Results:  
FireFox exits.

Expected Results:  
Firefox should have incorporated any changes and continued in the current page.
(In reply to comment #0)

Occurs only in the Trunk Nightly: Mozilla/5.0 (Windows; U; Win98; en-US;
rv:1.9a1) Gecko/20051005 Firefox/1.6a1 - Build ID: 2005100507 

Sorry I used the Branch when filing the report.
I can confirm this happens in Trunk 2005100503.  Branch 2005100503 is ok.
Mozilla/5.0 (Windows; U; Win95; en-US; rv:1.9a1) Gecko/20051005 Firefox/1.6a1
Not sure whether to kw this as a hang or a crash.
Status: UNCONFIRMED → NEW
Ever confirmed: true
Keywords: regression
Version: unspecified → Trunk
Severity: major → critical
Keywords: dataloss
Summary: Customize toolbars exits Firefox → Clicking 'Done' after customize toolbars exits Firefox
Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.9a1) Gecko/20051005
Firefox/1.6a1 ID:2005100507
I also see this on Win2k
*** Bug 311232 has been marked as a duplicate of this bug. ***
This is a regression.
Build 2005100406 was OK.
Build 2005100413 exhibits the bug.
Mozilla/5.0 (Windows; U; Win95; en-US; rv:1.9a1) Gecko/20051005 Firefox/1.6a1
Flags: blocking1.8b5?
So this is trunk only? I can't reproduce on the branch. If it is trunk only,
please remove the blocking1.8b5? flag.
2005100503 Branch is OK.
Rearranging and moving/adding Icons on the navigation bar is a WFM using the
Branch 1.8 1.5 Beta 2 build from today:

Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.8b5) Gecko/20051005
Firefox/1.4.1 ID:2005100506
Flags: blocking1.8b5?
Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.8b5) Gecko/20051005
Firefox/1.4.1 ID:2005100500

WFM , no crash on branch
Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9a1) Gecko/20051005
Firefox/1.6a1

Reproducible if the close "X" button is pressed.
(In reply to comment #6)
> This is a regression.
> Build 2005100406 was OK.
> Build 2005100413 exhibits the bug.
> Mozilla/5.0 (Windows; U; Win95; en-US; rv:1.9a1) Gecko/20051005 Firefox/1.6a1

Are you sure of that regression range? Nothind was checked in that could affect
this in that range, unless bonsai is lying to me.

Does anybody have any talkback incident IDs?

Why was the "dataloss" keyword added?
Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.8b5) Gecko/20051005
Firefox/1.4.1 - also tested on 20051003

WFM on both branch builds.
(In reply to comment #12)
> (In reply to comment #6)
> > This is a regression.
> > Build 2005100406 was OK.
> > Build 2005100413 exhibits the bug.
> > Mozilla/5.0 (Windows; U; Win95; en-US; rv:1.9a1) Gecko/20051005 Firefox/1.6a1
> 
> Are you sure of that regression range? Nothind was checked in that could affect
> this in that range, unless bonsai is lying to me.
I'm pretty sure of that range. I installed several old builds from my
collection, and that's what I got. I didn't have talkback enabled because in all
cases FF just did a normal close. I didn't do the dataloss deal.
> 
> Does anybody have any talkback incident IDs?
> 
> Why was the "dataloss" keyword added?


I added dataloss because firefox quitting with no warning could result in
dataloss. Technically, this is not a crash (no error msg) or a hang (firefox
closes cleanly). Plse change the kws as appropriate.
(In reply to comment #12)

> Are you sure of that regression range? Nothind was checked in that could affect
> this in that range, unless bonsai is lying to me.

Tried it again. Same results.
Build 2005100406 was OK.
Build 2005100413 exhibits the bug.


Is more than just clicking "done"...any option to close the "Customise toolbar"
panelwill result in a crash (in the 1.6a1 nighlies from 20051005)
Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9a1) Gecko/20051005
Firefox/1.6a1 ID:2005100515

I'm seeing this, too. The only thing that looks like a likely culprit is bug
310076. Can anyone back this patch out and verify that's what caused it?
Confriming on OS X:
Mozilla/5.0 (Macintosh; U; PPC Mac OS X Mach-O; en-US; rv:1.9a1) Gecko/20051005
Firefox/1.6a1 ID:2005100506

But *only* if I actually edit the toolbar. Simply opening the customize pane and
closing it doesn't cause Firefox to close.
Flags: blocking1.9a1?
Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9a1) Gecko/20051006
Firefox/1.6a1 ID:2005100607

Can confirm occurs when clicking 'Done' button or clicking close icon of
customize bar.
*** Bug 311416 has been marked as a duplicate of this bug. ***
*** Bug 311464 has been marked as a duplicate of this bug. ***
Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.9a1) Gecko/20051006 Firefox/1.6a1

I see this on Linux as well.
OS: Windows 98 → All
Hardware: PC → All
Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9a1) Gecko/20051010
Firefox/1.6a1 ID:2005101007

works just fine 
(In reply to comment #24)
> Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9a1) Gecko/20051010
> Firefox/1.6a1 ID:2005101007
> 
> works just fine 

Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9a1) Gecko/20051011
Firefox/1.6a1 ID:2005101106
bug still reproducible for me
Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9a1) Gecko/20051011
Firefox/1.6a1

Bug still happenning here. However, even though Firefox crash after I click
done. After reloading Firefox, the customization that I did stays though.
This is definatly still broken.

Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9a1) Gecko/20051011
Firefox/1.6a1 ID:2005101115

An interesting effect that I just discovered that may be causing confusion. If
you have a browser window open, customise then close the customise firefox
exits. If you have two browser windows open, you can customise twice before it
will close. Sure enough, with three windows, after closing customise for the
third time firefox will exit. Note that none of the browser windows close in
between, during that.

More interestingly, open two firefox windows. Customise and close the customise
once and the browser will still be up with 2 windows. Now close one window and
firefox totally exits.

It looks to me like firefox is keeping a count of the number of open windows but
for some reason closing the toolbar customise window is dropping that count more
than it should.


This is not only a Firefox problem. Error happens also on Sunbird 0.2+ Trunk 
builds.
Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.9a1) Gecko/20051012 Mozilla 
Sunbird/0.2+
Moving to Toolkit based on comment 28 from Stefan.
Component: Toolbars → Toolbars and Toolbar Customization
Product: Firefox → Toolkit
QA Contact: toolbars → nobody
mconnor, what does the "Done" button in toolbarcustomize actually do?
I suspect what's happening involves the customize toolbar window not firing an
xul-window-opened notification, but it does fire a xul-window-closed
notification, which means that the consider-quit-stopper in appstartup gets
confused.

See
http://lxr.mozilla.org/mozilla/source/xpfe/appshell/src/nsAppShellService.cpp#484
and
http://lxr.mozilla.org/mozilla/source/xpfe/appshell/src/nsXULWindow.cpp#552

which are supposed to be sent in matched pairs.
Assignee: nobody → benjamin
Flags: blocking1.9a1? → blocking1.9a1+
This is another potential. The customise script has two functions, onAccept and
onUnload, both of which call window.close.

Clicking done calls onAccept, and closing the window does the same. The
window.close then causes the window to unload causing onUnload to happen which
calls window.close while the window is closing.

Removing the window.close call from onUnload fixes this bug for me and I
couldn't see any obvious problems with it.
Blocks: 310076
good catch! we should probably also throw on the second call to .close() (or
silently fail), so that we don't end up with the evil early-quit in other places.
Comment on attachment 199326 [details] [diff] [review]
Dont call close too often

Mike, can you think of any bad side-affects for this?
Attachment #199326 - Flags: first-review?(mconnor)
Attachment #199326 - Flags: first-review?(mconnor) → first-review+
Fixed on trunk.
Status: NEW → RESOLVED
Closed: 19 years ago
Resolution: --- → FIXED
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Creator:
Created:
Updated:
Size: