Strange dots next to Slashdot news headers




Layout: Images
19 years ago
9 years ago


(Reporter: Blake Ross, Assigned: paper)


({regression, top100})

regression, top100
Dependency tree / graph

Firefox Tracking Flags

(Not tracked)




(8 attachments, 4 obsolete attachments)



19 years ago
Build ID: 2000042808

There seems to be a strange rectangular dot preceding each news header on /.  
It's not only on the same page, but is also to the left of the headers in 
anactual story/comments page (which you can reach by clicking one of the news 
stories for the day).

Haven't had a chance to study this yet, but figured I should report it since 
the dots don't appear in IE 5.5 or NS 4.72

Comment 1

19 years ago
Created attachment 8099 [details]
html code that demonstrates the problem

Comment 2

19 years ago
This was reported previously as bug 18657, but that got duped and then its dup-
of got marked as WORKSFORME.

The offending image is loaded on any dark 
background.  The bottom quarter of the image looks different each time mozilla 
renders it.  If you load the image from the same server without restarting 
mozilla, you will see the same corruption each time.  If you trick mozilla into 
thinking it's using a different server (as I did by varying the case in the 
hostname), however, it will corrupt each one differently.

Trying imagelib component.
Component: Layout → ImageLib

Comment 3

19 years ago
Reassigning  to component owner
Assignee: troy → pnunn
QA Contact: petersen → elig

Comment 4

19 years ago
dang..i just commented about this in bug 36869 - this seems to be a dupe of it.
Can it be the alt-tag that displays in that cell, just underneath the image?
The screenshot in 36869 isn't too clear but indicates it can actually be "" that
displays, the first " in bold, and both tainted in shades of blue?
I can't reproduce this bug on Linux, thus the guesswork.

Comment 5

19 years ago
Created attachment 8135 [details]
screenshot of testcase (2000042808, win 98)

Comment 6

19 years ago
Target Milestone: --- → M16

Comment 7

19 years ago
It has nothing to do with the table. It appears to
be solely an image problem (or an image rendering problem).
(Note to self: see local test file.)


19 years ago
Target Milestone: M16 → M17


19 years ago
Target Milestone: M17 → M18

Comment 8

19 years ago
I just added some comments to bug 38656 that are pertinant to this. 

Comment 9

18 years ago
*** Bug 40681 has been marked as a duplicate of this bug. ***

Comment 10

18 years ago
*** Bug 40681 has been marked as a duplicate of this bug. ***

Comment 11

18 years ago
*** Bug 36869 has been marked as a duplicate of this bug. ***

Comment 12

18 years ago
*** Bug 42285 has been marked as a duplicate of this bug. ***

Comment 13

18 years ago
Created attachment 10124 [details]
another demo img of bug from dupe#42285

Comment 14

18 years ago
From 42285 I have created a smaller test case with and without the image that 
causes the problem.

Comment 15

18 years ago
*** Bug 45744 has been marked as a duplicate of this bug. ***


18 years ago
Keywords: nsbeta3

Comment 16

18 years ago
seems to be only on specific images... 
Whiteboard: [nsbeta3-]

Comment 17

18 years ago
*** Bug 38656 has been marked as a duplicate of this bug. ***

*** This bug has been marked as a duplicate of 18754 ***
Last Resolved: 18 years ago
Resolution: --- → DUPLICATE
I don't believe I just did that. This is the second time I've accidentally
marked a bug duplicate in two days. I offer you my humble appologies once more.
Resolution: DUPLICATE → ---

Comment 20

18 years ago
Created attachment 15403 [details] [diff] [review]
Patch (moves gif_clear_screen after converter init)

Comment 21

18 years ago
The problem is caused by a bug in the gif decoder: it calls gif_clear_screen 
before calling ImgDCBSetupColorspaceConverter. Then the target image is written 
to as if it was an 8 bit image, while it is actually 24 bit, leaving 
uninitialized garbage in the target image.

The attached patch solves this by moving the gif_clear_screen call to after the 
ImgDCBSetupColorspaceConverter call. This undoes the fix for bug #13048, which 
moved gif_clear_screen to use the is_transparent flag. Therefore the 
is_transparent flag clearing is moved too, to reset it after the image is 
done instead of before the image is decoded. This seems the right place since it 
is set between the decoding of the last and the next image... 
(probably it would be even better to split the gif_image_start state in two 
states: an initializing state that resets all these flags, and then jumps to the 
looping state, but I didn't dare to change so much.)

Unfortunately the external accessible page for bug 13048 seems to be changed so 
I can't test if bug 13048 is still fixed :-(

Comment 22

18 years ago
Adding patch keyword.  Thanks :)

