Since the 20040831 builds, almost all my pulldown menus are appearing in the top-left corner. It didn't happen in the 20040830 builds. Erasing the XUL.mfasl and localstrore.rdf files didn't help. I'm running Mac OS X 10.2.8, and I'm seeing it both in Seamoney (trunk) and Firefox (1.0 branch). Mozilla/5.0 (Macintosh; U; PPC Mac OS X Mach-O; en-US; rv:1.8a3) Gecko/20040831 Mozilla/5.0 (Macintosh; U; PPC Mac OS X Mach-O; en-US; rv:1.7.3) Gecko/20040831 Firefox/0.9.1+ I see it with : - location pulldown - search engine pulldown (in FF) - right click pulldown on toolbar (icon-pulldowns are ok) - all right-click popups in the browser area - most title-popups Once in a while I see pulldowns that are in the correct place, or that jump back to the correct place (esp when closing the pulldown again), but that's not always repeatable. Most pulldowns that are attached to buttons (in the mail-interface f.e.) work ok, except for the location pulldown and the search engine pulldown. A major regression caused by bug 223545 ? I downloaded the 20040830 builds to verify the path for bug 223545, but it wasn't in the build yet, and I didn't see this error, only in the 20040831 builds. It looks like it's related to bug 257546 (sheets appearing in top-left corner), but that might be because I've never seen that before. I'm in the office now, but I can post a screendump later today. And I'll try to create a new profile.

Do you make your own builds? I could attach a patch to try out if you do, otherwise I'll have to make an OPT build and mail it to you.

(In reply to comment #1) > Do you make your own builds? I could attach a patch to try out if you do, > otherwise I'll have to make an OPT build and mail it to you. No, I don't make builds anymore. You could mail it to jo.hermans(AT)gmail.com (this spamgourmet.com address is actually a spamtrap), but there's a 10MB limit. I'll try to contact later tonight (IRC or mail), to see if I can find a FTP-server somewhere. Groetjes :-)

a new profile didn't help

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

It looks as a <= 10.2 only bug.

Probably so. I experience this only with my Beige G3 which has 10.2. All other Mac's I have are loaded with 10.3 and I don't experience this problem with them. (In reply to comment #5) > It looks as a <= 10.2 only bug.

Can anyone help with trying out this patch on a 10.2 system? I'm still building, hopefully I can put up a build with this patch for people to try out.

I've put up a build with this patch at http://people.mozilla-europe.org/peterv/Mozilla.app.sit Note that since I can't test on anything other than 10.3.5 it could be that it doesn't even start. I'm particulary interested in tests with 10.2.x.

Also, is anyone actually seeing this bug on anything below 10.2?

i tried peterv's special build on 10.2.8 and it still happens. I see: - context menus and bookmark folder menus in upper left - when switching from moz to the finder, the insertion point doesn't stop blinking even though Moz is in the background

Sorry to say, but I still experience the same problem with this build. (In reply to comment #9) > I've put up a build with this patch at > http://people.mozilla-europe.org/peterv/Mozilla.app.sit Note that since I can't > test on anything other than 10.3.5 it could be that it doesn't even start. I'm > particulary interested in tests with 10.2.x.

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

(In reply to comment #9) > I've put up a build with this patch at > http://people.mozilla-europe.org/peterv/Mozilla.app.sit Note that since I can't > test on anything other than 10.3.5 it could be that it doesn't even start. I'm > particulary interested in tests with 10.2.x. Tested on Mac OS 10.2.8. It starts (compared to those *.sitx files that you first mailed to me), but it still has the error.

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

This fixes it for me. I've put up a new build with this fix at http://people.mozilla-europe.org/peterv/Mozilla.app.sit.

This build works fine, no problem. The popup menu shows up where it's supposed to show up. (In reply to comment #16) > Created an attachment (id=158525) > v2 > > This fixes it for me. I've put up a new build with this fix at > http://people.mozilla-europe.org/peterv/Mozilla.app.sit.

(In reply to comment #16) > Created an attachment (id=158525) > v2 > > This fixes it for me. I've put up a new build with this fix at > http://people.mozilla-europe.org/peterv/Mozilla.app.sit. Works for me too on Mac OS X 10.2.8. Thanks Peter ! When I read the patch and compare with the other code in nsWindow.cpp, I noticed something strange. Or maybe it's the effect of last nights party :-) Apple-header /CarbonHeaders/AvailabilityMacros.h is supposed to contain the following defines (I don't have a develop enviroment anymore, but that's what I found on the web) : #define MAC_OS_X_VERSION_10_0 1000 #define MAC_OS_X_VERSION_10_1 1010 #define MAC_OS_X_VERSION_10_2 1020 #define MAC_OS_X_VERSION_10_3 1030 These are decimal constants ! Why is Mozilla using hexadecimal ones ?

See http://developer.apple.com/documentation/Carbon/Reference/Gestalt_Manager/gestalt_refchap/constant_180.html "represented as four hexadecimal digits in the low-order word of the return value"

(In reply to comment #19) > See > http://developer.apple.com/documentation/Carbon/Reference/Gestalt_Manager/gestalt_refchap/constant_180.html > > > "represented as four hexadecimal digits in the low-order word of the return value" Ah, no I see what the problem was. The MAC_OS_X_VERSION_10_* macros were supposed to be used in #define's (for conditional compilation), but nsMacWindow.cpp, nsWindow.cpp and nsToolkit.cpp were using them to compare against the output of Gestalt(). That was a big mistake.

Comment on attachment 158525 [details] [diff] [review] v2 - // XXX Need to special-case for OS X versions below 10.1, because + // XXX Need to special-case for OS X versions below 10.3, because // kSimpleWindowClass doesn't exist. if (mWindowType == eWindowType_popup && - nsToolkit::OSXVersion() < MAC_OS_X_VERSION_10_1) + nsToolkit::OSXVersion() < 0x00001030) Why did you make this change? According to the documentation, kSimpleWindowClass is available in 10.1 or later. Did you find otherwise?

I suppose I should change the comment, changing that from < 10.1 to < 10.3 is what fixes this bug. kSimpleWindowClass does seem to exist under 10.2.8 but the window shows up in the wrong place at first. No idea why.

Comment on attachment 158525 [details] [diff] [review] v2 > kSimpleWindowClass does seem to exist under 10.2.8 but the window shows up in the wrong place at first. That is strange. Maybe we should open a bug report with Apple. One minor nit: could you create defines for the OS versions, to make the code more readable? Something like: #define MAC_OS_X_VERSION_10_2_HEX 0X00001020 Otherwise, it looks good.

Mozilla/5.0 (Macintosh; U; PPC Mac OS X Mach-O; en-US; rv:1.8a4) Gecko/20040914 Thunderbird/0.6+ Today's build. Mac OS X 10.2.6 Still in - I presume that the patch has not yet been applied to the CVS trunk.

This includes the patch from bug 206649 since that fixes the positioning problem.

Comment on attachment 159124 [details] [diff] [review] v2.1 sr=jst

Checked this in on the trunk, please test and let me know if it's fixed so I can try to get bug 223545 and this one on the branch.

2004-09-17-05-trunk build works fine on MacOSX10.2.8. Title-popups on personal toolbar and context menu are OK. Location pulldown is OK, too. It seems that this bug is gone. Thanks!

Comment on attachment 159124 [details] [diff] [review] v2.1 Asking for approval, though it can only go together with the patch for bug 223545 (this one fixes a regression caused by the patch for that bug).

This works fine with 10.2.8. No problem! (In reply to comment #27) > Checked this in on the trunk, please test and let me know if it's fixed so I can > try to get bug 223545 and this one on the branch.

Mozilla/5.0 (Macintosh; U; PPC Mac OS X Mach-O; en-US; rv:1.8a4) Gecko/20040918 Firefox/0.9.1+ Today's build from head. Mac OS X 10.2.6 Now appears fixed. Incidentally, the faulty bahaviour was also in Thunderbird compiled from source, but context menus are not as widespread in that program, and I never saw it reported as a bug.

Comment on attachment 159124 [details] [diff] [review] v2.1 a=asa for aviary checkin.

Checked in to aviary branch. -> FIXED

Peter and Javier... If you have a sec, could you please take a look at bug 261758 and tell me if you think it's related to this one? The effect is similar (although affecting a different window type) and they started at around the same time. Thanks :)

Scratch that. I'm getting my months mixed up. The other bug began a month before this one. Apologies for the spam.

Asaf: Only drivers may set blocking flags.

Alex: The bug is already fixed on the aviary branch (read comment 33), there is no need to request blcoking? on bugs which are already fixed. Please check before bug spaaming everyone, thanks.