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

Categories

(Core :: Web Painting, defect)

PowerPC
macOS
defect
Not set
major

Tracking

()

RESOLVED FIXED
mozilla1.8beta1

People

(Reporter: david, Assigned: sfraser_bugs)

References

()

Details

(Keywords: regression)

Attachments

(7 files, 2 obsolete files)

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
Keywords: regression
Attached file testcase
<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
Assignee: nobody → roc
QA Contact: ian
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.
Depends on: 269402
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.
Flags: blocking1.8a6+
But you're not a driver, so shouldn't be setting "blocking+" flags. Feel free to
set the "blocking?" flag, however.
Flags: blocking1.8a6+
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.)
Flags: blocking-aviary1.0-L10N?
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.
Flags: blocking1.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.
Flags: blocking-aviary1.0-L10N?
Attached patch Possible patch (obsolete) — Splinter Review
This patch is somewhat inelligant, but it seems to work.
Attachment #170711 - Flags: superreview?
Attachment #170711 - Flags: review?(pinkerton)
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
Flags: blocking-aviary1.1?
Comment on attachment 170711 [details] [diff] [review]
Possible patch

hrm, is this really the right thing to be doing? roc, what do you think?
Attachment #170711 - Flags: superreview?
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.
Flags: blocking1.8b?
*** Bug 278141 has been marked as a duplicate of this bug. ***
Attached patch Something to test (obsolete) — Splinter Review
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. ***
Assignee: roc → sfraser_bugs
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.
Attachment #170711 - Attachment is obsolete: true
Attachment #171105 - Attachment is obsolete: true
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.
Checked in.
Status: NEW → RESOLVED
Closed: 18 years ago
Resolution: --- → FIXED
Flags: blocking1.8b?
Flags: blocking-aviary1.1?
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.