65730 - incomplete screen redraw when a div.style.visibility changes

Status: VERIFIED FIXED

(Core Graveyard :: GFX, defect)

Description

[Sorin Cristescu]

the webpage consist of a frameset (2 rows, bottom row split in 2 columns). When
the code finished loading in the main "text" frame, the javascript-based
navigation facilities in the other 2 frames get enabled. In the "top" navigation
frame (topmenu), clicking afterwards on an image switches "on" a series of
dropdown menus represented as hidden divs contained in the main "text" frame.
After the "on" switch, hovering the mouse above an image in the "top" frame does
a in-situ image swap but also changes the
document.getElementById("divN").style.visibility attribute of the corresponding
parent.text.document.getElementById("divN") element in the main frame, called
"text".
This works more or less as expected, save major screen redraw bugs : the now
visible layer gets only partially drawn (yet the inside links, even when
invisible to the eye, are accessible). When "mousing out" this div should become
hidden, which the code actually tries to do, but only partly succeds : only
patches of the "hidden" div actually disappear, the rest is still on screen,
though now the still visible links are no longer accessible (since they should
be invisible ...)
This bug is also seen with the latest Mozilla build for Win32, 0.7
I mention that the javascript code correctly sniffs the browser and uses (or at
least try very hard to) W3C standard DOM attributes and methods.

Comment 1

[Boris Zbarsky [:bzbarsky]]

Could you please attach a testcase or set the URL field to the URL for this
page?  debugging based on the description you have given is well-nigh impossible...

Also, this should be reassigned to a different component, but that should be
done after we have a testcase to base the assignement on.

Thanks for using Mozilla and reporting bugs!

Comment 2

[Boris Zbarsky [:bzbarsky]]

Email from reporter:

Actually this bug seems very easy to reproduce : juste create two
absolutely positioned divs, one visible the other hidden, that do not
overlap (at least not completely) and then use a mouse over handler that
calls javascript to toggle the visibility of the two divs. What I get is :
_most of the time_ the div that was hidden becomes visible ok (but not
always), whereas the div that was visible NEVER becomes fully hidden (at
least not on the screen) : trash pixels remain on the screen.

You can see this at the following address :
http://www.mnhn.fr/mnhn/phg/index.htm
then go to "Publications" (button in the left navigation frame) and pass
the mouse over "Team 1", "Team 2", "Team 3", "Team 4". However you cannot
see the javascript since it's in a .js file. But it doesn't actually
matter cause the bug is not related to the javascript code.

As you pass the mouse over those fake links, some div becomes visible
while the one that was on the screen becomes hidden ... well, only
partially : if you look in the right part of the screen, when the previous
div had a bigger width than the one called in sight, you can still see a
trash line leftover from the table border of the previous div. If you
minimize the app and then maximize it again, the trash disappears (cause
the screen gets redrawn).

This bug happens with NS 6 as well as Mozilla 0.7 under Win2k. I checked
using another page with similar code under Win98 SE and I saw it too
(however this other page isn't on-line yet), so I suppose it's not
restricted to Win2k, it's more like a Win32 bug

Comment 3

[Boris Zbarsky [:bzbarsky]]

OK, I just tried this with linux build 2001-01-16-08 and I see the problem
described by the reporter.  The JS in question seems to be OK.

I'll try to come up with a reduced testcase.  In the meantime, setting OS to
all, status to NEW, reassigning to compositor, since the div is hidden but not
drawn completely right.

Comment 4

[Kevin McCluskey (gone)]

Setting target to mozilla0.9.1

Comment 5

[Kevin McCluskey (gone)]

This may be fixed by the new viewmanager.

Comment 6

[Boris Zbarsky [:bzbarsky]]

Seems to be working for me with the new viemanager and 2001-02-26-08 on linux.

Reporter, could you try setting

user_pref("nglayout.debug.enable_scary_view_manager", true);

in your prefs.js and seeing whether that fixes the problem?

Comment 7

[Kevin McCluskey (gone)]

It is fixed in 200103204 build on WINNT.
Marking fixed.

Comment 8

[Chris Petersen]

Marking verified in the May 22nd build.