Closed Bug 52390 Opened 24 years ago Closed 24 years ago

Chrome images failing to load intermittantly

Categories

(Core :: Graphics: ImageLib, defect, P2)

Product:
Core
Component:
Graphics: ImageLib
Type:
defect

Tracking

()

Status:
VERIFIED FIXED

People

(Reporter: andreww, Assigned: pnunn)

References

Details

(Keywords: regression, Whiteboard: [nsbeta3++][rtm+])

Attachments

(2 files)

Screen shot showing missing chk boxes for Prefs (Appearance) and AIM Save Passowrd
48.55 KB, image/gif
Details
diff, turns off pinning chrome in imgcache
261 bytes, patch
Details | Diff | Splinter Review 
At any given time, under many circumstances, chrome images will fail to load. For 
instance on windows, new modern chrome, the "stop" button does not load.  Not 
only does the image not load, but subsequently the button does not work because 
of this.

This occurs intermittantly throughout the app, on mac, linux, windows, on all/any 
skins. The user does _not_ have to switch skins to see this bug.

This is a pretty severe and pernicious bug, as it is causing spurious bug reports 
on other components which are in fact ok - when you reload the app 2 or 3 times.

I dont know if a bug is filed on this already, but this needs to be looked into.
adding hyatt, per request.

Note  that I dont believe this is a dupe of :
http://bugzilla.mozilla.org/show_bug.cgi?id=51249

Necessarily, because images fail to load unpredictably - and this occurs 
regardless of whether you switch skins or not.


this may be related to bug bug 51778 "regchrome doesn't actually register
chrome". A fix was checked in around noon on the 11th.
Also related: bug 51267 "Intermittent failure loading CSS from JARs".
To add to the confusion:
There's also bug 41268 "imglib should cache chrome animations". All in all, i
think this bug is covered.
This sounds more like a jar problem than an image
decoding problem.
Who is handling jar stuff today?
-p
Nope. People are seeing this even with JARs turned off.

It started happening at about the same time that the image cache flush on skin 
switching became broken.

Right I see this on mac, which currently does not use jars.

ok. I'll get my fix in today for flushing chrome from the imgcache.
-p
adding cc

... nominating nsbeta3 for the record
Keywords: nsbeta3, regression
I have a fix for #51249 (human speak: stubborn chrome) and
am waiting for tree to open. This bug(52390) is probably a dupe
of 51249, but I will wait to mark it as such until #51249 is
checked in.
-p
Status: NEW → ASSIGNED
Bug 51249 is fixed but I still see this issue, now with check boxes (Win32 
2000-09-15-06M18 build), using a new profile and looking in prefs, check boxes 
are missing till you check on them, and when you exit and go in the 2nd time 
with the profile, they reappear.
This affects AIM in a big way, and leaves a bad impression for new users as the 
check boxes in the Add Buddy dialog are missing with a new profile in the 
default modern skin.
cc aim folk
*** Bug 51511 has been marked as a duplicate of this bug. ***
*** Bug 52465 has been marked as a duplicate of this bug. ***
*** Bug 50652 has been marked as a duplicate of this bug. ***
Possible dups:
- bug 52854, when low on system resources
- bug 52972, when reloading Mozilla after a crash
I even had this situation where the menu bar was empty. Even several re-loads, 
computer re-boot didn't work, so I had to install the app again...
cc andreww and vishy because the aim checkboxes are affected by this in sign on 
screen
Any chance fixing bug 51267 fixed this one?

*** Bug 52654 has been marked as a duplicate of this bug. ***
Is this happening with the latest build?
-p
Target Milestone: --- → M18
Raising to P2 and voicing my opinion that this should be fixed for nsbeta3.  The 
app feels very unstable with buttons or widgets disappearing at random times.  
Please give this a plus so this get's fixed soon.
Priority: P3 → P2
*** Bug 53274 has been marked as a duplicate of this bug. ***
pnunn, yep this still happens with the 2000.09.19.05 opt comm bits on winnt.
*** Bug 53249 has been marked as a duplicate of this bug. ***
*** Bug 53443 has been marked as a duplicate of this bug. ***
*** Bug 53443 has been marked as a duplicate of this bug. ***
adding myself to cc
Blocks: 53087
Blocks: 52831
methinks this deserves the mostfreq kw after 7 dups...
*** Bug 53482 has been marked as a duplicate of this bug. ***
We have had examples of every type of image in the chrome on all platforms.  
Let's plus this baby and raise it to P1.  We now have checkboxes, radio buttons, 
toolbar buttons, pieces of regular buttons, composer bar buttons, icons from mail 
news all failing to display.  Some of these bugs received P1 nsbeta3+, so it is 
now time to do that here.

*** Bug 51090 has been marked as a duplicate of this bug. ***
Blocks: 53413
Working with Joe's debug build, I turned off PIN_CHROME and this
appears to fix the problem. At worst, we can turn off PIN_CHROME
until I can find out why some of the images are not retrieved from
necko if they don't already exist in the imgcache. (Or perhaps layout
is too eager to fail if there is a slight delay in retrieving the image.)

-p


reassigning to syd.

