640444 - Regression: Graphic corruption while panning on a Hacker News page

Status: VERIFIED FIXED

(Firefox for Android Graveyard :: Panning/Zooming, defect)

Description

[Matt Brubeck (:mbrubeck)]

Attachment: screenshot

Steps to reproduce:
1. Open http://news.ycombinator.com/item?id=2307090
2. Without zooming, pan up and down by small amounts

See the attached screenshot for results.  I also saved a copy of the page in case the content changes later and affects this bug.

Comment 1

[Matt Brubeck (:mbrubeck)]

I am seeing this on Samsung Verizon Galaxy Tab and on HTC T-Mobile G2.  I couldn't reproduce it on desktop.

Comment 2

[Matt Brubeck (:mbrubeck)]

I'm seeing similar glitches on other pages, especially other pages from the same site, though most are not as dramatic as the one in comment 0.

Comment 3

[Benjamin Stover (:stechz)]

THis should be blocking I think.

Comment 4

[Mark Finkle (:mfinkle) (use needinfo?)]

(In reply to comment #3)
> THis should be blocking I think.

I agree. Getting it on the list so it has more visibility. We can debate it there.

Comment 5

[Alon Zakai (:azakai)]

I can reproduce this on Linux Desktop, on a different HN page.

Comment 6

[Alon Zakai (:azakai)]

Bisected so far to nightly resolution. March 2nd's nightly still works, the regression begins March 3rd.

Comment 7

[Alon Zakai (:azakai)]

Can't seem to reproduce this in landscape mode, btw - I need to switch to portrait for it to happen (on desktop). In portrait mode (control-shift-Q) it is very easy to reproduce.

Comment 8

[Alon Zakai (:azakai)]

No wonder the m-c changesets I was bisecting looked completely unrelated... the changeset that introduces this (by changing a pref) is from m-b. More specifically bug 624454, this part of it:

http://hg.mozilla.org/mobile-browser/rev/0811c1cc3170

Comment 9

[Matt Brubeck (:mbrubeck)]

Are you sure? I'm still seeing this after reverting that change on tip.

Comment 10

[Alon Zakai (:azakai)]

I did check several times, but it is possible I made a mistake somewhere. I'll do some more checking.

Note though that I didn't try on tip - I just bisected. IOW when reverting back to m-c 63295 and m-b 2857, I did not experience the bug, but advancing m-b to 2528 did make it appear. That doesn't necessarily imply that reverting that changeset on tip will fix things, due to interactions.

Comment 11

[Chris Jones [:cjones] inactive; ni?/f?/r? if you need me]

I'm not able to repro anything like attachment 518264 [details] on a desktop build of m-c 3570861040e9 / m-b 34ca5bea3ebe with bug 593243 applied, although I do see seaming (of course).

Comment 12

[Alon Zakai (:azakai)]

Ok, my bisecting is 100% reproducible as follows:

1. Download http://syntensity.com/static/fennec-azakai-63295-2857.tar.bz2
   That is fennec revisions 63295/2857 for linux desktop.
2. Unpack into new dir.
3. Run fennec. (Optionally create a new profile, but it works for me with both new and my old one.)
4. Load http://news.ycombinator.com/item?id=2311279
5. Shift to portrait mode (control-shift-Q). This depends on window size, which also depends on screen size. Mine is 1440x900 - if you cannot reproduce this, perhaps try to change to that resolution.
6. Scroll down a short distance (10% of screen or so), about 20 times. Everything should look fine.
7. Edit defaults/pref/mobile.js, changing 

   pref("toolkit.browser.cacheRatioWidth", 1100);

   to

   pref("toolkit.browser.cacheRatioWidth", 2000);

   This is exactly the change that revision 2858 introduces.
8. Repeat steps 3-6 exactly. You should see that after a few scrolls, the movement becomes terribly jumpy and often leaves a great deal of graphical corruption.
9. You can revert your edit in step 7, and repeating steps 3-6 will work as it did the first time.

If reverting that changeset on tip doesn't fix things, then there might be other factors in play here (patches since then, screen resolution, other stuff?).

Comment 13

[Alon Zakai (:azakai)]

hg hashes of that build are:

http://hg.mozilla.org/mozilla-central/rev/000fe7de6636
http://hg.mozilla.org/mobile-browser/rev/62e1753d84e4

Comment 14

[Aakash Desai [:aakashd]]

I can reproduce this on the latest nightly with my Samsung Vibrant:
Mozilla/5.0 (Android; Linux armv71; rv:2.0b13pre) Gecko/20110311 Firefox/4.0b13pre Fennec/4.0b6pre

Comment 15

[Chris Jones [:cjones] inactive; ni?/f?/r? if you need me]

I thought about this some, and there might be a regression from bug 635035 that could cause something this.  Attempting a test case.

Comment 16

[Chris Jones [:cjones] inactive; ni?/f?/r? if you need me]

Attachment: Self-copies end up changing all buffer content, so we need to read back the entire buffer after swapping

I can reproduce painting corruption with the following, on desktop

 (1) Open fennec in portrait orientation
 (2) Load http://people.mozilla.com/~cjones/input-test.html
 (3) Pan about halfway down the page until the input box appears
 (4) Pan slowly up and down near the input box

The box jumps around, and if the scroll amount is right, you can see two input boxes painted on screen.

This is sort of a dumb bug that's been around forever but only came to light after bug 635035.

Comment 17

[Matt Brubeck (:mbrubeck)]

This patch fixes the issue for me.  (Tested with and without patch on Galaxy Tab in portrait with http://limpet.net/item.html )

Comment 18

[Alon Zakai (:azakai)]

The patch does not fix the issue for me on linux desktop. Tested using the same page mbrubeck posted in comment #17.

The corruptions are different, but still very noticeable. Worse in some cases, better in others.

Comment 19

[Alon Zakai (:azakai)]

While the problem remains on linux desktop, the patch does appear to fix things on Galaxy S (not surprising given comment #17).

Comment 20

[Matt Brubeck (:mbrubeck)]

(In reply to comment #19)
> While the problem remains on linux desktop, the patch does appear to fix things
> on Galaxy S (not surprising given comment #17).

It sounds like we should open a separate bug for the corruption on desktop.  The corruption on Android definitely started on 3/9 around the checkin of bug 635035, while the desktop corruption apparently started on 3/2 with the checkin of bug 624454.  So it seems like they have different causes and different fixes, despite similar symptoms.

Comment 21

[Alon Zakai (:azakai)]

A separate bug is fine by me, but the symptoms are identical, so I am guessing they have a single underlying cause.

Comment 22

[Chris Jones [:cjones] inactive; ni?/f?/r? if you need me]

Alon: is your desktop build using --enable-mobile-optimize?  If not, can you try running with MOZ_LAYERS_FORCE_SHMEM_SURFACES=1 in the environment?

Comment 23

[Chris Jones [:cjones] inactive; ni?/f?/r? if you need me]

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

Comment 24

[Alon Zakai (:azakai)]

(In reply to comment #22)
> Alon: is your desktop build using --enable-mobile-optimize?  If not, can you
> try running with MOZ_LAYERS_FORCE_SHMEM_SURFACES=1 in the environment?

I don't have --enable-mobile-optimize in my mozconfig. Is that on by default?

Running with MOZ_LAYERS_FORCE_SHMEM_SURFACES=1 doesn't have any effect.

I filed bug 641538 to track this issue on Linux Desktop.

Comment 25

[gadjo]

could it make a regression in bug 641599?

Comment 26

[Anna (Waverley)]

VERIFIED FIXED on:

Build ID: Mozilla /5.0 (Android;Linux armv7l;rv:2.0b13pre) Gecko/20110315 Firefox/4.0b13pre Fennec /4.0b6

Devices: Motorola Droid 2 (Android 2.2), Nokia N900 (Linux Maemo GTK)