It looks like there's a copy of the page for bug 13048 at an internal Netscape 
url, so someone at Netscape should be able to test whether your patch leaves 
that image intact.
Keywords: patch

Comment 23

18 years ago
Adding review, approval, rtm keywords. This seems to be a simple straightforward
change, and we should be able to do this correctly in our release.
Keywords: approval, review, rtm

Comment 24

18 years ago
Either there is something funky with that image, or Paint Shop Pro 7 has the 
exact same bug as Mozilla. When I view the gif in PSP7 and do Colors -> Show 
Palette Transparency, that dot is the only thing left. It is quite odd. If 
Mozilla can fix that, that would be nice though.

Comment 25

18 years ago
Happens here in Windows 2000
kinda annoying

Comment 26

18 years ago
*** Bug 56608 has been marked as a duplicate of this bug. ***

Comment 27

18 years ago
Created attachment 18170 [details]
resized problem gif

Comment 28

18 years ago
The image has 2 colors that should be set for transparency.
The colors are close (70,82,84 and 50,102,100).

This doesn't explain the problem yet. The gif in question show
band across 2/3 of the bottom of the image, not all the way across
as the 2nd color would predict.
And there are reports of the band *flashing*. 

I'll attach a screengrab of a testpage showing the image
transparency issue.


Comment 29

18 years ago
Created attachment 18176 [details]
scrngrab of test page showing transparency problem.

Comment 30

18 years ago
Has anyone reviewed the patch?  Is there something wrong with it?  Time is
almost completely gone to get this into rtm, but if this is a correct patch that
can be reviewed and tested _immediately_ it isn't yet too late...

If it isn't worth the bother, please mark rtm- in the whiteboard.
Whiteboard: [nsbeta3-] → [nsbeta3-][need info]

Comment 31

18 years ago
PDT marking [rtm-]. Looks like this patch has languished without review, and we
can't hold for this bug at this time.
Whiteboard: [nsbeta3-][need info] → [nsbeta3-][rtm-]


18 years ago
Blocks: 61477


18 years ago
No longer blocks: 61477


18 years ago
Blocks: 61477


18 years ago
QA Contact: elig → tpreston

Comment 32

18 years ago
Meanwhile I received the files of bug 13048, and I didn't see anything wrong 
with my patch. I didn't see anything wrong either when I undid the patch of bug 
13048, so maybe I'm missing something, but I don't think that should hold up 
the patch for this bug.

Comment 33

18 years ago
Looks ok. Thanks for the patch and
sorry it took so long to get it reviewed.


Comment 34

18 years ago

Comment 35

18 years ago
Fix checked in.  Thanks for the patch!
Last Resolved: 18 years ago18 years ago
Keywords: approval, nsbeta3, patch, review, rtm
Resolution: --- → FIXED
Whiteboard: [nsbeta3-][rtm-]

Comment 36

18 years ago
Verified Win build 2001021604
Verified Linux build 2001021608
Verified Mac build 2001021604

Comment 37

17 years ago
I still occasionally see this
Resolution: FIXED → ---

Comment 38

17 years ago
Created attachment 67264 [details]
Screenshot of Slashdot

Comment 39

17 years ago
Created attachment 67272 [details]
screenshot 01/31/2002 Win2000


17 years ago
Keywords: top100

Comment 40

17 years ago
Seeing this in 2002020103, Windows XP with nVidia GeForce 2 card

Comment 41

17 years ago
I saw this image bug crop up in an unexpected place -- while viewing screenshots
for cygwin/xfree86 rendering a konquerer window displaying slashdot in an 8bpp X
server running within Microsoft Windows (parse that!).

Konq doesn't use gecko, does it? Is it determined that the image itself isn't
the problem? 

fwiw, the same problem still occurs for me in XP on 0.9.8 using a geforce2 gts

Comment 42

17 years ago
*** Bug 124833 has been marked as a duplicate of this bug. ***
Original problem was seen at:
Changing URL to a data URL testcase.
Assignee: pnunn → pavlov
Severity: minor → normal
Keywords: regression
OS: Windows 98 → All
Priority: P3 → --
Target Milestone: M18 → ---
*** Bug 118452 has been marked as a duplicate of this bug. ***
A new type of behavior has also appeared for me with 0.9.8 Somtimes there is an
actual white gap, guessing 3-4 pixels high at the bottom of the image. I'll
attach a screenshot next time this happens.

