Closed Bug 337334 Opened 15 years ago Closed 15 years ago

Can't hide browser after or during Download Manager activity

Categories

(Core :: ImageLib, defect)

1.8 Branch
PowerPC
macOS
defect
Not set
major

Tracking

()

RESOLVED FIXED

People

(Reporter: boudouarnaud, Assigned: jaas)

References

Details

(Keywords: fixed1.8.1, regression, Whiteboard: confirmed on trunk and Mozilla1.8 branch)

Attachments

(1 file)

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.
Did you try this on a trunk build (3.0a1) or a Mozilla1.8.0 build (1.5.0.4)?
With trunk build (clean profile): same issue
With 1.5.0.4 rc2 (clean profile): no issue
(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)
confirmed, same build, but on Mac OS X 10.2.8
Status: UNCONFIRMED → NEW
Ever confirmed: true
(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?
Whiteboard: confirmed on trunk and Mozilla1.8 branch
Version: unspecified → 2.0 Branch
Probably the same core issue as bug 337123 and bug 337122.
Depends on: 337123
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??)
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
Component: OS Integration → ImageLib
Product: Firefox → Core
Summary: Can't hide Bon Echo after Downloads window display → Can't hide browser after or during Download Manager activity
Version: 2.0 Branch → 1.8 Branch
Assignee: nobody → joshmoz
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.
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.
*** Bug 337575 has been marked as a duplicate of this bug. ***
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.
Blocks: 335723
Re comment 11, this does appear to be the result of getting [NSWorkspace sharedWorkspace].
Flags: blocking1.9a1?
Flags: blocking1.8.1?
Keywords: regression
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.
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!
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 17 is bug 312586, unrelated to this bug.
(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.
Attached patch fix v1.0Splinter Review
Attachment #223292 - Flags: review?(mark)
Attachment #223292 - Flags: review?(mark) → review+
landed on trunk, still needed on 1.8 branch
Status: NEW → RESOLVED
Closed: 15 years ago
Resolution: --- → FIXED
Keywords: fixed1.8.1
Depends on: 339389
Blocks: 339623
Comment on attachment 223292 [details] [diff] [review]
fix v1.0

This did land on 1_8.
Attachment #223292 - Flags: approval-branch-1.8.1+
Flags: blocking1.9a1?
Flags: blocking1.8.1?
You need to log in before you can comment on or make changes to this bug.