The fellow who has a debug build that
shows (or rather, doesn't show) the magic
disappearing chrome  is Joe (hewitt@netscape.com).

Changing PIN_CHROME from define to undef seems
to take care of the problem. The cause is not immediately
obvious.

-pn
Assignee: pnunn → syd
Status: ASSIGNED → NEW
*** Bug 53206 has been marked as a duplicate of this bug. ***
I'm on it.
Status: NEW → ASSIGNED
*** Bug 52854 has been marked as a duplicate of this bug. ***
*** Bug 53113 has been marked as a duplicate of this bug. ***
I thought I'd note that this problem has not recurred on my build since pam 
undefed PIN_CHROME, so that seems like a valid solution.
yes please at this stage let us have the simplest solution that works.
This used to work till just a few days ago. If undeffing PIN_CHROME
undoes whatever change broke this, lets undef PIN_CHROME and move on.

thanks, Vishy

*** Bug 53758 has been marked as a duplicate of this bug. ***
Blocks: 53513
*** Bug 53898 has been marked as a duplicate of this bug. ***
This should probably be plussed, or double-plussed, or whatever ... 
This really needs to get fixed - is the PIN_CHROME solution acceptable and can
we do this for PR3?

Adding Phil to cc

I might take this for PR3 if we had a safe fix. I don't think I'd hold PR3 for
it. Syd, where do we stand?

beta3 will be terrible if this is not fixed.  this affects every aspect of the
product.  i have scrollbar grippys that don't appear when clicked, radio buttons
and checkboxes not appearing, buttons not appearing, or appearing wrong.  if
this isn't ++ed, nothing should be.  This makes AIM very hard to use, and prefs
almost impossible to use, as you can't see what your options are without blindly
clicking around for a checkbox or radio button.

I can't agree with your assessment of the severity. I use the product all day
every day, and this is annoying, but it doesn't keep me from using it. The other
crashing, data-losing, people-suing-us nsbeta3++ bugs are worse.

I second Kerz comments. It may not be obvious to users they need to "click 
blindly around" either. To these users this makes any options, for example, with 
checkboxes, unusable in their eyes.
gagan, its time for some comments from the imagelib group since this is your bug.
I dont think this should be assigned to Syd. thanks, Vishy

A good test case it to just move your cursor over toolbar images in Composer,
or use certain buttons like one of the 3 alignment buttons. Rollover images
are often missing. Why isn't this "++" yet?
According to the comment by pnunn on 2000-09-21, this should be fixed, but
it isn't, unless the Composer toolbar problems (and thus 53206) is not really
a dup and must be fixed separately.
back to pam then.
Assignee: syd → pnunn
Status: ASSIGNED → NEW
PDT nominating for rtm
Keywords: rtm
Updating QA contact
QA Contact: paw → tpreston
OK. 
When I figure out when, where to check in, I will.
-p
Status: NEW → ASSIGNED
adding self

gagan -- can you rtm+ this one?
*** Bug 54299 has been marked as a duplicate of this bug. ***
*** Bug 54302 has been marked as a duplicate of this bug. ***
*** Bug 54357 has been marked as a duplicate of this bug. ***
*** Bug 53413 has been marked as a duplicate of this bug. ***
*** Bug 53513 has been marked as a duplicate of this bug. ***
*** Bug 53087 has been marked as a duplicate of this bug. ***
*** Bug 52831 has been marked as a duplicate of this bug. ***
Pam--please attach a diff since PDT probably won't accept this fix without it
attached...
Whiteboard: [rtm+]
*** Bug 54326 has been marked as a duplicate of this bug. ***
Marking nsbeta3++ per explanation from Hangas that the patch merely turns off
experimental functionality.  Very low risk.  Has been running in two peoples'
trees for the past week with no problems.

Let's get this one in immediately.
Whiteboard: [rtm+] → [nsbeta3++][rtm+]
Will check in as soon as Commercial branch is open.

-p
Just checked in.
-p
Status: ASSIGNED → RESOLVED
Closed: 24 years ago
Resolution: --- → FIXED
When this bug is fixed, re-test bug 54326.
*** Bug 54509 has been marked as a duplicate of this bug. ***
*** Bug 52847 has been marked as a duplicate of this bug. ***
*** Bug 54032 has been marked as a duplicate of this bug. ***
was this checked into the trunk as well?
Not yet. ...sooon.
very soooon.
-p
I just checked this into the vanilla moz trunk.
-pn
Jason - is this looking ok for IM now?
This seems to be much better for us, my win32 feature test didn't show any
problems with chrome images.  Will talk to others in the group to verify.

Yeah this lookes fixed to me. Great work!!

Verified in Windows, Mac and Linux builds 2000-09-29-09-MN6
Status: RESOLVED → VERIFIED
*** Bug 53715 has been marked as a duplicate of this bug. ***
While this is much, much better than before, I still see occasional failures to
load, or buttons disappearing briefly when moused over.  This usually only seems
to happen the first time the button is moused over after loading the program.
It's not very noticeable, as it was before, however I have read external
commentary pointing out this issue as a bug.  These seems like something we
should polish before 6.5.  Thoughts?  
For things flickering the first time you click on them, see bug 49143.  I 
haven't seen images failing to load, although I just noticed that someone 
mentioned that problem in bug 53912, a dup of 49143.
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Creator:
Created:
Updated:
Size: