339598 - using opacity on <input type="text"> causes border not to be drawn

Status: RESOLVED FIXED

(Core :: Graphics, defect)

Description

[Lee Houghton]

User-Agent:       Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9a1) Gecko/20060528 Minefield/3.0a1
Build Identifier: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9a1) Gecko/20060528 Minefield/3.0a1 ID:2006052804 [cairo]

When styling an <input type="text"> with the opacity property, the border is not drawn.

http://onfiar.com/~asztal/bugs/input-opacity.htm

When the border is explicitly specified, it is then drawn (see second text box in above page).

Reproducible: Always

Steps to Reproduce:
1. Open the URL for this bug
2. Observe borderless text box

Actual Results:  
The text field's border is not visible.

Expected Results:  
The text field's border is visible.

Comment 1

[Ria Klaassen (not reading all bugmail)]

Yes this is a cairo problem indeed.

Comment 2

[Martijn Wargers (dead)]

The url is not there anymore. Could you make it available again? Preferably, could you attach the testcase to the bug?

Comment 3

[Lee Houghton]

Attachment: Garish testcase

My apologies.

Comment 4

[Lee Houghton]

Ok, I can see a border now in the attached testcase. It looks like this has been fixed somehow. I guess that this may have been fixed by bug 340452, or maybe bug 340517.

Comment 5

[Martijn Wargers (dead)]

Attachment: testcase

Not fixed for me, using 20061029 trunk build. I can still not see a border on this input, that has an opacity of 0.7.

Comment 6

[Vladimir Vukicevic [:vlad] [:vladv] (needinfo me, slow to respond)]

Attachment: another testcase

Another testcase; there's something going on with native widgets and the text inside them specifically.  I think we may be going through a different text rendering path in this case, but it needs to be tracked down some more.

Comment 8

[Peter Simonyi]

Summary of Bug 362118: 
opacity is inherited so setting BODY {opacity: .99;} caused this border problem for all form controls on the page.  Also, scroll bars (overflow: auto;) are affected as well.

Comment 9

[Ryan VanderMeulen [:RyanVM]]

Attachment: Testcase from bug 362118

Comment 10

[Vladimir Vukicevic [:vlad] [:vladv] (needinfo me, slow to respond)]

Attachment: patch for win32 native theme rendering, v0

Ok, here we go.

Here's a patch for this, though it introduces some undesirable behaviour (see next attachment for screenshot).  However, it does fix rendering windows native theme widgets with opacity, and also allows windows native widgets to be reproduced in PDF output (in theory, since as of now noone but stuart can actually test it :).

But, I don't want to go with this patch, because I want to fix the issue in the next screenshot attachment.

Comment 11

[Vladimir Vukicevic [:vlad] [:vladv] (needinfo me, slow to respond)]

Attachment: problem with patch

So here's the problem with this patch.  Win32 can draw most native theme elements with a transform, provided that only scaling is involved.  What it does is just scale up the rectangle and renders as normal; it doesn't attempt to actually scale up the rendering (that is, button corners are still the exact same size in pixels at 10x scale as they are at 1x scale).

This patch has it render the non-scaled-size rectangle, and then transforms the result.  The problem is that widgets start to look ugly when scaled up, even though in some ways this is more "correct".  Rotated widgets start to work, though they're still ugly.

The real solution is to compute the scaling factors of the transformation matrix, render the widget scaled up but still axis-aligned, and then rotate that.  That's coming up.

Comment 12

[Robert O'Callahan (:roc) (email my personal email if necessary)]

Is it really simpler to manage this state machine rather than use a callback?

Comment 13

[Vladimir Vukicevic [:vlad] [:vladv] (needinfo me, slow to respond)]

Attachment: patch for win32 native theme rendering, v1

Ok, updated version with all the scale factor goodness.  We'll need to do some testing to get the right values for the flags per widget type, especially if it's different between classic and non-classic.

As for the state machine, I think that it's simpler -- it requires less modification of calling code, and isn't all that complicated in any case.  That is, the extra complexity is in the native drawing code, as opposed to requiring that all users pull out their drawing code into separate functions (and figure out how to get the right variables and all that there)...

Comment 14

[Vladimir Vukicevic [:vlad] [:vladv] (needinfo me, slow to respond)]

Attachment: patch for win32 native theme rendering, v1.1

Previous patch was missing a line, causing widgets to not be drawn in the right place in some cases.

Comment 15

[Vladimir Vukicevic [:vlad] [:vladv] (needinfo me, slow to respond)]

Attachment: patch for win32 native theme rendering, v1.2

Now nsRect and old-style-NSToCoordRound-free!

Comment 16

[Vladimir Vukicevic [:vlad] [:vladv] (needinfo me, slow to respond)]

Attachment: patch for win32 native theme rendering, v1.3

Attached wrong file

Comment 17

[Stuart Parmenter]

Comment on attachment 256966 [details] [diff] [review]
patch for win32 native theme rendering, v1.3

can you please add some comments to your new gfxMatrix functions?

please make the internal and external enums all be CAPS?

add some comments on the ownership of the HDC handed back from BeginNativeDrawing?  What is its lifetime?

in gfxAlphaRecoveryResult  instead of using alpha, r, g, b use a gfxRGBA struct?

in _compute_alpha_values maybe pass in a gfxIntSize instead of int width, int height?

in these spots:
 mWorldTransform.eM12 = 0.0;
is a FLOAT a float or double?  do you want 0.0f there?  does it matter?

Comment 18

[Vladimir Vukicevic [:vlad] [:vladv] (needinfo me, slow to respond)]

Attachment: 256966: patch for win32 native theme rendering, v1.4

Updated with review comments.

Comment 19

[Stuart Parmenter]

Comment on attachment 257072 [details] [diff] [review]
256966: patch for win32 native theme rendering, v1.4

r=me with the enum changes we talked about on irc

Comment 20

[Vladimir Vukicevic [:vlad] [:vladv] (needinfo me, slow to respond)]

Fix checked in.

Comment 21

[Dainis Jonitis]

Vladimir, you forgot to add bug number in the comment when you checked in the code to CVS. Without that it is hard in Bonsai to see relation between file changes and actual bug.

Comment 22

[Eli Friedman]

>+    /**
>+     * Returns true if the matrix has any transform other
>+     * than a translation or scale; this is, if there is
>+     * no rotation.
>+     */
>+    bool HasNonAxisAlignedTransform() const {
>+        return ((xy != 0.0) || (yx != 0.0));
>+    }

I think you meant "any rotation".