Closed Bug 382048 Opened 14 years ago Closed 14 years ago

Mac native buttons draw to window when supposed to draw to offscreen surface

Categories

(Core :: Widget: Cocoa, defect, P5)

PowerPC
macOS
defect

Tracking

()

RESOLVED FIXED
mozilla1.9beta2

People

(Reporter: dbaron, Assigned: jtd)

References

Details

Attachments

(3 files, 1 obsolete file)

Attached file testcase (obsolete) —
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?
Attached file testcase
Oops, attached the wrong testcase.
Attachment #266116 - Attachment is obsolete: true
Flags: blocking1.9? → blocking1.9+
Related issues: 382048, 382049, 382050
I'm seeing something different now.

Actual results: Button is not drawn at all if the opacity is less than 1.
Probably same as 382049, swiping for now.  Scream if you're dying to take this one...
Assignee: joshmoz → jdaggett
Attached image correct behavior?
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.
(In reply to comment #5)
> Created an attachment (id=274893) [details]
> correct behavior?

Yeah, that should be it.

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: 14 years ago
Resolution: --- → FIXED
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 → ---
Target Milestone: --- → mozilla1.9 M10
John - if you don't plan to investigate this on PPC we should figure out someone to reassign this to that can.
Attachment #286472 - Flags: review?(joshmoz)
John - did you actually test on PPC?
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?"
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)
Attachment #286472 - Flags: superreview?(dbaron) → superreview+
Attachment #286472 - Flags: approval1.9?
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+
Priority: -- → P2
Priority: P2 → P5
landed jdaggett's PPC unexpected pass patch
Status: REOPENED → RESOLVED
Closed: 14 years ago14 years ago
Resolution: --- → FIXED
You need to log in before you can comment on or make changes to this bug.