Closed Bug 647720 Opened 13 years ago Closed 6 years ago

[10.7] Windows do not appear initially under OS X Lion

Categories

(Penelope Graveyard :: General, defect)

x86_64
macOS
defect
Not set
major

Tracking

(Not tracked)

RESOLVED WONTFIX

People

(Reporter: Nicolas.Widmer, Assigned: mdudziak)

References

(Blocks 1 open bug)

Details

User-Agent:       Mozilla/5.0 (Macintosh; Intel Mac OS X 10_7) AppleWebKit/534.26.4 (KHTML, like Gecko) Version/5.1 Safari/534.26.4
Build Identifier: 

When Eudora OSE 1.0 is launched under OS X Lion DP 2, the main window does not appear on the screen. One has to switch to any other application running and come again to Eudora in order to make this window appear.

Reproducible: Always

Steps to Reproduce:
1. Launch Eudora under OS X.7 DP 1 or 2 => nothing appears on screen
2. Switch to other application
3. Come back to Eudora => The main window is here.
Summary: "Local folders" window does not appears initially under OS X Lion → "Local folders" window does not appear initially under OS X Lion
Summary: "Local folders" window does not appear initially under OS X Lion → Windows does not appear initially under OS X Lion
Version: unspecified → 1.0
Windows concerned are every windows (i.e. "Local folders" windows, new messages windows, etc.).
Summary: Windows does not appear initially under OS X Lion → Windows do not appear initially under OS X Lion
Summary: Windows do not appear initially under OS X Lion → [10.7] Windows do not appear initially under OS X Lion
The final release of OS 10.7.0 is also concerned.
I suppose this is the same issue as bug 647227. Which gecko version does Eudora OSE 1.0 use?
I see the exact same thing in Komodo 6 - which is a XULRunner 1.9.1 application, though no problems in the same app when using XULRunner 2.0 (Komodo 7).

Note: Firefox 3.5 (which is also Mozilla 1.9.1 code) doesn't seem to have this problem.

Can anyone shed some light on this issue?
(In reply to comment #3)
> I suppose this is the same issue as bug 647227. Which gecko version does
> Eudora OSE 1.0 use?

The info box of Eudora OSE 1.0 contains the following information:
"Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.7; en-US; rv:1.9.1.9) Gecko/20100722 Eudora/3.0.4"
(In reply to comment #4)
> I see the exact same thing in Komodo 6 - which is a XULRunner 1.9.1
> application, though no problems in the same app when using XULRunner 2.0
> (Komodo 7).
> 
> Note: Firefox 3.5 (which is also Mozilla 1.9.1 code) doesn't seem to have
> this problem.

I wonder if this happens in a 1.9.1.x Thunderbird?

> Can anyone shed some light on this issue?

One guess is a different Hiddenwindow handling than Firefox. IIRC Thunderbird and Firefox are similar, hence my question (it's a shot in the dark, but it would be nice to rule that out). Another guess is that the startup code does something different for non-firefox apps.
Yes, Thunderbird 3.0.11 (based on Mozilla 1.9.1) shows the same problem.

Definitely seems limited to Mozilla 1.9.x as I tested some other versions as well:

 * Thunderbird 3.1.11 (1.9.2) - same problem
 * Thunderbird 2.0.0.24 (1.8.1) - okay
 * Thunderbird 5.0 (5.0) - okay
 * Komodo 5 (1.9.1) - same problem
 * Komodo 4 (1.8.1) - okay
I guess this probably happens to all non-firefox apps based on gecko 1.9.x then. Looking at bug 647227, comment #6, the window seems to be there, but not visible.
Seems like it - the menubar appears, the window is not made visible, though once I click on the Dock icon again the window will appear and it then works correctly.

I'm really curious as to what the difference is between Firefox 3.5 and any other 1.9.1 application would be - I don't think it's the shell integration components - as those bits seem to be about setting the default browser in the system...
I guess one way of finding out is to look at the code in http://mxr.mozilla.org/mozilla1.9.1/source/browser/ and see if there are any hooks that, for example, thunderbird doesn't have. Kind of time-consuming, though.

Running a 1.9.1 debug build might also help.
Penelope didn't see any activity in the vcs for the last 8 years, closing.
Status: UNCONFIRMED → RESOLVED
Closed: 6 years ago
Resolution: --- → WONTFIX
You need to log in before you can comment on or make changes to this bug.