Closed
Bug 382048
Opened 18 years ago
Closed 17 years ago
Mac native buttons draw to window when supposed to draw to offscreen surface
Categories
(Core :: Widget: Cocoa, defect, P5)
Tracking
()
RESOLVED
FIXED
mozilla1.9beta2
People
(Reporter: dbaron, Assigned: jtd)
References
Details
Attachments
(3 files, 1 obsolete file)
(deleted),
application/xhtml+xml
|
Details | |
(deleted),
image/png
|
Details | |
(deleted),
patch
|
jaas
:
review+
dbaron
:
superreview+
beltzner
:
approval1.9+
|
Details | Diff | Splinter Review |
Mac native theme buttons are drawn to the window when they are supposed to be drawn to an offscreen surface.
Steps to reproduce: load attached testcase
Expected results: button is drawn with opacity 0.2, at the same position as the text inside it (which is in the right place)
Actual results: button is drawn at full opacity, at the same position as the div with opacity that contains it
Note that if additional content is added to the div so that the button should appear at a different position, it ends up drawn at the origin of the div
Flags: blocking1.9?
Reporter | ||
Comment 1•18 years ago
|
||
Oops, attached the wrong testcase.
Attachment #266116 -
Attachment is obsolete: true
Assignee | ||
Comment 2•18 years ago
|
||
Related issues: 382048, 382049, 382050
Comment 3•18 years ago
|
||
I'm seeing something different now.
Actual results: Button is not drawn at all if the opacity is less than 1.
Assignee | ||
Comment 4•17 years ago
|
||
Probably same as 382049, swiping for now. Scream if you're dying to take this one...
Assignee: joshmoz → jdaggett
Assignee | ||
Comment 5•17 years ago
|
||
Is this the desired output? I wasn't sure from your comments whether this would be considered correct or not. Glancing at the HTML it appears to be right but just wanted to check.
Fixed by patch attached to 382049.
Comment 6•17 years ago
|
||
(In reply to comment #5)
> Created an attachment (id=274893) [details]
> correct behavior?
Yeah, that should be it.
Assignee | ||
Comment 7•17 years ago
|
||
Fixed in latest nightly build which includes fix for bug 382049:
Mozilla/5.0 (Macintosh; U; Intel Mac OS X; en-US; rv:1.9a8pre) Gecko/2007080804 Minefield/3.0a8pre
Status: NEW → RESOLVED
Closed: 17 years ago
Resolution: --- → FIXED
Reporter | ||
Comment 8•17 years ago
|
||
The tests in layout/reftests/native-theme/reftest.list that have this bug number are still marked as failing on PowerPC, so reopening.
If that should be split off into a different bug, please do so before closing this one.
If they're marked as failing on PowerPC but they actually pass, the reftest.list should be fixed.
Status: RESOLVED → REOPENED
Resolution: FIXED → ---
John - if you don't plan to investigate this on PPC we should figure out someone to reassign this to that can.
Assignee | ||
Comment 10•17 years ago
|
||
Attachment #286472 -
Flags: review?(joshmoz)
Comment 11•17 years ago
|
||
John - did you actually test on PPC?
Assignee | ||
Comment 12•17 years ago
|
||
Yup, I built and confirmed this on my PPC iMac at home. If you're seeing different behavior or the tests are failing, let me know. The two tests in question are pretty silly, there basically "does something show up?"
Reporter | ||
Comment 13•17 years ago
|
||
They show up as UNEXPECTED PASS for me as well (on PPC, 10.4).
Attachment #286472 -
Flags: review?(joshmoz) → review+
Attachment #286472 -
Flags: superreview?(dbaron)
Reporter | ||
Updated•17 years ago
|
Attachment #286472 -
Flags: superreview?(dbaron) → superreview+
Attachment #286472 -
Flags: approval1.9?
Comment 14•17 years ago
|
||
Comment on attachment 286472 [details] [diff] [review]
remove the reflist expected failures on PPC
a=drivers, though no such approvals are required for fixing/checking in test aiui
Attachment #286472 -
Flags: approval1.9? → approval1.9+
Comment 15•17 years ago
|
||
landed jdaggett's PPC unexpected pass patch
Status: REOPENED → RESOLVED
Closed: 17 years ago → 17 years ago
Resolution: --- → FIXED
You need to log in
before you can comment on or make changes to this bug.
Description
•