Closed Bug 313988 Opened 19 years ago Closed 19 years ago

[10.3] Positioned select drop-down doesn't work

Categories

(Core Graveyard :: Widget: Mac, defect)

Product:
Core Graveyard
Component:
Widget: Mac
Version:
1.8 Branch
Platform:
PowerPC
macOS
Type:
defect
Priority:
Not set
Severity:
major

Tracking

(Not tracked)

Status:
RESOLVED FIXED
Milestone:
mozilla1.8.1

People

(Reporter: michael.graubart7, Assigned: mark)

References

(
URL
)

Details

(4 keywords)

Attachments

(5 files, 2 obsolete files)

Testcase from duped bug
815 bytes, text/html
Details
New testcase using document.body.offsetheight;
730 bytes, text/html
Details
Testcase with more interesting behavior
731 bytes, text/html
Details
Screenshot of "partial menu" behavior
12.03 KB, image/jpeg
Details
Use the already-known window content rect
1.96 KB, patch
jaas
: review+
mikepinkerton
: superreview+
dveditz
: approval1.8.0.1+
dveditz
: approval1.8.1+
Details | Diff | Splinter Review 
User-Agent:       Mozilla/5.0 (Macintosh; U; PPC Mac OS X Mach-O; en-US; rv:1.9a1) Gecko/20051026 SeaMonkey/1.1a
Build Identifier: Mozilla/5.0 (Macintosh; U; PPC Mac OS X Mach-O; en-US; rv:1.9a1) Gecko/20051026 SeaMonkey/1.1a

The drop-down menus for product type and specific product do not drop down.

This bug goes back at least as far as Build 20051019.

Reproducible: Always

Steps to Reproduce:
1. Click on a menu or its arrow-head.

Actual Results:  
The menu is highlighted but does not drop down.

Expected Results:  
The menu should drop down.

eMac G4, OS X 10.3.9, Classic theme.
I bet it's the site's fault. But someone who knows js better than me should probably take a look.
Stefan: it may well be the site's fault; and the bug/site fault appears as long ago as Build 20051019. But in Mozilla 1.7.12 the drop-down menus do drop down, and so they do in Safari.
worksforme with linux seamonkey trunk CVS 20051028.

Are there any errors in the JS console? Can you make a testcase that exhibits the problem?  Can you narrow down when this broke?
Assignee: general → nobody
Component: General → Layout: Form Controls
Product: Mozilla Application Suite → Core
QA Contact: general → layout.form-controls
Version: unspecified → Trunk
I have gone back to the earliest build of SeaMonkey that I can find on http://ftp.mozilla.org/pub/mozilla.org/seamonkey/nightly/, i.e. 20050703. The bug is still present in that build. So it must have been introduced between Mozilla 1.7.12 and SeaMonkey 20050703.

I presume that js is OK, because the drop-down menus do work in Mozilla 1.7.12; in any case I don't know what to do about it. And what do you mean by a testcase? A screenshot? That would not tell you anything, because it would not demonstrate the failure of the menus to drop down.
hmm.  What about Mozilla builds.  You could just try the alphas (1.8a1-6) and beta (1.8b).

By a testcase, I mean a minimal html document (with css/style and/or js as necessary) that exhibits the bug.  http://www.mozilla.org/newlayout/bugathon.html#testcase
I have so far failed to discover where I can download the Mozilla builds you mention from. As for the testcase procedure, it is too complicated and time-consuming for me. I am prepared to spend a certain amount of time on reporting SeaMonkey bugs, but I have my own work and my life, which have nothing to do with computers and software, to attend to.
The bug is not present, i.e. the drop-down menus do drop down, in Mozilla 1.8b1.
I can confirm this with 2005102510 on Mac OS 10.3.9. I get a bunch of js warnings in the console that might or might not be related.

Loading the page gives me this:

Warning: assignment to undeclared variable browserName
Source File: http://www.epson.lv/
Line: 38

(+ same warning, but variables 'browserVer', 'version', 'countryarray', 'country' and 'filename')

Warning: deprecated with statement usage
Source File: http://esupport.epson-europe.com/scriptJS.aspx?LNG=en-LV
Line: 28
Source Code:
with(document.layers[layerName].document)

Clicking on the drop-down list sometimes gives me this:

Warning: assignment to undeclared variable selectvalue
Source File: http://esupport.epson-europe.com/scriptJS.aspx?LNG=en-LV
Line: 120

