Phil Ringnalda (:philor) Reporter
	Description • 17 years ago

After the landing of bug 395334, clicking the "Done" button in the toolbar customization panel hides the parent window.

STR:
1. Right click toolbar, choose Customize...
2. In the customize panel, click Done
3. Panic, because the whole app window disappeared
4. Cmd+tab to another app, then Cmd+tab back to your apparently unharmed Minefield

Not quite sure how to tell whether it's really just from the widget: cocoa parts of bug 395334, or a cross-platform bug that we only exercise on OS X.

	Neil Deakin Assignee
	Comment 1 • 17 years ago

Isn't this and 403942 the same? So the Add Toolbar button doesn't actually factor in?

	Neil Deakin Assignee
	Comment 2 • 17 years ago

This seems to do the trick. Do I need to call SendSetZLevelEvent or the parent as well?

	Josh Aas
	Comment 3 • 17 years ago

Yeah, I'd call SendSetZLevelEvent on the parent. Otherwise this looks good to me.

	Robert O'Callahan (:roc) (email my personal email if necessary)
	Comment 4 • 17 years ago

Can you explain what's going on here? I'm lost.

	Phil Ringnalda (:philor) Reporter
	Comment 5 • 17 years ago

(In reply to comment #1)
> Isn't this and 403942 the same?

Not to someone who doesn't know widget code anyway - the bug 403942 problem was that you could interact with the panel while it had opened a sheet, and at that time when you closed them in the order panel, then sheet, you were left with a visible but non-functional window, while closing them sheet, then panel worked perfectly. Now, no matter what order you close them, or whether or not you open the sheet, closing the panel hides the browser window.

	Neil Deakin Assignee
	Comment 6 • 17 years ago

(In reply to comment #4)
> Can you explain what's going on here? I'm lost.
> 

The part of the code does: when Show(PR_FALSE) is called for a panel, unhook the panel from its parent window. The patch adds a makeKeyAndOrderFront call which ensures the parent window is ordered on the front and a key window (key window means focused window). I don't know why the window isn't already the front one, but this patch fixes the issue.
 

	Josh Aas
	Comment 7 • 17 years ago

This is better I think. No need for the makeKeyAndOrderFront call and no need for the z-level event.

	Damon Sicore (:damons)
	Comment 8 • 17 years ago

Per mac meeting discussion, this will block beta 2.  We need to get this landed ASAP once Neil reviews.

	Josh Aas
	Comment 9 • 17 years ago

landed on trunk

	Marcia Knous [:marcia]
	Comment 10 • 17 years ago

verified fixed using  Mozilla/5.0 (Macintosh; U; PPC Mac OS X 10.5; en-US; rv:1.9b2pre) Gecko/2007120604 Minefield/3.0b2pre. I verified using the STR in Comment 0.

	Marcia Knous [:marcia]
	Comment 11 • 17 years ago

https://litmus.mozilla.org/show_test.cgi?id=5048 is the test case added to Litmus.