130 bytes, text/html
27.10 KB, image/gif
54 bytes, text/html
174 bytes, text/html
333 bytes, text/html
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.
Reassigning to Eric.
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!
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).
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.
assigning to Petersen
Target Milestone: M14 → M16
Moving to M16.
Bulk moving [testcase] code to new testcase keyword. Sorry for the spam!
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
email@example.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!
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
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: 18 years ago
Resolution: --- → FIXED
*** Bug 32427 has been marked as a duplicate of this bug. ***
*** Bug 29781 has been marked as a duplicate of this bug. ***
Fixed in the April 26th build.
Status: RESOLVED → VERIFIED
You need to log in before you can comment on or make changes to this bug.