Warning: assignment to undeclared variable selecttext
Source File: http://esupport.epson-europe.com/scriptJS.aspx?LNG=en-LV
Line: 121
Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.8b5) Gecko/20051003 Firefox/1.4.1

I see the same warnings in the JS console, but the drop-down menus WFM on Linux,
so this seems to be unrelated. Issue may be Mac OS X only (which I can't test).

Confirming anyway based on Stefan's comments.
Status: UNCONFIRMED → NEW
Ever confirmed: true
Hmm, this happens on the 1.8 branch too. I can repro the issue with a recent seamonkey branch build on mac. However, I can't reproduce with Firefox 1.5rc1.
Re #11: on my Mac (OS 10.3.9), the arrow and menu work on the eBay site, but on the Epson one clicking on the text-area doesn't work any better than clicking on the arrow.
OK, so I have a regression range here:

Works with: 2005092916 (from the m.o. 2005-09-29-17 dir)
Does not work with: 2005093010 (from the m.o. 2005-09-30-11 dir)

Michael, I tried 2005070312 and it works for me here. I need to click twice, though.


(In reply to comment #13)
> Re #11: on my Mac (OS 10.3.9), the arrow and menu work on the eBay site, but on
> the Epson one clicking on the text-area doesn't work any better than clicking
> on the arrow.
> 
Even the search options at the left?
Keywords: regression
Stefan, I can confirm that in 2005070312 clicking twice works for me, too. (But not in 2005110110!)
Hmm, I can actually repro this in Firefox 1.5rc1. I must have tried the topmost ebay one.
*** Bug 314797 has been marked as a duplicate of this bug. ***
I have found another pair of drop-down menus in an Epson webpage that do not drop down. On www.epson.co.uk, near the right-hand foot of the page, there are similar menus for products, etc., which similarly do not work.

This in Build 2005110909, on an emac G4 with OS X 10.3.9 and Classic theme.
Has anyone been able to pinpoint a specific regression period? Comment 4 indicates that this is a longstanding issue, while comment 14 has a more specific date. Are there two seperate issues?
If the regression range in comment 14 is correct, I'd guess that this is a regression from bug 304089. Also, bug 311601 has some screenshots and testcases, can anyone confirm that this bug is indeed the same as that one?
Stefan, I have only just realized that I did not respond to 'Even the search options at the left?' in #14. If you mean 'Products' in the menu bar at the top of the page, there has never been a problem with that. If you mean the little slot that says 'Select an option…' — where the drop-down menu should appear, — that's what I meant by 'text area', and neither clicking nor double-clicking on it achieves anything. (eMac G4, OS X 10.3.9; SeaMonkey now 2005111010).
*** Bug 311601 has been marked as a duplicate of this bug. ***
*** Bug 316192 has been marked as a duplicate of this bug. ***
> <!-- Bizarrely, both script blocks (with "src") are necessary, even if
>      they are empty and don't have working addresses (as below). -->

It's likely this is actually timing-sensitive.  Can you try sprinkling <script>document.body.offsetHeight;</script> in various places to get a better testcase?  See http://weblogs.mozillazine.org/hyatt/archives/2003_08.html#003963
Steuard, please see comment #25


This is a modification of my "reliable" testcase that was already copied over to this bug.  The only real modification is that suggested in comment #25: I replaced the two empty script tags (with 'src=""') with a single script element <script>document.body.offsetHeight;</script>.  (I also increased the left margin a bit more, just to make it that much more likely to succeed on all computers.)  As predicted, the behavior remains the same: the pulldown menu doesn't show up at all.

Mind you, if this _is_ a timing issue, it seems to be a remarkably consistent one: I've yet to find a situation where the behavior wasn't completely reproducable (either success or failure) on my machine.  But I could imagine it being machine dependent (as some comments in bug 311601 might suggest).  For the record, I'm using a PowerBook G4 1.25 GHz with 512Mb RAM running Mac OS 10.3.9.
This updates my original testcase in bug 311601 to use the suggestion in comment #25.  The only difference is that the left margin is substantially smaller in this case.  According to comments in bug 311601, some people don't see the bug in this case.  But on my machine, the behavior is particularly striking: _part_ of the pulldown menu is shown, but only a sliver on the left-hand side.  (I'll attach a screenshot shortly.)

By adjusting the left margin of the "#contents" div, you can change how much or how little of the pulldown menu is visible.  I find it particularly odd that the "cut off line" changes _faster_ than the actual position of the <select> element (that is, the cut off line is moving too; it's not at a fixed position on the page).

If you don't see the "partial menu" behavior that I'm describing here, download the testcase and adjust the left margin value to find the exact point where the menu disappears.  (Smaller margins make the menu visible, larger ones make it invisible.)  There should be a small range of margin values in which only a part of the menu is shown.  I'd be interested to know how that range differs on different systems.
This is a screenshot of the "partial menu" behavior described in comment #28, based on the testcase immediately above.  My apologies for all the bug spam.

Incidentally, while I'm already spamming, I'll mention that for those who prefer pixel units, I get the "partial menu" behavior (to different degrees) for left margins of 77px (sliver) and 76px (a bit more than half).  The testcase and screenshot above use a left margin of 4.8em, which on my machine shows a bit more of the menu than 77px does.
Re ##27, 28, 29: On my machine (eMac G4, OS X 10.3.9, Classic theme) on the webpage <http://www.epson.lv/> I can make a single item appear in the space for the upper menu ('Product Type') by clicking the arrow of the lower ('Product') menu. That single item is then correctly placed within the confines of the rectangle in which the menu should appear, so on my machine it doesn't seem to be a left-right margin issue, but one of making the rest of the menu appear vertically.
Woops I didn't see this one and just submitted bug 317084 which seems to be related.

I've been able to narrow it down to being a position: relative; issue, if any of the select container's parents [all the way back up the DOM] are positioned that way.  I have been seeing it when hiding or showing elements.  The script tag must somehow be triggering it as well.

I have worked out a couple workaround for us web devs until this can be fixed in the Gecko core.  See the URL on bug 317084 for my test case & solutions (CSS based solutions).

I've tried a number of the Test Cases listed in the comments here, and every one using either of my CSS solutions fixes. [not ideal but works for as a web dev until the issue can be resolved internally]
Hmm, on what versions of Mac OS X do people see this? As the original reporter, I see this on 10.3.9. Does anyone see this on Tiger?
Summary: The drop-down menus on this web page do not work. → Select drop down doesn't work
(In reply to comment #32)
> Hmm, on what versions of Mac OS X do people see this? As the original reporter,
> I see this on 10.3.9. Does anyone see this on Tiger?
> 

10.3.9 here as well
I can confirm that I'm seeing the same regression range as Stefan in comment #14

Using the nightly builds found in http://ftp.mozilla.org/pub/mozilla.org/seamonkey/nightly/, it works up till and including the 2005-09-29-17 build. From 2005-09-30-11 onward, it doesn't work.

Hope that helps.
(In reply to comment #32)
> Hmm, on what versions of Mac OS X do people see this? As the original reporter,
> I see this on 10.3.9. Does anyone see this on Tiger?

"original reporter," eh? i filed bug 311601 almost three weeks before this report, though somehow it got marked as a dupe of this one. so, where do i get in line to borrow your time machine? ;) ;)

seriously, my report was on 10.3.9 as well.


> "original reporter," eh? i filed bug 311601 almost three weeks before this
> report, though somehow it got marked as a dupe of this one. so, where do i get
> in line to borrow your time machine? ;) ;)

I actually ment "As Michael (the original reporter of this bug) I'm on 10.3.9...


Mark, any idea of what's going on here? Comment #20 mentions 304089 as a possible cause of this regression.
Flags: blocking1.8.1?
Flags: blocking1.8.0.1?
Hello?  Any news on this?  It sure would be nice to get it fixed before Firefox 1.5 Final is released.  I think we've given more than enough information for the team to be able to track it down.  Debunk that myth that the Mozilla devs don't care about OS X users; or prove it is true.
1.5 is being released in a few hours, this won't be fixed there. It could potentially make a followup release, however.

I mentioned bug 304089, but bug 301411 could potentially be the culprit. None of the other fixes checked in during that time frame should have affected this, but stranger things have happened! Backing out those fixes locally is the best way to find out.
Then why even bother releasing 1.5 for the Mac at all?  You guys do realize this break nearly every modern website that uses drop down lists. It's only marked as normal but if you've tried to use 1.5 on the Mac OS X 10.3.9 at all, you'd realize it is a pretty major bug.
(In reply to comment #40)
> Then why even bother releasing 1.5 for the Mac at all?  You guys do realize
> this break nearly every modern website that uses drop down lists. It's only
> marked as normal but if you've tried to use 1.5 on the Mac OS X 10.3.9 at all,
> you'd realize it is a pretty major bug.

This issue was simply recognized too late in the development cycle to be fixed in time.  It doesn't affect all Mac users (see for example bug 311601 comment 7); all reports thus far have listed the same Mac OS version.  And in my experience, only a handful of websites are affected (doesn't bugzilla count as a "modern website that uses drop down lists"?); working around the bug by selecting the menu and then using the arrow keys is annoying but generally livable.

It might have been different if someone had come up with a patch already, but they haven't (as Gavin has pointed out, we don't even know for sure what caused the regression).  As it stands, I'm hopeful that this will get fixed in a minor release quite soon, once the push to get 1.5 out the door is over.
(In reply to comment #39)
> I mentioned bug 304089, but bug 301411 could potentially be the culprit. ...
> Backing out those fixes locally is the best way to find out.

With help from your new URL above, I've verified that backing out fixes for bug 304089 does resolve the issue.  Of course, the "Access Denied" message for that bug suggests that those were apparently introduced to address a security hole, so someone who knows the issue involved will have to fix it.  (Backing out bug 301411 had no effect.)
Assignee: nobody → mark
Severity: normal → major
Keywords: testcase
Sounds like mine, then.
(In reply to comment #41)
> (doesn't bugzilla count as
> a "modern website that uses drop down lists"?); working around the bug by
> selecting the menu and then using the arrow keys is annoying but generally
> livable.

No sorry bugzilla is nice but is not "modern".. HTML 4 Transitional?  It doesn't take much to trigger the bug... just some layers or some javascript. That's what I mean by "modern"

Livable for who?  Developers? yeah maybe.  Actual users? probably not ;)
Nobody's seen this in 10.4, right?  It's probably a display manager bug in 10.3, I'll need to see for sure next time I'm sitting at a Panther.
(In reply to comment #45)
> Nobody's seen this in 10.4, right?  It's probably a display manager bug in
> 10.3, I'll need to see for sure next time I'm sitting at a Panther.
> 

Mark I cannot be 100% certain since I don't have Tiger, but over at MacNN, everyone on Tiger says they are not seeing the problem.
*** Bug 317084 has been marked as a duplicate of this bug. ***
This bug is still present in Build 2005121210. May I append a cri de coeur that I added to another bug report a few days ago, so that it reaches people on the mailing list for the present bug, too?

I hope all those hardworking and dedicated experts who are developing SeaMonkey
will not be offended and will take the following remarks in the positive spirit
in which they are meant when I (as a non-expert user and devotee of SeaMonkey)
say that I am dismayed by the way in which, in recent weeks, successive builds
have accrued more and more serious bugs which directly impact on ordinary
users. Examples are the failure of 'Sort folder…' in Bookmark Manager, the failure of Drop-Down Menus to drop down and the failure of Password Manager to remember names and passwords. 

I am sure all sorts of subtle enhancements which are invisible to the naked eye
are being introduced, but in my humble opinion all efforts should be devoted to
eliminating such major bugs (which actually make it hard, or even impossible,
to use SeaMonkey for ordinary, everyday tasks) before adding new features or
tinkering with problems that most users never encounter. (It is, surely, also
regretable that some of these major bugs have got into the latest release of
FireFox: the Bookmarks Manager one is not applicable; the Password Manager bug
does not appear in FireFox 1.5; but the Drop-Down Menu one does).

I hope the apparent lack of attention to these major bugs in Mac builds is not
due to a lack of concern for Mac users. Mac users may not be numerically as
great as PC/Windows users, but they make up in quality (especially in the
graphics, the photographic and and generally the arts worlds) what they lack in
quantity!
Status: NEW → ASSIGNED
Attached patch Work around bad window offsets (obsolete) — — Splinter Review 
On 10.3.9, GetWindowBounds is returning evil values for kWindowContentRgn.  The (top,left) values of the rect it returns are twice as large as they should be.  For pop-up windows, kWindowContentRgn and kWindowStructureRgn should be identical, indicating zero offset.  Instead, we were getting wild offsets.

Since bug 304089, Resize uses the offset in computing the appropriate maximum resize bounds.  Because the offset was potentially large, Resize was setting erroneous maximum bounds.  In most cases, this resulted in an effective resize to zero width or height, so nothing appeared to pop up.  It's also possible to devise a case with nonzero but still incorrect effective widths or heights, and wind up with cut-off popups along the lines of attachment 202985 [details].

This bug is not present in Tiger, which properly returns the same values for kWindowContentRgn and kWindowStructureRgn for pop-up windows, indicating zero offset.

The workaround in this patch is to always zero out the offset for pop-up windows instead of computing it based on potentially incorrect information from the system.  This is safe because we know that pop-up windows are always of window class kSimpleWindowClass, and that class is defined as having no frame.
Attachment #207109 - Flags: superreview?(mikepinkerton)
Attachment #207109 - Flags: review?(joshmoz)
Comment on attachment 207109 [details] [diff] [review]
Work around bad window offsets

not a big fan, but....

sr=pink
Attachment #207109 - Flags: superreview?(mikepinkerton) → superreview+
Another idea is to create all new windows at (0,0) and then move them after getting the offsets.  Seems like overkill, but it might handle more presently unknown cases.
Attachment #207109 - Flags: review?(joshmoz)
This is an alternate patch that also fixes the bug.  This one creates all new windows at (0,0) and then calls MoveWindow to put them where they belong.

We already create most windows at (0,0) anyway, but the affected pop-ups are positioned differently and Create is getting nonzero window origins.  What makes this patch preferable is that it might cover currently unknown cases beyond pop-ups where the system gives back bad structure/content data, and it might cover us if we ever start passing nonzero origins to Create for other things.

But I can do better.  Watch this...
Duh.  We already know what the content rect is, because we set it ourselves as wRect in the CreateNewWindow call.  There's no need to get it again, we can just use wRect.
Attachment #207109 - Attachment is obsolete: true
Attachment #207117 - Attachment is obsolete: true
Attachment #207118 - Flags: superreview?(mikepinkerton)
Attachment #207118 - Flags: review?(joshmoz)
Comment on attachment 207118 [details] [diff] [review]
Use the already-known window content rect

i like this better. sr=pink.
Attachment #207118 - Flags: superreview?(mikepinkerton) → superreview+
Note: this is a problem in 10.3.9.  It's not a problem in 10.2.8.
Component: Layout: Form Controls → Widget: Mac
Summary: Select drop down doesn't work → [10.3] Positioned select drop-down doesn't work
Attachment #207118 - Flags: review?(joshmoz) → review+
Checked in on the trunk.
Status: ASSIGNED → RESOLVED
Closed: 19 years ago
Resolution: --- → FIXED
Comment on attachment 207118 [details] [diff] [review]
Use the already-known window content rect

Requesting approval1.8.0.1.  This is a real usability show-stopper on Panther.  Most positioned <select> drop-downs don't open at all.  The risk is low: rather than making a call into the OS to retrieve values that we had set one function call prior, this patch lets us use the values that we know to be correct.
Attachment #207118 - Flags: approval1.8.0.1?
I'm delighted to say that this bug has been fixed in Build 2006010309 (on eMac G4 with OS X 10.3.9), at least on the Epson website on which I first discovered the bug.
Comment on attachment 207118 [details] [diff] [review]
Use the already-known window content rect

a=dveditz
Please add the fixed1.8.0.1 and fixed1.8.1 keywords when checked in.
Attachment #207118 - Flags: approval1.8.1+
Attachment #207118 - Flags: approval1.8.0.1?
Attachment #207118 - Flags: approval1.8.0.1+
Flags: blocking1.8.1?
Flags: blocking1.8.1+
Flags: blocking1.8.0.1?
Flags: blocking1.8.0.1+
Checked in to 1_8 and 1_8_0.
Keywords: fixed1.8.0.1, fixed1.8.1
*** Bug 322357 has been marked as a duplicate of this bug. ***
Target Milestone: --- → mozilla1.8.1
verified on the branching using Mac OS X 10.3.9, Mozilla/5.0 (Macintosh; U; PPC Mac OS X Mach-O; en-US; rv:1.8.0.1) Gecko/20060111 Firefox/1.5.0.1. I tried all three test cases and everything looks good.
Keywords: fixed1.8.0.1 → verified1.8.0.1
*** Bug 325225 has been marked as a duplicate of this bug. ***
Product: Core → Core Graveyard
Version: Trunk → 1.8 Branch
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Creator:
Created:
Updated:
Size: