Closed Bug 269561 Opened 18 years ago Closed 18 years ago
Dropup/dropdown boxes leave gray box visible after selection if <select> has height/width on Mac
55.08 KB, image/jpeg
39.31 KB, image/jpeg
3.12 KB, text/html
70.94 KB, image/jpeg
55.68 KB, image/jpeg
44.17 KB, image/jpeg
1.80 KB, patch
|Details | Diff | Splinter Review|
User-Agent: Mozilla/5.0 (Macintosh; U; PPC Mac OS X Mach-O; en-US; rv:1.8a5) Gecko/20041029 Firefox/0.9.1+ Build Identifier: Mozilla/5.0 (Macintosh; U; PPC Mac OS X Mach-O; en-US; rv:1.8a5) Gecko/20041029 Firefox/0.9.1+ In Mozilla and Firefox Mac trunk builds starting on 10/30/04 and continuing to the present, after I select an item from a "dropup box" (where choices drop upwards instead of dropping down), then the entire box is replaced by an equally-sized gray square with scrollbars which cannot be removed. Reproducible: Always Steps to Reproduce: 1. Go to http://apps.ati.com/cservice/webformcontactPreSales.asp?cboPrePostSales=_PreSales&cmdNext=Continue 2. Click the triangle that asks for your state. 3. Choices will appear above the triangle. (See "mozbox1.jpg" for example.) 4. Pick any state. 5. Observe area where choices appeared. Actual Results: The area where the choices appeared has now been replaced by an equally-sized gray square with scrollbars. (See "mozbox2.jpg" for example.) Sometimes, if you move the window, the square will move with it. Other times, the square stays fixed if the window is moved. Expected Results: When the dropup box selection was made, the text under the choices should have reappeared and no gray box should appear. Problem occurs in Chrome & Modern themes in Mozilla and Modern & Default Theme in Firefox. The 10/29/04 Firefox and Mozilla Mac trunk builds did not experience this bug. All builds of 10/30/04 of Firefox and Mozilla Mac trunk builds do experience the bug.
Note: This bug has appeared for me on several sites that use dropup boxes, not just the URL listed in this report.
Confirmed with Mozilla 2004111207-trunk/Mac. 2004111204-trunk/Win has no problem. regression. Marking New.
Status: UNCONFIRMED → NEW
Ever confirmed: true
<select style="HEIGHT: 22px; WIDTH:310px"> causes this problem on Mac. Over to View Rendering for the moment.
Component: XP Toolkit/Widgets: Menus → Layout: View Rendering
Summary: Dropup boxes leave gray box visible after selection is made in Firefox & Mozilla Mac trunk builds → Dropup boxes leave gray box visible after selection if <select> has height/width on Mac
Note: This bug does not occur on the latest daily Firefox 0.11 Mac official builds or the latest daily Mozilla 1.7 Mac official builds. It only occurs on the official daily trunk builds. My system config is: PowerMac G4/733 (digital audio), 1 GB RAM, Mac OS X 10.3.6.
Sounds like fallout from bug 244290. Is this fixed by the patch in bug 268090? I suspect it should be....
Depends on: 268090
It appears to me that the patch from 268090 hasn't been reviewed, approved, or posted to the trunk, so I can't say yet whether it'll fix 269561, although I'll watch for it and test again once it is. As of the 11/17 Mozilla trunk build for Mac (posted late that night) and the 11/17 Firefox trunk build for Mac (posted early that morning), the bug still exists.
bz: No, the patch in bug 268090 does not fix this problem. I get this on the console: ###!!! ASSERTION: View is hidden but widget is visible!: '!visible', file /Users/pedemonte/builds/trunk/mozilla/view/src/nsViewManager.cpp, line 1710 Break: at file /Users/pedemonte/builds/trunk/mozilla/view/src/nsViewManager.cpp, line 1710
Hmm... I'm not seeing that assert (or the problem) on Linux. So maybe checking on why the widget is claiming to be visible is a good start?
Neither the fixes for 268090 or 269402 fixed the bug mentioned in 269561. The bug is still present in the 11/23/04 trunk builds.
Someone with access to a Mac build will really need to debug this... :(
I really hope that somebody can fix this bug--it's made Mozilla and Firefox largely unusable for the last month, since the bug appeared on October 30. I definitely think this should be a blocker for 1.8a6.
But you're not a driver, so shouldn't be setting "blocking+" flags. Feel free to set the "blocking?" flag, however.
Boris, I guess that indicates a shortcoming of Bugzilla that should be investigated and fixed.
(I mistakenly thought that was the process to request the blocking flag--I didn't think it would actually set the flag, since I don't have authority to do so.)
Following the proper procedure this time, I'm setting the "blocking?" flag for 1.8a6 for this bug. This bug still exists as of the 11/30 trunk builds and has occurred in all daily trunk builds since 10/30. It not only makes many "dropup" boxes impossible to use but also obscures a fair portion of the page when it occurs.
Problem still exists in Mozilla and Firefox Mac trunk builds as of 12/09/04--41 days after first appearing.
The problem is that this seems to be specific to mac widgets (doesn't appear with the other toolkits), and appears to be likely to be a mac widget bug. Which means that we need someone with access to a mac to help debug this...
FYI, this bug doesn't appear in daily builds of Camino; it displays as a regular dropdown box with no gray box visible afterwards. I'm requesting the "blocking?" flag for aviary, since this bug also affects Firefox. (I previously requested the flag only for the Mozilla suite.)
This bug also affects dropdown boxes if <select> has height/width on Mac, as new attachment shows; therefore, I have changed the Summary to reflect that. Both bugs still occur in 12/21/04 builds of Mozilla trunk for Mac and Firefox trunk for Mac.
Summary: Dropup boxes leave gray box visible after selection if <select> has height/width on Mac → Dropup/dropdown boxes leave gray box visible after selection if <select> has height/width on Mac
Due to the new breadth of the bug, I am requesting the "blocking?" flag for Mozilla 1.8a6.
*** Bug 276803 has been marked as a duplicate of this bug. ***
Simon, Pink, can one of you look into this?
FYI, bug does not appear in current daily builds of Mozilla for Mac 1.7.6. However, it does still occur in current daily trunk builds of both Mozilla for Mac 1.8a6 and Firefox for Mac 1.0+.
If this bug does not occur on the 1.7 branch, then it shouldn't be a problem in the Firefox 1.0 branch (and certainly not L10N specific) so I've unset that request. If we don't get some Mac widget help here quickly, this isn't going to be fixed for 1.8a6. Hopefully one of our Mac folks will take a look.
This patch is somewhat inelligant, but it seems to work.
That patch is wrong, sorry. Asking for widget visibility is a somewhat expensive operation that we really want to avoid if we can. What needs to happen is the place where the view and widget visibility actually get out of sync needs to be found and fixed.
Asa, point taken about the flag for blocking-aviary 1.0. I'd like to request the "blocking-aviary1.1?" flag, though, since current Firefox trunk builds are affected by this bug. OK? -- David
Comment on attachment 170711 [details] [diff] [review] Possible patch hrm, is this really the right thing to be doing? roc, what do you think?
Once the gray box appears, if you open a new tab in Mozilla or a new window in Mozilla, that same box covers them, too.
Once the gray box appears in Mozilla, it will also float over other applications' windows.
Attachment #170947 - Attachment description: Gray Box also blocking other Moz windows/tabs once triggered → Gray Box also floats over other Moz windows/tabs once triggered
Changing bug severity to "Major" in order to match classification assigned to the Firefox version of the bug (#277671).
Severity: normal → major
*** Bug 277671 has been marked as a duplicate of this bug. ***
too late for 1.8a6. blocking-
Flags: blocking1.8a6? → blocking1.8a6-
Requesting Mozilla "blocking 1.8b?" flag.
*** Bug 278141 has been marked as a duplicate of this bug. ***
Could someone test whether this helps? I sorta doubt it would, but worth checking...
It hasn't helped, I get the same result either with or without this patch.
Comment on attachment 170711 [details] [diff] [review] Possible patch prolly not what we want to do.
Attachment #170711 - Flags: review?(pinkerton) → review-
*** Bug 278050 has been marked as a duplicate of this bug. ***
*** Bug 278431 has been marked as a duplicate of this bug. ***
What's happening is that the dropdown window is hidden, then immediately made visible again because of some code in nsMacWindow (line 1462).
So should that set mVisible to whatever mVisible was before Show(PR_FALSE) was called, instead of setting it to true?
What Boris said.
Comment on attachment 171565 [details] [diff] [review] Don't set mVisible to true willy-nilly r=pink
Attachment #171565 - Flags: review+
Attachment #171565 - Flags: superreview?(bzbarsky)
Comment on attachment 171565 [details] [diff] [review] Don't set mVisible to true willy-nilly sr=bzbarsky
Attachment #171565 - Flags: superreview?(bzbarsky) → superreview+
Even though it's already been approved and for what it's worth the latest patch worked for me.
Status: NEW → RESOLVED
Closed: 18 years ago
Resolution: --- → FIXED
Target Milestone: --- → mozilla1.8beta
*** Bug 280473 has been marked as a duplicate of this bug. ***
*** Bug 282063 has been marked as a duplicate of this bug. ***
Component: Layout: View Rendering → Layout: Web Painting
You need to log in before you can comment on or make changes to this bug.