Closed Bug 640444 Opened 12 years ago Closed 12 years ago

Regression: Graphic corruption while panning on a Hacker News page


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

Not set



Tracking Status
fennec 2.0+ ---


(Reporter: mbrubeck, Assigned: cjones)



(Keywords: regression, Whiteboard: [has patch][has review])


(2 files)

Attached image screenshot
Steps to reproduce:
1. Open
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.
I am seeing this on Samsung Verizon Galaxy Tab and on HTC T-Mobile G2.  I couldn't reproduce it on desktop.
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.
THis should be blocking I think.
(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.
tracking-fennec: ? → 2.0+
I can reproduce this on Linux Desktop, on a different HN page.
Bisected so far to nightly resolution. March 2nd's nightly still works, the regression begins March 3rd.
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.
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:
Depends on: 624454
Are you sure? I'm still seeing this after reverting that change on tip.
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.
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).
Ok, my bisecting is 100% reproducible as follows:

1. Download
   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
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);


   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?).
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
I thought about this some, and there might be a regression from bug 635035 that could cause something this.  Attempting a test case.
I can reproduce painting corruption with the following, on desktop

 (1) Open fennec in portrait orientation
 (2) Load
 (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.
Assignee: nobody → jones.chris.g
Attachment #518795 - Flags: review?
Attachment #518795 - Flags: review? → review?(bas.schouten)
This patch fixes the issue for me.  (Tested with and without patch on Galaxy Tab in portrait with )
Whiteboard: [has patch][needs review]
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.
While the problem remains on linux desktop, the patch does appear to fix things on Galaxy S (not surprising given comment #17).
(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.
A separate bug is fine by me, but the symptoms are identical, so I am guessing they have a single underlying cause.
Attachment #518795 - Flags: review?(bas.schouten) → review+
Whiteboard: [has patch][needs review] → [has patch][has review]
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?
Closed: 12 years ago
Resolution: --- → FIXED
Blocks: 641538
(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.
could it make a regression in bug 641599?

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)
You need to log in before you can comment on or make changes to this bug.