[GTK3] tooltip having transparent(alpha) style isn't painted correctly

VERIFIED FIXED in Firefox 47

Status

()

VERIFIED FIXED
3 years ago
2 years ago

People

(Reporter: euthanasia_waltz, Assigned: acomminos)

Tracking

({regression})

Trunk
mozilla49
Unspecified
Linux
regression
Points:
---
Dependency tree / graph

Firefox Tracking Flags

(firefox46 unaffected, firefox47+ fixed, firefox48+ fixed, firefox49 verified)

Details

Attachments

(7 attachments)

(Reporter)

Description

3 years ago
Tooltip with transparent style is normal at first time but it is gradually corrupted.
Following screenshots are taken on manjaro-linux-xfce.(gtk 3.18.8)
They can be reproduced on LinuxMint(gtk 3.10.8) also with having ~/.config/gtk-3.0/gtk.css.
e.g.
>.tooltip {
>  color: rgb(255,255,255);
>  background-color: rgba(64,64,64,0.5);
>}
(Reporter)

Comment 1

3 years ago
Created attachment 8732487 [details]
1st, Tooltip is appeared normally.
(Reporter)

Comment 2

3 years ago
Created attachment 8732488 [details]
2nd, Tooltip is appeared normally maybe fortunately.
(Reporter)

Comment 3

3 years ago
Created attachment 8732489 [details]
3rd, Background color is darker, something text("Help and Tutorials") is drawn like a ghost.
(Reporter)

Comment 4

3 years ago
Created attachment 8732490 [details]
4th, Background color is more darker, more text("Help and Tutorials" and "Get Involved") is drawn like ghosts double.
(Reporter)

Comment 5

3 years ago
Created attachment 8732491 [details]
5th, ...
(Reporter)

Comment 6

3 years ago
This broken tooltip is not appeared constantly. It becomes sometimes normal. It becomes as if being mixed with previous one. It becomes as if being mixed with another(not previous) one. ...

If there is no transparency,
e.g.
>.tooltip {
>  color: rgb(255,255,255);
>  background-color: rgb(64,64,64);
>}
this problem won't occur.

Updated

3 years ago
Blocks: 627699
Thanks for the nice clear bug report.
This happens with gfx.xrender.enabled;false but not with true.
Blocks: 1241832
Status: UNCONFIRMED → NEW
status-firefox46: --- → unaffected
status-firefox47: --- → affected
Ever confirmed: true
Keywords: regression
Created attachment 8739227 [details]
testcase 1

I can reproduce this as well on Ubuntu Linux 16.04 with gnome-shell and default Ambiance theme.

Testcase attached. For me, the tooltip border in the testcase is noticeably darker on the 1st hover (when it's nearly the same as the tooltip-background color) as compared to the 4th/5th hover (when it's nearly the same as the tooltip-text color).

And I can confirm karlt's report that this bug goes away if I set the pref gfx.xrender.enabled to true.
See Also: → bug 1262995
I suspect this is a graphics problem (even if the code may live in widget/gtk) with a surface not being initialized to clear for the paint, or operator over used instead of operator source somewhere.

[Tracking Requested - why for this release]:
Noticeable regression that can make tooltips hard to read.
tracking-firefox47: --- → ?
Component: Widget: Gtk → Graphics
Blocks: 1262995
See Also: bug 1262995
Assignee: nobody → andrew
(Assignee)

Comment 10

2 years ago
The issue here appears to be that we aren't properly clearing a reused SHM image in response to an expose event. Since we use X11 SHM unbuffered (with BufferMode::BUFFER_NONE), the basic layer manager draws directly to the SHM image using an arbitrary composition operator, unlike our XRender path which is buffered and draws to the window using the source operator (which is why this isn't occurring with XRender on). I'll look into why the layer manager isn't clearing unbuffered DTs properly.
Status: NEW → ASSIGNED
(Assignee)

Comment 11

2 years ago
Created attachment 8746182 [details]
MozReview Request: Bug 1258086 - Clear unbuffered SHM images with a 32-bit visual before drawing with the basic layer manager. r?lsalzman

