22684 - Content in text box changes as the browser window is resized

Status: RESOLVED WORKSFORME

(Core :: Web Painting, defect)

Description

[Nisheeth Ranjan]

1) Goto http://www.mozilla.org/newlayout/xml/books/books.xml
2) Click the "Toggle Style" button
3) Resize the window.

As you resize, content in the upper left table cell's text box gets swapped with
the content of the bottom right table cell's text box and then reverts to its
original content.  This keeps happening as you continue to resize the window.
When you stop resizing you end up with the original content.

This bug is part of the effort to break out the different problems reported in
bug 19612 into different bugs.

Comment 1

[Sean Richardson]

A detail: the bottom-right cell that matters is the bottom-rightmost
that is visible at the time, not the very bottom-rightmost. This can change
while resizing.

Also, the scrollbars on the upper-left textbox go wild while resizing,
but not the scrollbars on the bottom-right textbox.

Comment 2

[Sean Richardson]

*** Bug 22690 has been marked as a duplicate of this bug. ***

Comment 3

[troy]

The XML demo has been busted for quite a while, and it's not clear when/why it
no longer works well

Nisheeth, you're Mr. XML so re-assigning to you. If you can narrow it down or
come up with simpler test cases I will take another look

Comment 4

[Nisheeth Ranjan]

Attachment: books.xml

Comment 5

[Nisheeth Ranjan]

Attachment: common.css

Comment 6

[Nisheeth Ranjan]

- Save the attached books.xml and common.css to the same directory on your local
disk.
- Load books.xml.
- Resize the window.

The content of the first book gets swapped with the content of the second book
and then reverts to the original content.  This behavior repeats as you resize.

Troy, now that this bug has a simplified test case, assigning this back to you.
Thanks for your help with this!

Comment 7

[troy]

*** Bug 22765 has been marked as a duplicate of this bug. ***

Comment 8

[troy]

Problem is in block code and how it doesn't properly position floaters before
reflowing them, and so it places them in the wrong spit and then ends up moving
them

Comment 9

[Nisheeth Ranjan]

*** Bug 24801 has been marked as a duplicate of this bug. ***

Comment 10

[troy]

This is fixed. Eric Vaughan made a change to the compositor so it defers moving 
widgets until we're all done positioning views

Comment 11

[Chris Petersen]

Fixed in the July 14th build.

Comment 12

[Sean Richardson]

Seeing this again using 2000-07-31-08-M18 (and -07-30-21-M18) on WinNT.

The Bill Gates <TEXTAREA> stutters with the contents of the 
84 Charing Cross Road <TEXTAREA> when the window is resized, and also
as the layout finishes up after pressing the [Toggle Style]. 

Bug 29195, "Text jumping around", looks related. It was previously marked a
DUP of bug 22685, but looks much more similar to this bug.

Comment 13

[Hixie (not reading bugmail)]

Troy no longer with us, reassigning to Buster. This won't get fixed for RTM
unless someone nominates it and says why it is more important than us leaking
more than the Military...

Comment 14

[Biswapesh Chatterjee]

*** Bug 29195 has been marked as a duplicate of this bug. ***

Comment 15

[buster]

minor display glitch.  not easy to fix.  future

Comment 16

[Kevin McCluskey (gone)]

Build reassigning Buster's bugs to Marc.

Comment 17

[Niels Aufbau]

Since there haven't been any comments for a year, I'll just say that this bug
still exists.  By the way, the rectangle containing the synopsis of each book
isn't a textarea, but rather a block element with fixed size and overflow:scroll.

Comment 18

[Boris Zbarsky [:bzbarsky]]

Over to the right component....  This happens on Linux too.

Comment 19

[Robert O'Callahan (:roc) (email my personal email if necessary)]

This is probably something to do with native widget repositioning during reflow.
The content change only happens transiently during reflow; the "steady state" is
that the rendering is correct.

Probable fixes are to a) buffer native widget state changes (see bug 23742) or
b) make scroll areas not use a native wiget. The latter fix would be best but
I'm not sure we can do it on X11.

Comment 20

[Martijn Wargers (dead)]

Isn't this fixed now in current trunk builds (more than 2 years later)?
I'm not seeing anything unusual with the url testcase.

Comment 21

[Gérard Talbot]

As far as I understand the testcase at http://www.mozilla.org/newlayout/xml/books/books.xml and the bug description, I get expected results with Firefox 2.0 RC2 rv:.1.8.1 build 20061003 under XP Pro SP2.

Comment 22

[Martijn Wargers (dead)]

Marking WORKSFORME, if someone can still reproduce this bug, please reopen.