622942 - Gmail's chat contact list layer is not opaque when scrolling on OS X

Status: RESOLVED FIXED

(Core :: Layout, defect)

Description

[Jeff Muizelaar [:jrmuizel]]

This shows up as bad looking text. The problem also shows up in list boxes.

Comment 1

[Joe Drew (not getting mail)]

Specifically, Jeff's claim is that since this is on a solid background, we should never have to have a transparent layer.

Comment 2

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

The chat box is not opaque, it has rounded corners doesn't it?

But all the text should be over opaque stuff so the layer should be RGBA with subpixel AA specifically enabled. Ah, I bet ThebesLayerOGL needs something like SetAntialiasingFlags from BasicLayers.cpp.

Comment 3

[Jeff Muizelaar [:jrmuizel]]

(In reply to comment #2)
> The chat box is not opaque, it has rounded corners doesn't it?

I meant the contact list, but it's true the chat box suffers from a similar problem.

Comment 4

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

I'm not sure why the contact list would even have its own layer. It's just part of the page. Isn't it?

Comment 5

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

By "the contact list" do you mean the things you get when you click on "Contacts"?

Comment 6

[Timothy Nikkel (:tnikkel)]

If you open up the chat box on the left hand side where it has your name and then a textbox with "Search, add, or invite" there is a list of contacts, if you have enough it is scrollable.

Comment 7

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

Ah. That box probably is transparent, but we should probably be able to make it opaque by pulling up the solid background color from underneath. I'd have to do some debugging I don't have time to do right now to figure out why that isn't happening.

In any case, the text would be fixed either by what I said in comment #2 (which definitely needs to be done anyway), or by component alpha for GL.

Comment 8

[Jeff Muizelaar [:jrmuizel]]

I also see this problem in the awesomebar dropdown. It would be nice if we didn't just paper over all of these cases taking the perf hit of doing component alpha.

Comment 9

[Jeff Muizelaar [:jrmuizel]]

It's also visible in text areas that scroll like on the following page:

data:text/html,<textarea cols=13 rows=10></textarea>

Comment 10

[Timothy Nikkel (:tnikkel)]

There is bug 606075 also, which was reported on mac. Is this problem mac specific? (I mean without component alpha.) Maybe the mac theme code is messing with the analysis?

Comment 11

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

(In reply to comment #9)
> It's also visible in text areas that scroll like on the following page:
> 
> data:text/html,<textarea cols=13 rows=10></textarea>

In general that has to be component alpha since we don't know what the platform theme will draw for the background of the <textarea>. If it draws some theme stuff under the text, then we can't fill the text layer with a uniform opaque background.

We could potentially code in some assumptions about the theme backgrounds for textareas (i.e. that they're transparent or a known solid color inside the border), and then hoist that solid color up into the background of the text layer.

I'm not sure what's up with the awesomebar dropdown. That is probably a different issue.

Comment 12

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

Someone with a Mac that supports GL-layers should address comment #2, then we'll have a clearer idea of what else should be done.

Comment 13

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

I guess I might be able to do it on my Linux box at home too.

Comment 14

[Jeff Muizelaar [:jrmuizel]]

(In reply to comment #11)
> In general that has to be component alpha since we don't know what the platform
> theme will draw for the background of the <textarea>. If it draws some theme
> stuff under the text, then we can't fill the text layer with a uniform opaque
> background.
> 
> We could potentially code in some assumptions about the theme backgrounds for
> textareas (i.e. that they're transparent or a known solid color inside the
> border), and then hoist that solid color up into the background of the text
> layer.

I think that's the correct thing to do on OS X.

Comment 15

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

Maybe a better option is to simply make the scrollable layer for textareas non-active so we repaint it all the time. Repainting textareas should hardly ever be expensive.

Comment 16

[(no longer active)]

Attachment: Patch (v1)

I couldn't reproduce the original problem, but this is what comment 2 was about, I think.  roc: is this any good?

Comment 17

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

Comment on attachment 514987 [details] [diff] [review]
Patch (v1)

Yes!

Comment 18

[(no longer active)]

So is this the only thing that I need to land as part of this bug?

Comment 19

[Marco Bonardo [:mak]]

This needed an unbitrot, please check everything is fine.
http://hg.mozilla.org/mozilla-central/rev/0ac8887f208a

Comment 20

[Bill Gianopoulos [:WG9s]]

This appears to have causes permaorange test failures:

s: talos-r3-fed-047
TEST-UNEXPECTED-FAIL | /home/cltbld/talos-slave/test/build/xpcshell/tests/toolkit/mozapps/extensions/test/xpcshell/test_bug619730.js | test failed (with xpcshell return code: 0), see following log:
TEST-UNEXPECTED-FAIL | /home/cltbld/talos-slave/test/build/xpcshell/tests/toolkit/mozapps/extensions/test/xpcshell/test_bug619730.js | null == GFX - See following stack:
TEST-UNEXPECTED-FAIL | /home/cltbld/talos-slave/test/build/xpcshell/tests/toolkit/mozapps/extensions/test/xpcshell-unpack/test_bug619730.js | test failed (with xpcshell return code: 0), see following log:
TEST-UNEXPECTED-FAIL | /home/cltbld/talos-slave/test/build/xpcshell/tests/toolkit/mozapps/extensions/test/xpcshell-unpack/test_bug619730.js | null == GFX - See following stack:

Comment 21

[Bill Gianopoulos [:WG9s]]

Unless the blacklist update somehow caused the orange.

Comment 22

[Joe Drew (not getting mail)]

Yep, the blacklist update caused those oranges (bug 637008).

Comment 23

[(no longer active)]

(In reply to comment #19)
> This needed an unbitrot, please check everything is fine.
> http://hg.mozilla.org/mozilla-central/rev/0ac8887f208a

Yes, everything is fine.  Thanks a lot for landing this!