337334 - Can't hide browser after or during Download Manager activity

Status: RESOLVED FIXED

(Core :: Graphics: ImageLib, defect)

Description

[u127172]

User-Agent:       Mozilla/5.0 (Macintosh; U; PPC Mac OS X Mach-O; en-US; rv:1.8.1a2) Gecko/20060509 BonEcho/2.0a2
Build Identifier: Mozilla/5.0 (Macintosh; U; PPC Mac OS X Mach-O; en-US; rv:1.8.1a2) Gecko/20060509 BonEcho/2.0a2

After opening then closing "Downloads" window, Bon Echo can't be hidden anymore.

Reproducible: Always

Steps to Reproduce:
1. Launch Bon Echo
2. Goto into "Bon Echo" menu, then select "Hide Bon Echo" => Bon Echo is hidden
3. Display Bon Echo, open "Downloads" window, then close this window
4. Goto into "Bon Echo" menu, then select "Hide Bon Echo" => Bon Echo is not hidden. I seems to go to background, a right click on Dock's icon displays the "Display" menu item, but the main window remains visible.
Actual Results:  
Bon Echo main window is not hidden.

Expected Results:  
Bon Echo main window must be hidden.

Comment 1

[Charli Li (winsxs)]

Did you try this on a trunk build (3.0a1) or a Mozilla1.8.0 build (1.5.0.4)?

Comment 2

[u127172]

With trunk build (clean profile): same issue
With 1.5.0.4 rc2 (clean profile): no issue

Comment 3

[Jo Hermans]

(In reply to comment #1)
> Build Identifier: Mozilla/5.0 (Macintosh; U; PPC Mac OS X Mach-O; en-US;
rv:1.8.1a2) Gecko/20060509 BonEcho/2.0a2

that's a 2.0 alpha 2 (todays build)

Comment 4

[Jo Hermans]

confirmed, same build, but on Mac OS X 10.2.8

Comment 5

[Charli Li (winsxs)]

(In reply to comment #4)
> confirmed, same build, but on Mac OS X 10.2.8
> 

does this happen on Mac OS X 10.3.9?

Comment 6

[:Gavin Sharp [email: [e-mail]]]

Probably the same core issue as bug 337123 and bug 337122.

Comment 7

[Wayne Woods]

Perhaps caused by the patch checked in in bug 315421 comment 6?

See http://bonsai.mozilla.org/cvsview2.cgi?diff_mode=context&whitespace_mode=show&root=/cvsroot&subdir=mozilla/toolkit/components/downloads/src&command=DIFF_FRAMESET&root=/cvsroot&file=nsDownloadManager.cpp&rev1=1.61&rev2=1.62

Comment 8

[Wayne Woods]

Actually, ignore that. The regression dates for the bugs that Gavin mentioned in comment 6 are quoted as between 20060505 and 20060506. I made a bad assumption that this bug started at the same time. It actually regressed between the 20060502 and 20060503 Firefox trunk builds (unless maybe the dates in the other bugs refer to the 1.8 branch, and that regressed 3 days later??)

Comment 9

[Wayne Woods]

OK, found it. The bug first occurred in the 20060503 Minefield (trunk) build. Bon Echo seems to have a broken Download Manager over that period, so I can't use it to pick the exact regression time, but the SeaMonkey Moz 1.8 branch first regressed in the 20060505 build.

It seems to be the fix for bug 335723 that caused it (see attachment 220524 [details] [diff] [review]). The check-in dates for branch and trunk fit. But most importantly, backing out the patch for that bug seems to remove this bug. Not sure exactly what code caused it, but I know that it wasn't the change to nsIconChannel.h (reversing that alone fixed nothing). Presumably some of the internal changes that occurred when nsIconChannel.cpp was moved to nsIconChannel.mm

Comment 10

[Josh Aas]

I can confirm Wayne's comments. The first trunk build with this bug is 2006-05-03-04, and backing out the new icon decoder fixes the problem.

Comment 11

[Josh Aas]

I do not see this problem with a trunk Cocoa Firefox build, but I do see it with a trunk Carbon build.

There isn't anything suspicious going on in the icon decoder. My guess is that there is some side effect of calling into NSWorkspace or other Cocoa code from within a Carbon app, maybe it tries to do something crazy like initialize NSApplication.

For the record, I diffed my new Cocoa decoder impl file against the old cpp file, and nothing was accidentally changed that could screw things up. Also, I can still repro in Carbon builds with a patch applied to supply an NSAutoreleasePool to the Cocoa code (see bug 338041), so that isn't what's making the app go crazy.

Comment 12

[Mark Mentovai]

*** Bug 337575 has been marked as a duplicate of this bug. ***

Comment 13

[Mark Mentovai]

Another symptom from duped bug 337575: command-tab into an app that's executed the new icon decoder code will activate the application but not its windows.

Comment 14

[Mark Mentovai]

Re comment 11, this does appear to be the result of getting [NSWorkspace sharedWorkspace].

Comment 15

[Josh Aas]

We're going to need to back out the Cocoa icon decoder from the 1.8 branch. I'll work on rewriting the carbon one so it does nice alpha.

Comment 16

[Josh Aas]

I opened an Apple DTS incident on this problem, and an hour ago they sent me a solution, so we're not going to need to back out the Cocoa icon decoder. Turns out we can initialize the Cocoa frameworks with NSApplicationLoad() before using Cocoa and avoid these problems. Initializing with [NSApplication sharedApplication] from a Carbon app is known to cause this bug, and I guess when we let Cocoa initialize itself it initializes that way. Interestingly, since the Java we use via JEP uses Cocoa, the JEP plugin calls NSApplicationLoad() and thus loading a Java plugin after launching the browser prevents these bugs from showing up!

Patch on the way. Thanks Apple DTS!

Comment 17

[Patrick]

Don't know if this problem causes yet another symptom.

Mozilla/5.0 (Macintosh; U; PPC Mac OS X Mach-O; en-US; rv:1.9a1) Gecko/20060524 Minefield/3.0a1.

Clean profile. Create a user.js file that says
user_pref("network.cookie.cookieBehavior", 3);
user_pref("network.cookie.lifetimePolicy", 1);
user_pref("network.cookie.p3p", "frfradaa");
user_pref("network.cookie.p3plevel", 2);

--> this way you'll get a dialog whether or not you want to accept a cookie that is being offered.

Define a bookmark consisting a bunch of pages to open up as a tab.

Open all these pages at the same time via OPEN IN TABS. Since this is a clean profile you're likely to be bombarded with "sheets" (aka dialogs) for accepting the cookies from all these pages. After acknowledging the second cookie, the third sheet will be completely blank. This effectively results in a hang as it seems not possible to dismiss the sheet.

If the problem described above is caused by the same mechanism as is causing this bug, then the severity of this bug should be bumped up to Critical, because of the hang?

Comment 18

[Mark Mentovai]

Comment 17 is bug 312586, unrelated to this bug.

Comment 19

[Patrick]

(In reply to comment #18)
> Comment 17 is bug 312586, unrelated to this bug.


That bug is listed as fixed on trunk as of January 2006. However, as mentioned in comment 17, i'm seeing this again in the latest nightly.

Comment 20

[Josh Aas]

Attachment: fix v1.0

Comment 21

[Josh Aas]

landed on trunk, still needed on 1.8 branch

Comment 22

[Mark Mentovai]

Comment on attachment 223292 [details] [diff] [review]
fix v1.0

This did land on 1_8.