419164 - Text and images on rhein-zeitung.de change when scrolling, marking, and moving the mouse

Status: RESOLVED WORKSFORME

(Core :: General, defect)

Description

[Peter Weilbacher]

Attachment: after loading the page

Current SeaMonkey and Firefox trunk on OS/2 (2008022216)

Different from bug 418882 the pages on http://rhein-zeitung.de/ don't crash the browser on OS/2, but I see weird stuff happening. When loading the page only part of the content is displayed, most of the text and images are missing. When using the mouse to mark text, some of it appears but may immediately disappear again after moving the mouse further. After scrolling down and up, some of the images on the right-hand side also appeared. Will attach screenshots in a minute.

In a build of 20071202 I don't see any problems...

Comment 1

[Peter Weilbacher]

Attachment: after scrolling down and up again and marking some text

Comment 2

[Peter Weilbacher]

This does not happen on Linux, so I used the available OS/2 nightlies to restrict the regression range:

2008011614  SM good
2008012215  SM good
2008012820  FX bad

So this leaves 6 days. Lots of stuff happened, I suspect some changes in gfx/ maybe the cairo update (which happened at 2008-01-25 16:25).

Comment 3

[Walter Meinl]

(In reply to comment #2)
> I suspect some changes in gfx/
> maybe the cairo update (which happened at 2008-01-25 16:25).
> 
Yep, this seems to be the culprit. It was a little bit hard to find it out, as the today's frontpage works also in current builds, but when you go to a link deeper in the newspaper, most are hosed. Pictures only come up, when you hover the mouse over it. It seems that text is likely not displayed after a hyphen. All is ok immediately checked out before the cairo update you mentioned.

Comment 4

[Peter Weilbacher]

Wow, I'm always amazed how fast you can check these things. :-) Thanks!

Now I wonder how we can find out which change exactly caused it. The changes to cairo-os2-surface.c
   http://bonsai.mozilla.org/cvsview2.cgi?diff_mode=context&whitespace_mode=show&subdir=mozilla/gfx/cairo/cairo/src&command=DIFF_FRAMESET&file=cairo-os2-surface.c&rev1=1.15&rev2=1.16
and cairo-ft-font.c
   http://bonsai.mozilla.org/cvsview2.cgi?diff_mode=context&whitespace_mode=show&subdir=mozilla/gfx/cairo/cairo/src&command=DIFF_FRAMESET&file=cairo-ft-font.c&rev1=1.33&rev2=1.34
don't seem like they could have caused any problems (in fact, the latter would have fixed a problem with the font pixel sizes), and the other stuff is unlikely to be OS/2 specific. Still, will try to back out only those changes.

Comment 5

[Peter Weilbacher]

I have tried to change back only some of the cairo files to their older versions but that is hard because too many things changed and one then has to hand-edit a lot. Changing cairo-ft-font.c and cairo-os2-surface.c to older versions doesn't help. Using only the old libpixman doesn't help, either. But using the new libpixman again with the old cairo helps. So it's cairo itself.

Comment 6

[Peter Weilbacher]

Attachment: call stack

Interesting, in a FF debug build with cairo from the current trunk I see lots of failed assertions on the sub-pages of rhein-zeitung.de when scrolling, marking. They all look like this:

Assertion failed at X:/trunk/mozilla/gfx/cairo/cairo/src/cairo-image-surface.c:5
71: CAIRO_FORMAT_VALID (image_surface->format)

And really, the format is -858993460 while it should really between 0 and 3 (see cairo_format_t definition in cairo.h). The call stack to cairo_image_surface_get_format() is always like the one I attach here. Using that I also found out that mSize that gets set in gfxImageSurface::gfxImageSurface is always (4096, -1) in the case of the above assert.

Comment 7

[Peter Weilbacher]

I should also note that I tried to use git bisect to determine exactly which of the changes in cairo triggered this problem. So far I did this:

   git bisect start
   git bisect good 141-g57c2b75
   git bisect bad 75-gc621d8d

on the cairo repository on a Linux machine. But when I tried to copy the resulting checkout of the cairo sources into my Mozilla tree I couldn't compile it any more. I guess one would have to try this with a dated checkout of the Mozilla tree close to the regression date. I will come back to that if my debugging doesn't give any results.

Comment 8

[Peter Weilbacher]

OK, further followed the git bisect thing. The last good revision in cairo's git repository is
   http://gitweb.freedesktop.org/?p=cairo;a=commit;h=6d0dc3e0760e6bc6b0eceab48674410b4e865287
The next two commits
   http://gitweb.freedesktop.org/?p=cairo;a=commitdiff;h=45f269e33020d8d7cf247926712b9c64c1fb8959
and
   http://gitweb.freedesktop.org/?p=cairo;a=commitdiff;h=efd3a965244305a069ec231b7ec28cff8d6c67c8
make Firefox crash on startup. The next one
   http://gitweb.freedesktop.org/?p=cairo;a=commitdiff;h=5dfe47a3f14ee8597395dc53ff57fd429e9804cd
lets Firefox run again but causes this problem.

Switching only the changes between the first and the last of the above doesn't cause the problem, so I suspect that the wider commit of efd3a965244305a069ec231b7ec28cff8d6c67c8 really is the problem. I don't think I will have time to test that tonight, though.

Comment 9

[Peter Weilbacher]

I wanted to visit this again today but visited many pages on the site of that newspaper and couldn't reproduce any more. Even the Dalai Lama story (http://rhein-zeitung.de/on/08/03/15/tt/t/rzo409871.html) for which I could previously reproduce it 100% shows correctly, even after lots of scrolling and marking.

It is working in the nightly of 2008-04-02 00:08 but was still broken in the one of 2008-03-25 15:00. I wonder what fixed it, I don't see any changes to gfx/cairo in CVS in that timeframe.

Comment 10

[Walter Meinl]

Though its not a cairo fix, could it be fixed by the checkin for bug421885? This seems to me a good candidate in the time frame mentioned. Btw, it was still broken with Mozilla/5.0 (OS/2; U; Warp 4.5; en-US; rv:1.9pre) Gecko/2008032721 Minefield/3.0pre (no closer build date to April 2nd here availble, but I can confirm it was fixed after 04-02).

Comment 11

[Peter Weilbacher]

Whatever the reason was (I'm too lazy to back out that checkin) it hasn't returned so I'll mark this WFM.