384143 - multiple lines draw on the bottom when scrolling down google reader on feeds with many photos

Status: RESOLVED FIXED

(Core :: General, defect)

Description

[jose israel]

User-Agent:       Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9a6pre) Gecko/20070611 Minefield/3.0a6pre
Build Identifier: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9a6pre) Gecko/20070611 Minefield/3.0a6pre

When viewing an RSS feed like ENGADGET (with big photographs embedded) in Expanded view of google reader web page, when you scroll down the web with the wheel mouse, horizontal light blue lines appear on the bottom of the right frame. It only happens when scrolling down, not when scrolling up, and sometimes the screen refreshes and the lines dissapear. It allways reproduce, tested on several machines with different graphics cards and drivers versions updated.

Reproducible: Always

Steps to Reproduce:
1.Open google reader and go to engadget RSS feed.
2.Scroll down with the mouse wheel quickly on expanded view.

Actual Results:  
Blue horizontal lines appear almost on every image on the right frame.

Expected Results:  
Display images correctly without horizontal lines.

No themes, no addons.

Comment 1

[jose israel]

Attachment: screen capture of the problem

bug screeen captured

Comment 3

[Jean-Marc Desperrier]

Jose, as far as I'm concerned, almost every single google reader entry is concerned. The one with photo are easier for reproduction only because they take much more vertical space. 
The trouble is that in "Expanded View" it's almost every, but not every, and it's a bit dependant on the repro step. 
I have apparently 100% reproductible steps in "List View" mode :

- Display a large list of items in "List View"
- click on the lowermost item to expand it. 
- After expansion, you can only see the upper part of the item
- scroll up to view the rest of the item that is hidden
- the blue lines appears

This is *not* a dupe of bug 376124, because the problems described in bug 376124 appeared much earlier than that.

Here are the checkin in that regression window :
http://bonsai.mozilla.org/cvsquery.cgi?treeid=default&module=PhoenixTinderbox&branch=HEAD&branchtype=match&dir=&file=&filetype=match&who=&whotype=match&sortby=Date&hours=2&date=explicit&mindate=2007-05-30+04%3A00&maxdate=2007-05-31+05%3A00&cvsroot=%2Fcvsroot

I hope I'm not accusing wrongly :-), but the most likely culprit seems to be vladimir in bug 379834.

Comment 4

[Jean-Marc Desperrier]

One line is missing in my previous comment : 
I isolated the regression windows to be between the 05/31 and the 05/30 nightly builds.

Comment 5

[Jean-Marc Desperrier]

I tried to save the reader page locally to reproduce the problem from a page on my hard drive but without success. I suspect the bug is somehow linked to the use of javascript.

Comment 6

[Vladimir Vukicevic [:vlad] [:vladv] (needinfo me, slow to respond)]

Pretty sure this isn't due to my patch for bug 379834 -- however, I can't seem to reproduce this in my debug build, with or without the patch for 379834.  I -can- see it in the nightly build though; I'm not sure what the difference is.

Comment 7

[Vladimir Vukicevic [:vlad] [:vladv] (needinfo me, slow to respond)]

Taking for investigation.

Comment 8

[Jean-Marc Desperrier]

Despite the regression window not being the same, I can not repro this anymore with the latest nightly that includes the fix for bug 382458 (but it might around two weeks since I didn't test for the bug)

Are other people also seing this as fixed ?

Comment 9

[Vladimir Dudas]

I would say it's partially fixed. Instead of full lines across, all I am seeing are 1 pixel white breaks in the border of the active item. 

It is more easily replicated using keyboard up/down arrows. I think it only happens when reader fetches more items and resizes the "river" pane

Comment 10

[Jean-Marc Desperrier]

(In reply to comment #9)

I can not repro what you describe *and* I'd say it looks like a different bug.
Can you include a screen capture of what you see as well as check if it's the same regression windows ? 

(The regression windows of this bug is between the buid http://ftp.mozilla.org/pub/mozilla.org/firefox/nightly/2007-05-30-04-trunk/
and 
http://ftp.mozilla.org/pub/mozilla.org/firefox/nightly/2007-05-31-04-trunk/
)

Comment 11

[Vladimir Dudas]

Attachment: Screen capture of one pixel breaks

Comment 12

[Vladimir Dudas]

(In reply to comment #10)

It turns out that one pixel breaks do appear in 2007-05-30 build.. It took me a while to reproduce it, but it is there. Will open new bug

Comment 13

[Jean-Marc Desperrier]

As nobody complained still seing this, I'll mark this as FIXED (Maybe it should be WORKSFORM, as no specific patch was checked in to fix it, but I don't like it, it still very easy to repro with the older builds).

(In reply to comment #12)
I didn't see a new bug with you as the reporter. When I keep the down arrows pushed I sometime see the problem you describe, but as soon as I release the key, the screen is redrawn and the problem disappears. Everytime the entry gets focus and is redrawn it disappears also. So it's so transient I'd be unable to do the screen capture you provided. How comes the entry doesn't have focus ? (grey border instead of blue)

Comment 14

[mdavila78]

The problem has not been solved, those lines all over the screen while I use Firefox.  I've been forced to use IE 7.

Can't you guys figure out what's the bug?

Build identifier: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.8.1.4) 
Gecko/2007051502 Firefox/2.0.0.4

Comment 15

[Jean-Marc Desperrier]

(In reply to comment #14)
mdavila, this bug is about a problem that occured with the *trunk* builds of Firefox from the 2007-05-31 until around the 2007-07-02 build.

If you have a problem with the 2.0.0.4 build of Firefox, it's very unlikely to have the same cause.

The 2 branch is a stable branch, your problem will very probably only be fixed if it's a regression brought after the initial 2.0 release. You need to check that, and what exactly the repro steps are.

Two problems may look quite similar externally but not have the same cause. And if they do not have the same cause, they are completely independent as far as the developers are concerned.