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

Status: RESOLVED FIXED

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

Description

[David Baron :dbaron: (⌚️UTC-4, no longer working on Mozilla)]

Attachment: testcase

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

Comment 1

[David Baron :dbaron: (⌚️UTC-4, no longer working on Mozilla)]

Attachment: testcase

Oops, attached the wrong testcase.

Comment 2

[John Daggett (:jtd)]

Related issues: 382048, 382049, 382050

Comment 3

[Colin Barrett [:cbarrett]]

I'm seeing something different now.

Actual results: Button is not drawn at all if the opacity is less than 1.

Comment 4

[John Daggett (:jtd)]

Probably same as 382049, swiping for now.  Scream if you're dying to take this one...

Comment 5

[John Daggett (:jtd)]

Attachment: 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.

Comment 6

[philippe (part-time)]

(In reply to comment #5)
> Created an attachment (id=274893) [details]
> correct behavior?

Yeah, that should be it.

Comment 7

[John Daggett (:jtd)]

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

Comment 8

[David Baron :dbaron: (⌚️UTC-4, no longer working on Mozilla)]

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.

Comment 9

[Josh Aas]

John - if you don't plan to investigate this on PPC we should figure out someone to reassign this to that can.

Comment 10

[John Daggett (:jtd)]

Attachment: remove the reflist expected failures on PPC

Comment 11

[Josh Aas]

John - did you actually test on PPC?

Comment 12

[John Daggett (:jtd)]

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?"

Comment 13

[David Baron :dbaron: (⌚️UTC-4, no longer working on Mozilla)]

They show up as UNEXPECTED PASS for me as well (on PPC, 10.4).

Comment 14

[Mike Beltzner [:beltzner, not reading bugmail]]

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

Comment 15

[Josh Aas]

landed jdaggett's PPC unexpected pass patch