Still see the dots most of the time (again with 0.9.8)

Comment 47

17 years ago
I don't see dots, but I do see the gray line at the bottom of the image. It only
seems to happen first time I go to the site after my cache is emptied. If I hit
refresh, the problem goes away.


17 years ago
Blocks: 134942


17 years ago
Component: ImageLib → Image: Layout
Target Milestone: --- → mozilla1.2alpha

Comment 48

16 years ago
Mass removing self from CC list.

Comment 49

16 years ago
Now I feel sumb because I have to add back. Sorry for the spam.

Comment 50

16 years ago
If you clear your cache (while not on slashdot) then goto you'll
see the image flaws next to each article header.  As soon as you refresh the
screen, or minimize the window and maximize the window or drag another window on
top of the messed up images.. it fixes its self.

(this is on MacOSX 10.1 with build 2002060203)

Comment 51

16 years ago
I have a fix for this.. taking
Assignee: pavlov → paper


16 years ago

Comment 52

16 years ago
Sorry for the delay.  I've been waiting on Bug 87819 (although I can't remember
why, but I'm going to assume it was because it blocks this one)


Placeholder does not disappear after image is loaded.  Build 2002071908.
Patch coming in the next day or so.
Depends on: 87819

Comment 53

16 years ago
Created attachment 92764 [details] [diff] [review]
good karma coming, mod me up :P

Reviewers reference:

Chunk #1
Update the whole image width, and the right y-axis areas

Chunk #2 and #3
Read the comments in the code :D


16 years ago
Severity: normal → minor
Keywords: patch, review
Hardware: PC → All

Comment 54

16 years ago
futuring since I don't have time to hunt down r='s
Target Milestone: mozilla1.2alpha → Future


16 years ago
Attachment #15403 - Attachment is obsolete: true
+      if (imgHeight > realFrameHeight) {
+        PRInt32 imgWidth;
+        decoder->mImageContainer->GetWidth(&imgWidth);
+        nsRect r(0, realFrameHeight, imgWidth, imgHeight - realFrameHeight);

what if the imgHeight=frameHeight but frame width is smaller than image width?

or does that already work in our code?

Comment 56

16 years ago
Yes, that's what chunk #1 makes sure of.  It notifies observers that the whole
width of the image is available, instead of just the frame's width.

Comment 57

16 years ago
Created attachment 102620 [details] [diff] [review]
The Patch

Fixed spelling error and put spaces between operators.	No code change -- just
Attachment #92764 - Attachment is obsolete: true
Comment on attachment 102620 [details] [diff] [review]
The Patch

ok... two questions:
in the second part: should the comment also mention the bug#?
and in the third part: would a better place for that code be in FlushImageData?
because that seems to be the function which does the other OnDataAvailable

Comment 59

16 years ago
Created attachment 102686 [details] [diff] [review]
The Patch

-Fixed height calculations in chunk 1 (was adding framerect.y to nsRect.height
when that's plainly wrong)
-Bug # added to chunk 2

FlushImageData doesn't know whether it's at the end of the image or not, so
putting chunk 3 there wouldn't work.  This is especially true for interlaced
GIFs, who (may?) reach the end of the frame and then go back up again x more
times.	Better to do it at EndImageFrame where we definitely know there's no
more for the frame.
Attachment #102620 - Attachment is obsolete: true

Comment 61

16 years ago
Created attachment 102709 [details] [diff] [review]
The Patch

Had an extra chunk on there that wasn't supposed to be there (wasn't on the
other patches as in junk)
Attachment #102686 - Attachment is obsolete: true
Comment on attachment 102709 [details] [diff] [review]
The Patch

oh, right, I wondered about that but I misread that as just a comment addition
and thought that was fine.

anyway, r=biesi here.

Comment 63

16 years ago
Comment on attachment 102709 [details] [diff] [review]
The Patch

The two new hunks where you call OnDataAvailable() - they're going to
miss a bit if you have an image where the first frame doesn't touch
the top or bottom, aren't they?  You might want to mention in the
comment that we don't have to worry about right/left fixup because
libpr0n currently only does full lines.

Comment 64

16 years ago
Comment on attachment 102709 [details] [diff] [review]
The Patch

Oops, overlooked that both hunk 2&3 are run and are actually doing
something different.

Attachment #102709 - Flags: superreview+

Comment 65

16 years ago
Checked in.
Last Resolved: 18 years ago16 years ago
Resolution: --- → FIXED
You need to log in before you can comment on or make changes to this bug.