139589 - Problem with shown/hidden elements not rendering fully/not hiding fully.

Status: RESOLVED WORKSFORME

(Core Graveyard :: GFX, defect)

Description

[Garrett Smith]

From Bugzilla Helper:
User-Agent: Mozilla/5.0 (Macintosh; U; PPC Mac OS X; en-US; rv:1.0rc1)
Gecko/20020417
BuildID:    2002041712

When a Menu is shown for the first time, it is positioned and then the
visibility is set to hidden. But when it is shown again, if it does not need
repositioning, the element will be shown it the place where it is positioned.

The problem is with Mozilla not fully rendering the element when it is shown the
second time. 


Also, when hiding a Menu, the menu will sometimes leave a ghost of itsself in
the form of pixel "junk":
http://dhtmlkitchen.com/dhtml/ui/oomenubar/examples/mouseover/index.html


Reproducible: Always
Steps to Reproduce:
1.http://dhtmlkitchen.com/dhtml/ui/oomenubar/examples/topnav/index.html
2. get a submenu
3. close the menu (by getting another submenu or mousing over another item)
4. show the same submenu.

Actual Results:  The second time the menu is shown, it will be only partially
visible. 

Expected Results:  Menu should be 100% visible.

Comment 1

[Boris Zbarsky [:bzbarsky]]

worksforme, linux trunk build 2002-04-22-07.  Is this Mac-only?

Comment 2

[Greg K.]

Confirmed using FizzillaCFM/2002041712 (RC1).

Probably DOM 0, so reassigning. Needs a minimized testcase.

Comment 3

[Boris Zbarsky [:bzbarsky]]

No, if it appears then the DOM is doing the right thing.... If it's not painted
fully, it's a painted problem.

Comment 4

[Garrett Smith]

I noticed that the window is repainted when it is resized or scrolled. Try 
resizing the window. Try making the window very short (100px) and 
reload.

My result: No effect -- the anomalous scrollbar is visible if you scroll or 
resize the window.

The only thing that makes it go away is by setting it's container to hidden 
via javascript. This is done by clicking the tab it's in and then clicking 
another tab.

Hope this helps.

Comment 5

[Garrett Smith]

Attachment: A textarea inside a div that is hidden with css

Comment 6

[Boris Zbarsky [:bzbarsky]]

Rod, didn't you fix this a few weeks back?  Was that Linux-only?

Comment 7

[Boris Zbarsky [:bzbarsky]]

Comment on attachment 81505 [details]
A textarea inside a div that is hidden with css

reporter attached this to the wrong bug...

Comment 8

[Kevin McCluskey (gone)]

WFM: Using 2002050108 build on WinXP and going to
http://dhtmlkitchen.com/dhtml/ui/oomenubar/examples/topnav/index.html

Mac port issue?
Reassigning to Don.

Comment 9

[Greg K.]

Debugging this is going to be a nightmare. I've constructed a "testcase" (I'm
hesitant to even use the term) HTML file that includes all relevant CSS and JS
inline, and it's still ginormous, and horridly formatted to boot. (Whoever made
it is one of those people who believes in removing all possible whitespace. Let
them debug this.)

Comment 10

[Greg K.]

Attachment: The source with all extras removed and all necessary CSS and JS inline

Comment 11

[Martin von Oertzen]

maybe this is a smaller example of the same problem?
http://forums.mozillazine.org/viewtopic.php?t=76839
http://www.maletin.de/display.html

Comment 12

[Boris Zbarsky [:bzbarsky]]

It's not.

Comment 13

[Andrew Schultz]

is this still a problem on mac?

Comment 14

[Stefan [:stefanh]]

(In reply to comment #13)
> is this still a problem on mac?

Menus are rendered ok in the testcase (comment #10) with a 11 days old SeaMonkey
trunk build (Mac OS 10.3.9). The URL is gone.

Comment 15

[Andrew Schultz]

resolving WORKSFORME