Closed Bug 34801 Opened 25 years ago Closed 25 years ago

[REGRSSION]Image buttons don't paint all the way.

Categories

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

x86
Windows NT
defect

Tracking

()

VERIFIED FIXED

People

(Reporter: rods, Assigned: pnunn)

Details

Attachments

(2 files)

When look at a simple select test case, the button isn't painted all the when it comes in. This has been broken for a week or two.
In the testcase the arrow for the drop down doesn't draw completely. This use to work about two weeks ago.
Kevin: Bill: I'm not sure who should deal with this one. Widgets? context? I'll reassign to Kevin and cc: Bill -P
Assignee: pnunn → kmcclusk
Pamm, This isn't Kevin's bug. I own all the form controls, I assigned it to you and copied don becuase you and don have been making changes to the image stuff and this stopped working recently. There haven't been any changes in the GfxButton or HTMLButton that would affect the painting of the images. Or another way to put this is the image part of the button paints half way and stops. This is more than likely a notification issue, like once the image has completely come in it isn't being notified th last time to paint the entire image that is in the button. I am reassigning this to to you because if I thought I could make a fix to the form controls to get this working I would.
Assignee: kmcclusk → pnunn
Maybe this is don's bug, because it is a background image. If you look in the html.css the css for the dropdown button is: select > input[type="button"] { user-focus: none; position: static !important; white-space:nowrap; border: outset 2px rgb(204, 204, 204); background-image:url("arrow.gif"); background-repeat:no-repeat; background-position:center; width:12px; height:12px; -moz-border-radius:0px; } I will do some further checking to make sure it isn't the button frame.
Here is something interesting: It doesn't paint all the way when the viewer statrs up, but if you refload the page by hitting return in the url bar it loads and draws correctly. In mozilla, if you bring up the "Font" prefs panel they don't paint all the way the first time. But the second time you bring them up they do. Does this have anything to do with caching? Wouldn't the image code being going down two different paths. The first patha it is loading and waits for the rntire disk image to come in. The second code path should be different since the image should be in the cache because it has already been loaded once.
hmmm. If I force a repaint by obscuring the window with another app's window, the image is there. I'm interpreting the "non painting" of the image for the downarrow is that it is displaying a dash, rather than painting halfway. but it could be either. Do you know how we could use another image that is less ambiguous in the paint? -P
Status: NEW → ASSIGNED
ok. Forcing a repaint works...and the repaint does not cause the image to be retrieved from cache or redecoded. Putting a breakpoint where the imglib looks for an image in the cache is not hit when the image is displayed after a repaint. And when the image displays half way, I hit break point at image_complete(). The image lib has finished decoding the image. And doesn't try to redecode or get it from the cache after a repaint displays the whole image. I'll follow some of the higher level messages, but the decoding is working properly. -P -P
In the last week I did remove some frame_complete notifications that Troy and I both thought were extraneous. ...maybe they weren't. I'll try backing out one or two of those changes and retest. -P
I may have found it. -P
Target Milestone: --- → M15
checked in. -P
Status: ASSIGNED → RESOLVED
Closed: 25 years ago
Resolution: --- → FIXED
The "minuses", or downarrow dash (broken arrows?) on prefs dropdown boxes is newer than one week? They vanished at the same time the content of the dropdown boxes vanished (no fonts display). Commented on in bug 34635. But after checkin of the fix for this one (34801), the arrows now *do* initially display when you open prefs, but they *vanish* when you click on them! [Linux, nightly build ID 2000-040616]
They don't disappear when you click on them on NT. -p
I just checked this change on linux, and the arrow doesn't disappear when I click on it. The text in the drop down list does disappear and the drop down list box stays up. This looks wrong to me...but is a different bug. -P
Checked again in nightly build ID 2000-040708 - still vanish when i click. Bugzilla won't accept attachment but have it snapshot. The dropdown box also steals all focus but THAT's probably another bug.
pnunn: mailed as per request. Arrived?
yes. Image arrived. Much thanks. Have not had time to ponder. -p
Ponder no more. The arrows are back in 2000041309 :)
I love bugs that heal themselves. :) -p
Oops..ponder a *little* more: The bug was and is gone in M16. But it persists in M15. Tested on 2000041505 (The remaining part of bug being the one i sent attachment of - "boxed" buttons with no arrow after click.) Should it have a separate bug?
M15 is history. Worry about M16. -p
Works for Me Platform: PC OS: Windows 98 Mozilla Version: 2000100508 Marking as Verified
Status: RESOLVED → VERIFIED
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Creator:
Created:
Updated:
Size: