Frame resizing causes repaint problems

VERIFIED FIXED in M15

Status

()

P3
normal
VERIFIED FIXED
20 years ago
3 months ago

People

(Reporter: mats, Assigned: pollmann)

Tracking

({testcase})

Trunk
testcase
Points:
---

Firefox Tracking Flags

(Not tracked)

Details

(Whiteboard: Fix in hand, URL)

Attachments

(5 attachments)

(Reporter)

Description

20 years ago
To repeat:
1. load http://www.aricia.fr/
2. grab and drag any of the frame dividers and resize frame.

What happens:
Window is not repainted properly (I have a screenshot if you want)

Version and OS:
build 1999-08-02-13-M9 on Windows 98.

Updated

20 years ago
Assignee: karnaze → pollmann

Comment 1

20 years ago
Reassigning to Eric.
(Assignee)

Comment 2

19 years ago
Created attachment 1804 [details]
Test case
(Assignee)

Updated

19 years ago
Status: NEW → ASSIGNED
(Assignee)

Updated

19 years ago
Target Milestone: M15
(Assignee)

Comment 3

19 years ago
I can find no resizable frames on this site.

To test the bug, I created an attachment.  Resizing this on Windows NT causes no
visible artifacts.

1) What exact URL are you experiencing this on?
2) Please attach the screenshot.

Thanks!
(Reporter)

Comment 4

19 years ago
The original site (http://www.aricia.fr/) has been completly redesigned since I
reported this bug, but I have found a new page that has the same problems.
I don't see any problems in the attached testcase either, it seems to only
appear when there are both frames divided horizontally and vertically.
Changing URL. Bug still occurs in apprunner 1999-09-25-09-M11 on Windows NT4sp5.
Attaching a snapshot of the new URL. (I'll see if I can dig up the old one too).
(Reporter)

Comment 5

19 years ago
Created attachment 1882 [details]
snapshot of repaint problem at java.sun.com
(Assignee)

Updated

19 years ago
Target Milestone: M14
(Assignee)

Comment 6

19 years ago
Ah, I see it now!  What I'm seeing is: When I slide the vertical divider left,
the two left frames shrink twice the needed amount. When I slide the vertical
divider right, the two left frames grow twice the needed amount, and paint on
top of the divider and right frame.

This looks like a math error somewhere, shouldn't be too bad to track it down
(famous last words.)  I'm attaching a test case.
(Assignee)

Comment 7

19 years ago
Created attachment 1884 [details]
simple page
(Assignee)

Comment 8

19 years ago
Created attachment 1885 [details]
reduced test case
(Assignee)

Comment 9

19 years ago
Created attachment 1886 [details]
reduced test case

Updated

19 years ago
QA Contact: beppe → petersen

Comment 10

19 years ago
assigning to Petersen
Whiteboard: [TESTCASE]
Target Milestone: M14 → M16
Moving to M16.
Bulk moving [testcase] code to new testcase keyword. Sorry for the spam!
Keywords: testcase

Comment 13

19 years ago



I've found another situation where resizing causes paint problems that I don't
think has been addressed here.

using Win32 build: 2000031008

Steps to reproduce:
1. go to http://www.syntegra.com

2. drag the right bottom corner of the browser to the left so that the
horizontal space shrinks.  Do this until you see a scrollbar.

3. grab the scrollbar and scroll it to the right (any distance, but try moving
it all the way to the right the first time).

4. Now go back to the bottom right corner and drag the window so that the
horizontal space gets bigger.

5. You should now see a white area at the right side of the window. The width of
the white space seems to correspond to how far the scrollbar was scrolled to the
right.  The window just isn't being repainted until you either refresh or you
repeat step 2

Jake

(Assignee)

Comment 14

19 years ago
hoju@visi.com that was a great catch, thanks.  In fact, this happens on any page
even if there are no framesets.  I've filed a new bug for you:

http://bugzilla.mozilla.org/show_bug.cgi?id=32679

This bug will remain about the problem described earlier, thanks!
(Assignee)

Comment 15

19 years ago
I think I have a fix for this.  Still testing.  It turns out that if one of the 
frameset children that is being resized is actually a frameset, it is resized in 
two places in the code (once in ::MouseDrag and once in ::ReflowPlaceChild).  I 
removed the extra one (ReflowPlaceChild) and the bug was fixed.  Need to do some 
testing, but it looks very promising.
OS: Windows 98 → All
Hardware: PC → All
Whiteboard: [TESTCASE] → Fix in hand
Target Milestone: M16 → M15
(Assignee)

Comment 16

19 years ago
Fix checked in.  To verify, go to Viewer debug test case 9:

resource:/res/samples/test9.html

Grab the divider bar between the top and two bottom frames.
Drag it upwards or downwards.  Though the resizing will be slow (this is due to 
reflow being slow for such large documents), resizing should work now.

There is also a reduced test case on this bug.  Draging the vertical resize bar 
should work on that now too.  Thanks!
Status: ASSIGNED → RESOLVED
Last Resolved: 19 years ago
Resolution: --- → FIXED
(Assignee)

Comment 17

19 years ago
*** Bug 32427 has been marked as a duplicate of this bug. ***
(Assignee)

Comment 18

19 years ago
*** Bug 29781 has been marked as a duplicate of this bug. ***

Comment 19

19 years ago
Fixed in the April 26th build.
Status: RESOLVED → VERIFIED

Updated

3 months ago
Product: Core → Core Graveyard
Component: Layout: HTML Frames → Layout: Images
Product: Core Graveyard → Core
You need to log in before you can comment on or make changes to this bug.