536065 - textarea on MozillaZine Forums has scrolling corruption

Status: RESOLVED FIXED

(Core :: Layout: Form Controls, defect)

Description

[Matthew Turnbull [Bluefang]]

User-Agent:       Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv:1.9.3a1pre) Gecko/20091220 Minefield/3.7a1pre Firefox/3.7
Build Identifier: 

Starting with the 2009-12-14-03 trunk build, I've noticed scrolling corruption in the textareas on the MozillaZine forums.

enabling/disabling HTML5 has no effect. Happens on both x86 and x86_64

Reproducible: Always

Comment 1

[Matthew Turnbull [Bluefang]]

Attachment: Test case

I'm not sure whether or not this test case is minimal.

Happens with scrolling by mousewheel, cursor, and scrollbar. Mousing-out and unfocusing the textarea appears to fix the corruption.

Comment 2

[Boris Zbarsky [:bzbarsky]]

roc, could this be your composite() change?

Comment 3

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

Could be, although that should only have resulted in temporary changes.

Comment 4

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

I can't reproduce this with the 20091220 nightly in my Windows VM. Could it be driver specific? Can you try setting your display mode to some generic SVGA mode and see if the problem goes away?

Comment 5

[Matthew Turnbull [Bluefang]]

(In reply to comment #4)
> I can't reproduce this with the 20091220 nightly in my Windows VM. Could it be
> driver specific? Can you try setting your display mode to some generic SVGA
> mode and see if the problem goes away?

I doubt it has anything to do with the drivers, as it wasn't there on the 2009-12-13 Linux build, and it was there on the 2009-12-14 build.

But I tried setting my resolution to 1024x768 and it didn't help.

Comment 6

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

Oh wait, this is Linux. Sorry, will retest.

Comment 7

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

I definitely see the bug on Linux. I probably should just back out the change, but I'll first check to see if the rest of the scrolling patches fix the bug.

Comment 8

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

Adding the rest of the scrolling patches doesn't fix the bug. We'll have to back out the change that caused the regression.

Comment 9

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

Fixed by backout of offending patch.
http://hg.mozilla.org/mozilla-central/rev/80bd9c61fbff

Comment 10

[Matthew Turnbull [Bluefang]]

I'd like to agree, but I still see scrolling corruption.

Also, now that I think about it, that couldn't have possibly been the cause. In  Bug 526394 you mentioned that you checked it in on 2009-12-19, but the corruption showed up in the 2009-12-14 build.

Comment 11

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

What's in the real regression range, then?

Comment 12

[:Gavin Sharp [email: [e-mail]]]

(In reply to comment #11)
> What's in the real regression range, then?

From comment 5:
> I doubt it has anything to do with the drivers, as it wasn't there on the
> 2009-12-13 Linux build, and it was there on the 2009-12-14 build.

Using the source stamps from those linux nightlies gives this range:
https://hg.mozilla.org/mozilla-central/pushloghtml?fromchange=3ff17b03644e&tochange=44c392db6672

Comment 13

[:Gavin Sharp [email: [e-mail]]]

Bug 518506, perhaps?

Comment 14

[Karl Tomlinson (:karlt)]

Yes, seems to be something from bug 518506.
Looks like empty rectangles might be confusing pixman.

Breakpoint 37, nsWindow::Scroll (this=0x7f470b2a69b0, aDelta=@0x7fff4feb7d50, 
    aDestRects=@0x7fff4feb7c00, aConfigurations=@0x7fff4feb7d10)
    at /home/karl/moz/dev/widget/src/gtk2/nsWindow.cpp:1916
(gdb) p aDestRects.Length()
$270 = 4
(gdb) p aDestRects[0]
$271 = (const nsIntRect &) @0x7f470b11bec8: {
  x = 11, 
  y = 42, 
  width = 534, 
  height = 15
}
(gdb) p aDestRects[1]
$272 = (const nsIntRect &) @0x7f470b11bed8: {
  x = 11, 
  y = 57, 
  width = 1, 
  height = 0
}
(gdb) p aDestRects[2]
$273 = (const nsIntRect &) @0x7f470b11bee8: {
  x = 12, 
  y = 57, 
  width = 50, 
  height = 210
}
(gdb) p aDestRects[3]
$274 = (const nsIntRect &) @0x7f470b11bef8: {
  x = 62, 
  y = 57, 
  width = 483, 
  height = 0
}
(gdb) p blitRegion
$275 = {
  <nsAutoRefBase<pixman_region32>> = {
    <nsSimpleRef<pixman_region32>> = {
      <pixman_region32> = {
        extents = {
          x1 = 11, 
          y1 = 42, 
          x2 = 545, 
          y2 = 267
        }, 
        data = 0x7f470b276970
      }, <No data fields>}, <No data fields>}, <No data fields>}
(gdb) p *blitRegion->data
$276 = {
  size = 6, 
  numRects = 3
}
(gdb) p *(pixman_box32*)(blitRegion->data + 1)@3
$283 = {{
    x1 = 11, 
    y1 = 42, 
    x2 = 545, 
    y2 = 57
  }, {
    x1 = 11, 
    y1 = 57, 
    x2 = 12, 
    y2 = 57
  }, {
    x1 = 12, 
    y1 = 57, 
    x2 = 62, 
    y2 = 57
  }}

(The empty rectangles come from rounding non-empty appunit rectangles to pixels.)

Comment 15

[Karl Tomlinson (:karlt)]

Attachment: don't init pixman regions with empty boxes

Comment 16

[David Baron :dbaron: (⌚️UTC-5, no longer working on Mozilla)]

Here's an additional set of steps to reproduce that are also fixed by the patch attached here.  (How'd I get here?  I bisected the regression range using nightlies and found it was http://hg.mozilla.org/mozilla-central/pushloghtml?fromchange=3ff17b03644e&tochange=44c392db6672 , found bug 518506 in that range as the most obvious candidate, looked at its dependencies, found this bug with a patch, and tested the patch.)

Steps to reproduce:
 1. load http://maps.google.com/
 2. enter "pizza in 94301" in the search field, or any other search likely to produce a decent length list of results (more than a page)
 3. drag the scrollbar separating the results from the map downward

Actual results: after scrolling the top of the results off, there's no blitting in the middle while scrolling, only repainting at the edges.

Expected results: everything scrolls

Comment 17

[Karl Tomlinson (:karlt)]

http://hg.mozilla.org/mozilla-central/rev/ba8780007126

Comment 18

[Benjamin Smedberg]

http://hg.mozilla.org/projects/firefox-lorentz/rev/99adb70d46b1

Comment 19

[Mike Beltzner [:beltzner, not reading bugmail]]

Blanket approval for Lorentz merge to mozilla-1.9.2
a=beltzner for 1.9.2.4 - please make sure to mark status1.9.2:.4-fixed

Comment 20

[Benjamin Smedberg]

Merged into 1.9.2 at http://hg.mozilla.org/releases/mozilla-1.9.2/rev/84ba4d805430