Closed Bug 65730 Opened 24 years ago Closed 24 years ago

incomplete screen redraw when a div.style.visibility changes

Categories

(Core Graveyard :: GFX, defect)

x86
All
defect
Not set
normal

Tracking

(Not tracked)

VERIFIED FIXED
mozilla0.9

People

(Reporter: sorin, Assigned: kmcclusk)

References

()

Details

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.
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!
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
Assignee: locka → kmcclusk
Status: UNCONFIRMED → NEW
Component: ActiveX Wrapper → Compositor
Ever confirmed: true
OS: Windows 2000 → All
QA Contact: cpratt → petersen
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.
Status: NEW → ASSIGNED
Setting target to mozilla0.9.1
Target Milestone: --- → mozilla0.9.1
This may be fixed by the new viewmanager.
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?
It is fixed in 200103204 build on WINNT. Marking fixed.
Status: ASSIGNED → RESOLVED
Closed: 24 years ago
Resolution: --- → FIXED
Target Milestone: mozilla0.9.1 → mozilla0.9
Marking verified in the May 22nd build.
Status: RESOLVED → VERIFIED
Product: Core → Core Graveyard
You need to log in before you can comment on or make changes to this bug.