199913 - text not properly repainted after reflow / characters cut off at left

Status: RESOLVED WORKSFORME

(Core :: Web Painting, defect)

Description

[Andrew Schultz]

After loading the valgrind home page, the far left side of a few of the lines
are not repainted.  The text seems to jiggle a bit during reflow and/or addition
of the vertical scrollbar (after which the text is partially missing).  If the
window is too small, the bug doesn't occur.  I need at least 1000x900 to get the
bug to show up.

Moving a window over the glitches fixes them as does scrolling them off the
screen and then back on.

I see this with current default (.tar.gz binary) builds, but not CVS (debug or
optimized/gtk2/xft).  It started happening sometime between linux trunk
2003032405 and 200302505 (regression from bug 191474) and continues to happen
with 2003033008 (not fixed by bug 199159).

I'll attach a screenshot

Comment 1

[Andrew Schultz]

Attachment: screenshot

http://developer.kde.org/~sewardj/ as seen with linux trunk 2003033008

Comment 2

[Andrew Schultz]

Actually, if I download something in the background, I can reproduce the bug
with my debug build.

Comment 3

[Marek Stępień [:marcoos, inactive]]

It often happens to me on many other websites (using 2003032705 on GNU/Linux).
This probably has something in common (maybe it's a duplicate) of bug 199457.

Comment 4

[Jason Bassford]

This is not happening to me under XP (2003032808).

Comment 5

[Eugene Savitsky]

I believe I saw it under XP on bugzilla, but I'm not sure...

Comment 6

[Paul Bergsagel]

I am experiencing this bug on MacOS X 10.1.5 using Mozilla Build ID 2003032808.
I don't believe this build was the first build where this bug was seen.

Comment 7

[Stefan Borggraefe]

I saw this since shortly after 1.3 branched. I´m using Windows XP SP1.

For me it happens constantly for every Bug-page: The B in the text "Bugzilla
Version 2.17.1" at the top of the page is cut of on the left side after reflow.
I´ll attach a screenshot in a minute...

I also see this bug with other pages quite often.

Comment 8

[Stefan Borggraefe]

Attachment: Screenshot of a Bugzilla Bug-page showing this bug

Comment 9

[Jason Bassford]

Thanks to the screenshot, I can state that I *have* been experiencing this -
even though, as per comment 4, I still do not see it with the reference URL. 
It's pretty annoying... 

Comment 10

[djk]

I can repro the problem with the 'B' in the Bugzilla link at the top of this
page also, and I'm running Mozilla/5.0 (Windows; U; Win98; en-US; rv:1.3b)
Gecko/20030312 Phoenix/0.5

So the bug definitely regressed before 2003032405, as the initial report suggests.

Comment 11

[Andrei Leo]

see bug 196054 (opened 2003-03-05)

Thep roblem is the same. 
So, regression started even earlier. 
I tried 2003-03-03 and it also has this bug.

Comment 12

[Andrew Schultz]

> So the bug definitely regressed before 2003032405, as the initial report 
> suggests.

this bug regressed between 2003032405 and 2003032505.  if you see something that
started happening before that, it's not this bug.

Comment 13

[Andrei Leo]

Attachment: Picture taken with Mz 20030303

Are you sure? 
Ok, I'm quite lazy guy but here you are...

Comment 14

[Andrew Schultz]

all I can say is that my 20030303 (and 20030324) build does not exhibit this bug.  

Andrei: are you using linux or windows?

Comment 15

[Andrei Leo]

Andrew,
I'm using Windows 2000.

Comment 16

[Andrew Schultz]

ok, it seems is a windows-only bug existed before 3-24.  bug 191474 exposed the
bug on linux or created a new bug with similar symptoms.

Comment 17

[Jason Bassford]

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

Comment 18

[Jason Bassford]

Tweaking summary for Bugzilla searches.

Comment 19

[Sander]

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

Comment 20

[Michiel van Leeuwen (email: mvl+moz@)]

http://yellow.exedo.nl/~michiel/reflow.php show this reproducable for me. It
just add a 2 second sleep between loading the first line, and loading a tall
div, to make the scrollbar appear. reflow.txt has the php code.
It only shows if the first line is centered.

Comment 21

[Ere Maijala (slow)]

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

Comment 22

[Thamer Mahmoud]

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

Comment 23

[Andrew Schultz]

this got fixed sometime between linux trunk 2003040505 and 2003040605 for me,
probably bug 197065.

marking WORKSFORME

if B-ugzilla problems are still happening under windows, please reopen one of
the dupes here.

Comment 24

[Andrei Leo]

Pages from bugs 200809, 199538, 199687 still broken with 20030408.
I don't understand why to mark bug OS=All (also duplicating many Win bugs
against it) and later mark it as WORKSFORME after testing only on Linux ? No logic.

