Frame not painted properly when event dialog is up

VERIFIED WORKSFORME

Status

()

Core
Layout: View Rendering
P3
normal
VERIFIED WORKSFORME
18 years ago
17 years ago

People

(Reporter: Heikki Toivonen (remove -bugzilla when emailing directly), Assigned: Kevin McCluskey (gone))

Tracking

Trunk
x86
Windows NT
Points:
---

Firefox Tracking Flags

(Not tracked)

Details

(URL)

Using the URL (testcase from bug 53763) I can see that while the event dialog is
visible the right frame did not do a complete repaint of the frame; the select
element is still visible in the frame even though the content above it changed.
I know it is paint problem because I can move a window partly over the erroneous
area and it gets repainted correctly (plain background).

To reproduce:

1. Open URL.
2. Click on an entry in the select box in the right frame.
3. Click the link in the left frame.

Expected results:

You get an alert box, and the content in the right frame changes.

Actual results:

You get the alert box, but the select element's area has not been painted in the
right frame, even though the frame was replaced and the area above it has been
painted properly.

I see this on NT but not on Linux.
(Assignee)

Updated

18 years ago
Status: NEW → ASSIGNED
(Assignee)

Comment 1

18 years ago
The URL in the left frame of the testcase is no longer valid
(Assignee)

Comment 2

17 years ago
Seems to work fine with todays build on WINNT buldid 2001030903. Marking WORKSFORME.
Status: ASSIGNED → RESOLVED
Last Resolved: 17 years ago
Resolution: --- → WORKSFORME
Bizarre... If I try the testcase in URL the testcase itself does not work: when
I click the i.html link the page is opened in a new window instead of the right
frame. But when I save the files locally it is working as expected, so the
worksforme seems like a right solution. Marking verified. I'll search for the
target bug and open a new if I don't find it.
Status: RESOLVED → VERIFIED
You need to log in before you can comment on or make changes to this bug.