Review commit: https://reviewboard.mozilla.org/r/49287/diff/#index_header
See other reviews: https://reviewboard.mozilla.org/r/49287/
Attachment #8746182 - Flags: review?(lsalzman)
(Assignee)

Comment 12

2 years ago
AFAICT, it's not the responsibility of the layer manager to ensure the surface it draws into is "clean"- this patch ensures that we explicitly clear unbuffered RGBA surfaces before drawing with basic layers in response to an expose. Otherwise, we don't care what composition operator is used.

Thanks!
Comment on attachment 8746182 [details]
MozReview Request: Bug 1258086 - Clear unbuffered SHM images with a 32-bit visual before drawing with the basic layer manager. r?lsalzman

https://reviewboard.mozilla.org/r/49287/#review46197

Seems like it should work.
Attachment #8746182 - Flags: review?(lsalzman) → review+

Comment 16

2 years ago
bugherder
https://hg.mozilla.org/mozilla-central/rev/0aa740ece69e
Status: ASSIGNED → RESOLVED
Last Resolved: 2 years ago
status-firefox49: --- → fixed
Resolution: --- → FIXED
Target Milestone: --- → mozilla49
Recent regression, tracking
Want to request uplift to 47?
tracking-firefox47: ? → +
Flags: needinfo?(andrew)
(Assignee)

Comment 18

2 years ago
Comment on attachment 8746182 [details]
MozReview Request: Bug 1258086 - Clear unbuffered SHM images with a 32-bit visual before drawing with the basic layer manager. r?lsalzman

Sure, sounds good.

Approval Request Comment
[Feature/regressing bug #]: Bug 1180942
[User impact if declined]: Tooltips will show artifacts after a redraw on Linux.
[Describe test coverage new/current, TreeHerder]: N/A
[Risks and why]: Small risk, merely clears a surface already expected to be clear before painting.
[String/UUID change made/needed]: N/A
Flags: needinfo?(andrew)
Attachment #8746182 - Flags: approval-mozilla-beta?
Attachment #8746182 - Flags: approval-mozilla-aurora?
status-firefox48: --- → affected
tracking-firefox48: --- → +
Hello Atlanto, could you please verify this issue is fixed as expected on a latest Nightly build? Thanks!
Flags: needinfo?(euthanasia_waltz)
Comment on attachment 8746182 [details]
MozReview Request: Bug 1258086 - Clear unbuffered SHM images with a 32-bit visual before drawing with the basic layer manager. r?lsalzman

Recent regression in Fx47, Aurora48+, Beta47+
Attachment #8746182 - Flags: approval-mozilla-beta?
Attachment #8746182 - Flags: approval-mozilla-beta+
Attachment #8746182 - Flags: approval-mozilla-aurora?
Attachment #8746182 - Flags: approval-mozilla-aurora+

Comment 21

2 years ago
bugherderuplift
https://hg.mozilla.org/releases/mozilla-aurora/rev/b059ea150b9e
status-firefox48: affected → fixed

Comment 22

2 years ago
bugherderuplift
https://hg.mozilla.org/releases/mozilla-beta/rev/3d7688da70b6
status-firefox47: affected → fixed
(Reporter)

Comment 23

2 years ago
Verified with latest nightly(build 20160506052037) on manjaro-linux(gtk3 3.20.3-1) and inuxmint(3.10.8~8+qiana).
It works very fine. Thanks.
Flags: needinfo?(euthanasia_waltz)
(Assignee)

Updated

2 years ago
Duplicate of this bug: 1262995
(In reply to atlanto from comment #23)
> Verified with latest nightly(build 20160506052037) on manjaro-linux(gtk3
> 3.20.3-1) and inuxmint(3.10.8~8+qiana).
> It works very fine. Thanks.

Great! Thank you for the verification.
Status: RESOLVED → VERIFIED
status-firefox49: fixed → verified
No longer blocks: 1263222
You need to log in before you can comment on or make changes to this bug.