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)
Tracking
()
VERIFIED
FIXED
M15
People
(Reporter: rods, Assigned: pnunn)
Details
Attachments
(2 files)
(deleted),
text/html
|
Details | |
(deleted),
patch
|
Details | Diff | Splinter Review |
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.
Reporter | ||
Comment 1•25 years ago
|
||
Reporter | ||
Comment 2•25 years ago
|
||
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
Reporter | ||
Comment 4•25 years ago
|
||
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
Reporter | ||
Comment 5•25 years ago
|
||
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.
Reporter | ||
Comment 6•25 years ago
|
||
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
Assignee | ||
Comment 10•25 years ago
|
||
I may have found it.
-P
Assignee | ||
Comment 11•25 years ago
|
||
Assignee | ||
Comment 12•25 years ago
|
||
checked in.
-P
Status: ASSIGNED → RESOLVED
Closed: 25 years ago
Resolution: --- → FIXED
Comment 13•25 years ago
|
||
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]
Assignee | ||
Comment 14•25 years ago
|
||
They don't disappear when you click on them on NT.
-p
Assignee | ||
Comment 15•25 years ago
|
||
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
Comment 16•25 years ago
|
||
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.
Comment 17•25 years ago
|
||
pnunn: mailed as per request. Arrived?
Assignee | ||
Comment 18•25 years ago
|
||
yes. Image arrived. Much thanks.
Have not had time to ponder.
-p
Comment 19•25 years ago
|
||
Ponder no more. The arrows are back in 2000041309 :)
Assignee | ||
Comment 20•25 years ago
|
||
I love bugs that heal themselves.
:)
-p
Comment 21•25 years ago
|
||
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?
Assignee | ||
Comment 22•25 years ago
|
||
M15 is history.
Worry about M16.
-p
Comment 23•24 years ago
|
||
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.
Description
•