Closed Bug 257647 Opened 18 years ago Closed 18 years ago

pulldown menus in top-left corner (regression from 223545) on OS X 10.2

Categories

(SeaMonkey :: General, defect)

PowerPC
macOS
defect
Not set
major

Tracking

(Not tracked)

RESOLVED FIXED

People

(Reporter: jo.hermans, Assigned: peterv)

References

Details

(4 keywords, Whiteboard: regression from 223545 - backed out from aviary branch)

Attachments

(1 file, 2 obsolete files)

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.
Summary: pulldown menus in left-hand corner (regression from 223545 ?) → pulldown menus in top-left corner (regression from 223545 ?)
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
Blocks: 257800
Flags: blocking1.8a4?
Flags: blocking1.7.x?
Flags: blocking-aviary1.0PR?
No longer blocks: 257800
*** Bug 257800 has been marked as a duplicate of this bug. ***
It looks as a <= 10.2 only bug.
Keywords: qawanted
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.
Whiteboard: regression from 223545 - back that one out?
Attached patch v1 (obsolete) — Splinter Review
Assignee: general → peterv
Status: NEW → ASSIGNED
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.

Flags: blocking-aviary1.0PR?
Summary: pulldown menus in top-left corner (regression from 223545 ?) → pulldown menus in top-left corner (regression from 223545) on OS X 10.2
Whiteboard: regression from 223545 - back that one out? → regression from 223545 - backed out from aviary branch
*** 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. ***
Attached patch v2 (obsolete) — Splinter Review
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.
Attachment #157783 - Attachment is obsolete: true
Attachment #158525 - Flags: superreview?(bryner)
Attachment #158525 - Flags: review?(jhpedemonte)
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.
Flags: blocking-aviary1.0mac?
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.
Attachment #158525 - Flags: review?(jhpedemonte) → review+
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.
Attached patch v2.1Splinter Review
This includes the patch from bug 206649 since that fixes the positioning
problem.
Attachment #158525 - Attachment is obsolete: true
Attachment #159124 - Flags: superreview?(jst)
Attachment #159124 - Flags: review?(jhpedemonte)
Attachment #158525 - Flags: superreview?(bryner)
Comment on attachment 159124 [details] [diff] [review]
v2.1

sr=jst
Attachment #159124 - Flags: superreview?(jst) → superreview+
Attachment #159124 - Flags: review?(jhpedemonte) → review+
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).
Attachment #159124 - Flags: approval-aviary?
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.
Attachment #159124 - Flags: approval-aviary? → approval-aviary+
Checked in to aviary branch.  -> FIXED
Status: ASSIGNED → RESOLVED
Closed: 18 years ago
Keywords: fixed-aviary1.0
Resolution: --- → FIXED
Flags: blocking-aviary1.0mac? → blocking-aviary1.0mac+
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.
Flags: blocking-aviary1.0mac+ → blocking-aviary1.0mac?
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.
Flags: blocking-aviary1.0mac?
Product: Browser → Seamonkey
Keywords: fixed1.7.5
You need to log in before you can comment on or make changes to this bug.