430613 - The mysterious red dot icon causes missing "Loading" and "Broken" image placeholder icons

Status: RESOLVED WORKSFORME

(Core :: Layout: Images, Video, and HTML Frames, defect)

Description

[Alex Faaborg [:faaborg] (Firefox UX)]

Attachment: The mysterious red dot

Can anyone tell me what if this is one of our icons, and if so where the icon lives?  I see this icon from time to time in the place of a layout/generic/broken-image.gif

Comment 1

[Alex Faaborg [:faaborg] (Firefox UX)]

Attachment: Another look, back to the normal images

I went back to look at the icon again and now it appears as loading-image.gif (which we have been stretching strangely), and eventually broken-image.gif (also stretched.)

this leads me to think that the red dot is being served up by imageshack.us, but I want to make sure it is not one of icons living in cdata somewhere, since I tend to see it pretty often.

Comment 2

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

That image is drawn from C++ code directly, when we fail to load the placeholder image:
http://mxr.mozilla.org/mozilla/source/layout/generic/nsImageFrame.cpp#1078

Comment 3

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

Better link: http://bonsai.mozilla.org/cvsblame.cgi?file=/mozilla/layout/generic/nsImageFrame.cpp&rev=1.420&mark=1060,1077,1086,1087#1060

Comment 4

[fswl1234]

it looks worse in tb
https://bugzilla.mozilla.org/show_bug.cgi?id=272534

Comment 5

[Alex Faaborg [:faaborg] (Firefox UX)]

Interesting, well this is the first icon I've encountered that we are drawing
in code.

It would be good for us to draw something closer to the new loading and error
icons (bug 240463), although that is obviously more complex than the current
implementation.

Perhaps draw just the document outline and folded corner using 7 lines:
https://bugzilla.mozilla.org/attachment.cgi?id=317469 

Comment 6

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

I'm not sure how much code we want to add to improve this icon, given that it's (in theory) not meant to appear unless there's either a packaging error or some kind of exceptional circumstance (OOM?). Are you seeing it that frequently?

Comment 7

[Smokey Ardisson (offline for a while; not following bugs - do not email)]

I used to see it all the time (almost every new Camino nightly) for about a year, and then I went for six months or so without seeing it, and then coincidentally it came back last night when relaunching (the same build) after an OS update.

Prior to my seeing it for the first time in Camino, I had seen it so much in Firefox (this would be about the 1.0 era and before) that I thought it *was* Firefox's loading icon :P

Clearly there's some circumstance that's not all that exceptional (at least for some of us) that causes this.

Comment 8

[Smokey Ardisson (offline for a while; not following bugs - do not email)]

Also, it's not clear from Alex's comment 0 and comment 1 whether those are the from the same browsing session or not, but in my experience when you launch and get the red dot, you're stuck with it until you quit and relaunch (and hope you don't get the red dot again).

Comment 9

[Alex Faaborg [:faaborg] (Firefox UX)]

>Also, it's not clear from Alex's comment 0 and comment 1 whether those are the
>from the same browsing session or not

That was not the same browsing session.

>but in my experience when you launch and
>get the red dot, you're stuck with it until you quit and relaunch

Now that you mention it, I'm pretty sure I have seen that behavior as well.

Comment 10

[Kai Liu]

