1239106 - [GTK] Native-themed buttons with near-0 opacity are now being displayed at full opacity

Status: RESOLVED DUPLICATE of bug 1239040

(Core :: Graphics, defect)

Description

[Daniel Holbert [:dholbert]]

Attachment: testcase 1: button with extremely-small opacity

STR:
 1. View attached testcase.

ACTUAL RESULTS:
Button is visible (though its contents are not).

EXPECTED RESULTS:
Button should not be visible at all.


The button's source looks like this:
 <button style="opacity: 0.001">INVISIBLE</button>

This is a recent regression:
https://hg.mozilla.org/integration/mozilla-inbound/pushloghtml?fromchange=36c1e4eb0c9141aae4071a917ce4e3a59f5a79c6&tochange=d74084d072f0b5dfb00e3fbc103bef0a3fecbf85
--> regression from bug 1220629.

This causes a visual glitch on GitHub's "attach files" UI. I'll attach a screenshot of that next.

Comment 1

[Daniel Holbert [:dholbert]]

I'm using Nightly 46.0a1 (2016-01-12) on 64-bit Ubuntu Linux.

ni=Bas to investigate, since he was the assignee of bug 1220629.

Comment 2

[Daniel Holbert [:dholbert]]

Attachment: screenshot of rendering glitch at GitHub

Here's a screenshot of this bug causing a problem in the comment field at the following GitHub page (and probably every github page with a comment field):
 https://github.com/JasonBarnabe/stylish/issues/266

There's an <input type="file"> control, which involves a button, and the button is rendered at full opacity due to this bug.

Comment 3

[Daniel Holbert [:dholbert]]

One more data point: if I add "-moz-appearance: none" to the button's style, then this bug goes away. So, this only seems to be a problem with native-themed buttons.

Comment 4

[Daniel Holbert [:dholbert]]

Looks like this doesn't reproduce on Mac, either. (mccr8 just tested mac nightly for me.)

So it looks like this is specifically a problem with *GTK* themed buttons. --> CC'ing karlt.
(Maybe regressing-bug 1220629 makes assumptions about how native widgets are drawn, and our GTK widget code does not satisfy those assumptions?)

Comment 5

[Lee Salzman [:lsalzman]]

I have a fix for this as part of bug 1239040. There were some bugs in BorrowedXlibDrawable with respect to PushLayers in DrawTargetCairo.

Comment 6

[Lee Salzman [:lsalzman]]

Attachment: fix DrawTargetCairo LockBits to fail inside PushLayer

This fixes DrawTargetCairo LockBits and BorrowedXlibDrawable to fail gracefully inside of PushLayer instead of silently breaking with undefined behavior.

Comment 7

[Jeff Muizelaar [:jrmuizel]]

(In reply to Lee Salzman [:lsalzman] from comment #6)
> Created attachment 8707306 [details] [diff] [review]
> fix DrawTargetCairo LockBits to fail inside PushLayer
> 
> This fixes DrawTargetCairo LockBits and BorrowedXlibDrawable to fail
> gracefully inside of PushLayer instead of silently breaking with undefined
> behavior.

Why can't LockBits succeed when we have pushed layers?

Comment 8

[Lee Salzman [:lsalzman]]

(In reply to Jeff Muizelaar [:jrmuizel] from comment #7)
> (In reply to Lee Salzman [:lsalzman] from comment #6)
> > Created attachment 8707306 [details] [diff] [review]
> > fix DrawTargetCairo LockBits to fail inside PushLayer
> > 
> > This fixes DrawTargetCairo LockBits and BorrowedXlibDrawable to fail
> > gracefully inside of PushLayer instead of silently breaking with undefined
> > behavior.
> 
> Why can't LockBits succeed when we have pushed layers?

DrawTargetCairo::mSurface refers to the top-level surface, so you need to make it refer to the group target. Second, you need to also take account of the device offset, which requires the extension to LockBits to support returning an origin which I made in the PushLayers patch.