376576 - many Aqua form widgets don't print as Aqua

Status: VERIFIED WORKSFORME

(Core :: Widget: Cocoa, defect)

Description

[Smokey Ardisson (offline for a while; not following bugs - do not email)]

Attachment: subset of attachment 99911

Bug 177953 was resolved with the claim that all form widgets print as Aqua widgets on the trunk now.

Sam and I took a look at this (he on Intel 10.4 and me on 10.3.9), and found that of the form widgets that currently do draw as Aqua, 

1) buttons revert to gfx, and 

2) single-line text fields have a very heavy beveled gfx look (instead of the light, barely noticeable shadow they have on-screen).  

The text fields on branch were pretty inconsistent; sometimes they printed with the light shadow, and sometimes with the heavy one, for reasons I can't fathom; depending on which subset of the text fields I used for my testcase, a different text field had the light shadow....  On trunk, I can never get any of the fields to print using the light shadow.

Comment 1

[Smokey Ardisson (offline for a while; not following bugs - do not email)]

Attachment: Testcase printed to PDF on branch

(This one is mainly to show that the "Normal Textfield" does use a lighter shadow on branch; input buttons of course didn't print)

Comment 2

[Smokey Ardisson (offline for a while; not following bugs - do not email)]

Attachment: Testcase printed to PDF on trunk

Observe the Aqua input buttons becoming gfx ugliness....

Comment 3

[Smokey Ardisson (offline for a while; not following bugs - do not email)]

Attachment: Testcase as rendered in the browser on branch

(Again, just to show both text fields have the light shadow)

Comment 4

[Smokey Ardisson (offline for a while; not following bugs - do not email)]

Attachment: Testcase as rendered in the browser on trunk

Comment 5

[Josh Aas]

I think this is because we have wacky fallback rules in the first place and the CSS for "@media print" triggers fallback in different places than the normal display CSS. We really need to look over what we're doing for print CSS.

Comment 6

[Josh Aas]

I also wouldn't be surprised if the same layout bug responsible for bug 375436 is responsible for this.

Comment 7

[Stan Shebs]

This bug seems to have gone away on its own in the past couple of days, last night's nightly prints widgets correctly for instance. I had traced it down to some general confusion between CSS pixels and device pixels, so not too surprising that an unrelated fix could resolve.

Comment 8

[Colin Barrett [:cbarrett]]

Looks fixed to me as well.