(In reply to comment #7)
> I used to see it all the time (almost every new Camino nightly) for about a
> year, and then I went for six months or so without seeing it, and then
> coincidentally it came back last night when relaunching (the same build) after
> an OS update.
> 
> Prior to my seeing it for the first time in Camino, I had seen it so much in
> Firefox (this would be about the 1.0 era and before) that I thought it *was*
> Firefox's loading icon :P
> 
> Clearly there's some circumstance that's not all that exceptional (at least for
> some of us) that causes this.
> 

Yea, I've had that happen too; there was a period--about a month or so--when I'd see the red dot a lot, across many sessions.  But it's been a very long time since I last saw it; I had almost forgotten about it until I stumbled across this bug.

If this is happening a lot, the best thing to do is to try to figure out why it's happening and fix the cause instead of bandaging the symptom.  If anything, the red is nice in that if people see it and complain, then there's a greater chance of a problem or regression being noticed by the developers.

Comment 11

[Alex Faaborg [:faaborg] (Firefox UX)]

At a minimum could we start by commenting out the line that draws the red dot.

Comment 12

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

(In reply to comment #11)
> At a minimum could we start by commenting out the line that draws the red dot.

Not sure what that would get us... what we need to figure out is why people are seeing the red dot in the first place.

Comment 13

[Branislav Kirilov]

I think i have an idea how to reproduce this. I was browsing a site and decided to do subscribe for the page rss feed. Clicked on rss then subscribe to this feed using live bookmarks and then subscribe now button. I think that i started to see the red dot image for loading/broken images. 

What i tried was to restart firefox saving sessions. Problem was still there. After closing all tabs and restarting firefox problem was gone. Hope it helps :)

Comment 14

[Alex Faaborg [:faaborg] (Firefox UX)]

>Not sure what that would get us... what we need to figure out is why people are
>seeing the red dot in the first place.

This would achieve making the icon look less like a Japanese flag, in the meantime.  I'm interested in resolving the aspect of this bug that is a polish problem, even if it takes us awhile to get to the root of the actual problem.

Comment 15

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

Oh, sure. I didn't realize that you were suggesting that having no icon is better than having the current alternate icon.

Either way we should probably have a separate bug for "figure out why alternate icon appears so often", if this one is "alternate icon is ugly and should be removed/improved".

Comment 16

[Smokey Ardisson (offline for a while; not following bugs - do not email)]

(In reply to comment #15)
> Oh, sure. I didn't realize that you were suggesting that having no icon is
> better than having the current alternate icon.

FWIW, I think something less ugly than the red dot is better than nothing at all (e.g., comment 5).

> Either way we should probably have a separate bug for "figure out why alternate
> icon appears so often", if this one is "alternate icon is ugly and should be
> removed/improved".

Like bug 272534?

Comment 17

[Kai Liu]

I don't think that the replacement for the red dot should resemble the current loading-image and broken-image icons; losing the ability to distinguish between the normal icons and the fallback icon could make some bugs harder to notice.  And since this is code that in theory should not be running, simplicity would be nice.  So given that, what about a red X?  That should be simple to draw, users would more easily and clearly understand the meaning of a red X, and, of course, there's the IE parity.  ;)

Comment 18

[Alex Faaborg [:faaborg] (Firefox UX)]

From the user's perspective the fallback icons should be identical to the broken image and loading image icons (that actually both went through 3 revisions).  If you need to be able to track when the fallback icon is appearing for the purposes of fixing the bug, can you send a message to the error console or something.

Comment 19

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

If we're going to make the fallback draw the same thing as the intended image, we might as well get rid of the original image file. Whatever bug is causing us to fail to draw the original image can just as well affect our drawing of the fallback, too - what happens then? A fallback for the fallback image? :)

Comment 20

[Smokey Ardisson (offline for a while; not following bugs - do not email)]

(In reply to comment #19)
> If we're going to make the fallback draw the same thing as the intended image,
> we might as well get rid of the original image file.

Doing that removes the ability for theme authors (and especially other Gecko consumers) to ship something that matches their aesthetic vision and instead forces everyone to conform Firefox's aesthetic vision of the world.

The red-dot is clearly user-unfriendly; it doesn't indicate at all what it's supposed to be, so I think it really needs to go.  On the other hand, until we've fixed the underlying bug, a sufficiently-descriptive (but also sufficiently-generic) icon-in-code seems like the right solution for this bug.

Comment 21

[Alex Faaborg [:faaborg] (Firefox UX)]

The mysterious red dot was featured briefly last night on NBC prime time during an advertisement for remax.  Until we solve the actual bug, I recommend we comment out the line of code that draws the bright red dot.

Comment 22

[Alex Faaborg [:faaborg] (Firefox UX)]

This bug's priority relative to the set of other polish bugs is:
P2 - Polish issue that is in a secondary interface, occasionally encountered, and is easily identifiable.

I'm tempted to set this P1 since it is so obvious once it strikes, but it isn't a standard behavior, and it isn't always in effect, so pushing it down to P2.

Comment 23

[Torvin]

hi guys. i see this bug from time to time, and today it's been very annoying and i couldn't get rid of it restarting ff as usual, so i decided to investigate.
i ran ff under OllyDbg and.. the bug disappeared. i did that several times, but bug never appeared while ff was under my debugger but it still appeared every time ff was started without debugger. so i decided there is some kind of race condition there.
i attached a debugger after ff was started and found nsImageFrame::gIconLoad in memory. it's mIconsLoaded field was zero and there were red dots in ff. then i just changed that value to '2' and normal placeholders appeared!
so, it looks like icons where loaded, but mIconsLoaded flag was not changed. i examined nsImageFrame.cpp carefully and found out that mIconsLoaded is changed only in HandleIconLoad (not taking into account the nsImageFrame::IconLoad::IconLoad ctor). so, everything looks like this HandleIconLoad function was never called. 
and i think the reason of that is because icons are loaded by the first instance of nsImageFrame, which may be destructed BEFORE icons are loaded, since they are loaded asynchronously. so, if nsImageFrame::mListener is destroyed before any icons are loaded, HandleIconLoad callback won't be called and we'll see no icons in spite of icons are loaded successfully.

i'm not sure which is the better way to fix that, but hope that helps. please tell me if i'm wrong.

Comment 24

[Dão Gottwald [:dao]]

Thanks Torvin.

Comment 26

[Smokey Ardisson (offline for a while; not following bugs - do not email)]

Adjusting summary to incorporate some of the salient searchable keywords from bug 272534 (which, contrary to my statement in comment 16, isn't very useful now that this bug has the actual analysis of why the red dot appears).

Comment 27

[(mostly gone) XtC4UaLL [:xtc4uall]]

Is regressionwindow-wanted still needed here wrt the Analysis in Comment 23?

Comment 28

[toe_head2001]

I'd say this should be marked as fixed.

Comment 29

[Jet]

I say that this is not working properly still @Firefox 22

Comment 30

[Paul Silaghi, QA [:pauly]]

(In reply to X3 from comment #29)
> I say that this is not working properly still @Firefox 22
How can I reproduce this?

Comment 31

[zigboom]

Attachment: red-dot.png - the horror is back on Nightly, every image and every time it's loading

Come on guys, why RED ? the pages look like hell on earth while they load. I fyou cannot fix it for so many years, why not choose a gray image that will not blind the eyes and annoy so much ? the person who designed it must be color blind :) 
I had to cancel image placeholders because its unbearable :(

Comment 32

[zigboom]

A quick fix for the hurting eyes .. I added the following CSS (with Stylish): 

@-moz-document url-prefix() {
    
    /* Make Loading and Broken Images Grayscale */
    img:-moz-loading, img:-moz-broken {
    filter: grayscale(100%);
    }
    
}

It makes the icon Grayscale instead of red so it doesn't hurt the eyes while loading. 
Hopefully the bug will get fixed so the real image placeholder will be back.

Comment 33

[Timothy Nikkel (:tnikkel)]

If you're problem started recently then you are most likely seeing bug 1106252.

Comment 34

[BugBot [:suhaib / :marco/ :calixte]]

The severity field for this bug is relatively low, S3. However, the bug has 11 votes.
:emilio, could you consider increasing the bug severity?

For more information, please visit auto_nag documentation.

Comment 35

[BugBot (nomail) [:suhaib / :marco/ :calixte]]

The last needinfo from me was triggered in error by recent activity on the bug. I'm clearing the needinfo since this is a very old bug and I don't know if it's still relevant.

Comment 36

[Timothy Nikkel (:tnikkel)]

Anyone still seeing this? I'm gonna close this, please re-open if you still see it.