Comment 25

[piers]

This is not resolved. 2003040708 Win2K. Reopening. 

OS -> Windows (doesn't appear to happen on Linux - any Mac people see this?)
URL -> http://yellow.exedo.nl/~michiel/reflow.php (more reliable testcase)

Comment 26

[Jason Bassford]

Additionally, if it does get resolved by some unknown fix, it should,
nonetheless, be be resolved as FIXED (not WORKSFORME).  (The latter is only for
cases when there's nothing intrinsically wrong with Mozilla code.)

> OS -> Windows (doesn't appear to happen on Linux - any Mac people see this?

See comment 3 and comment 5.  Please read the entire bug before making changes
such as this.  Changing back.

Comment 27

[Jason Bassford]

I mean comment 6 for MacOS.

Comment 28

[Andrew Schultz]

> I don't understand why to mark bug OS=All (also duplicating many Win bugs
> against it) and later mark it as WORKSFORME after testing only on Linux ? No 
> logic.

because they weren't dupes.  that's why I said to reopen one of them.

> OS -> Windows (doesn't appear to happen on Linux - any Mac people see this?)
> URL -> http://yellow.exedo.nl/~michiel/reflow.php (more reliable testcase)

this bug is not morphing to the bug you think it is simply because the actual
bug got fixed.

> Additionally, if it does get resolved by some unknown fix, it should,
> nonetheless, be be resolved as FIXED (not WORKSFORME).  (The latter is only 
> for cases when there's nothing intrinsically wrong with Mozilla code.)

nope. WORKSFORME is for bugs that can not be reproduced.  Cases when there's
nothing intrinsically wrong with Mozilla code are INVALID.

since I filed this bug, it is defined more by what I see than what you think is
related to what I see.

marking WFM

Comment 29

[Andrew Schultz]

I reopened bug 195598

Comment 30

[piers]

Andrew, if I follow your steps to reproduce in comment 0 (i.e. just open the URL)
the problem still occurs, so this does not work for me. What makes this 
bug resolved? Was this bug just about non-Windows platforms? Or are there some 
different steps that can differentiate this bug from bug 195598? Thanks.

Comment 31

[Andrew Schultz]

> What makes this bug resolved? Was this bug just about non-Windows platforms?

this bug was defined as a repainting problem that started between 3/24 and 3/25.  

similar behavior was seen on windows starting as far back as 3/3, indicating
that something was wrong (A) with Mozilla before 3/24.  Sometime between 3/24
and 3/25, some code was changed (B) in Mozilla that resulted in this bug
appearing on Linux.  this bug was to track getting problem B fixed.  On linux
the problem stopped happening, indicating that whatever caused B was fixed or
worked around.  Whatever fixed B did not help with A.  So the only way to
distinguish between problems A and B is not through the symptoms (which are very
similar) but by the code changes that caused them or fixed them.

It is difficult to say whether this bug ever existing under Windows because of
the previously existing bug (since the symptoms were the same).

Comment 32

[piers]

Ok, cool, that is clearer. And 195598 == A :)