All users were logged out of Bugzilla on October 13th, 2018

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

RESOLVED FIXED

Status

--
major
RESOLVED FIXED
14 years ago
10 years ago

People

(Reporter: jo.hermans, Assigned: peterv)

Tracking

(4 keywords)

Trunk
PowerPC
Mac OS X
fixed-aviary1.0, fixed1.7.5, qawanted, regression

Firefox Tracking Flags

(Not tracked)

Details

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

Attachments

(1 attachment, 2 obsolete attachments)

(Reporter)

Description

14 years ago
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.
(Reporter)

Updated

14 years ago
Summary: pulldown menus in left-hand corner (regression from 223545 ?) → pulldown menus in top-left corner (regression from 223545 ?)
(Assignee)

Comment 1

14 years ago
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.
(Reporter)

Comment 2

14 years ago
(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 :-)
(Reporter)

Comment 3

14 years ago
a new profile didn't help
Flags: blocking1.8a4?
Flags: blocking1.7.x?
Flags: blocking-aviary1.0PR?
(Assignee)

Updated

14 years ago
No longer blocks: 257800
(Assignee)

Comment 4

14 years ago
*** Bug 257800 has been marked as a duplicate of this bug. ***
It looks as a <= 10.2 only bug.
Keywords: qawanted

Comment 6

14 years ago
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.

Updated

14 years ago
Whiteboard: regression from 223545 - back that one out?
(Assignee)

Comment 7

14 years ago
Created attachment 157783 [details] [diff] [review]
v1
Assignee: general → peterv
Status: NEW → ASSIGNED
(Assignee)

Comment 8

14 years ago
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.
(Assignee)

Comment 9

14 years ago
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.
(Assignee)

Comment 10

14 years ago
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

Comment 12

14 years ago
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. ***
(Reporter)

Comment 14

14 years ago
(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. ***
(Assignee)

Comment 16

14 years ago
Created attachment 158525 [details] [diff] [review]
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.
Attachment #157783 - Attachment is obsolete: true
(Assignee)

Updated

14 years ago
Attachment #158525 - Flags: superreview?(bryner)
Attachment #158525 - Flags: review?(jhpedemonte)

Comment 17

14 years ago
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.
(Reporter)

Comment 18

14 years ago
(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 ?
(Assignee)

Comment 19

14 years ago
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"
(Reporter)

Comment 20

14 years ago
(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?
(Assignee)

Comment 22

14 years ago
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.
(Reporter)

Updated

14 years ago
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+

Comment 24

14 years ago
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.
(Assignee)

Comment 25

14 years ago
Created attachment 159124 [details] [diff] [review]
v2.1

This includes the patch from bug 206649 since that fixes the positioning
problem.
Attachment #158525 - Attachment is obsolete: true
(Assignee)

Updated

14 years ago
Attachment #159124 - Flags: superreview?(jst)
Attachment #159124 - Flags: review?(jhpedemonte)
(Assignee)

Updated

14 years ago
Attachment #158525 - Flags: superreview?(bryner)
Comment on attachment 159124 [details] [diff] [review]
v2.1

sr=jst
Attachment #159124 - Flags: superreview?(jst) → superreview+

Updated

14 years ago
Attachment #159124 - Flags: review?(jhpedemonte) → review+
(Assignee)

Comment 27

14 years ago
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.

Comment 28

14 years ago
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!
(Assignee)

Comment 29

14 years ago
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?

Comment 30

14 years ago
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.

Comment 31

14 years ago
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 32

14 years ago
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
Last Resolved: 14 years ago
Keywords: fixed-aviary1.0
Resolution: --- → FIXED
Flags: blocking-aviary1.0mac? → blocking-aviary1.0mac+

Comment 34

14 years ago
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 :)

Comment 35

14 years ago
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

Updated

14 years ago
Keywords: fixed1.7.5
You need to log in before you can comment on or make changes to this bug.