Closed Bug 622942 Opened 9 years ago Closed 9 years ago
Gmail's chat contact list layer is not opaque when scrolling on OS X
This shows up as bad looking text. The problem also shows up in list boxes.
Specifically, Jeff's claim is that since this is on a solid background, we should never have to have a transparent layer.
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.
blocking2.0: --- → ?
(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.
I'm not sure why the contact list would even have its own layer. It's just part of the page. Isn't it?
By "the contact list" do you mean the things you get when you click on "Contacts"?
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.
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.
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.
It's also visible in text areas that scroll like on the following page: data:text/html,<textarea cols=13 rows=10></textarea>
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?
(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.
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.
I guess I might be able to do it on my Linux box at home too.
blocking2.0: ? → final+
(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.
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.
I couldn't reproduce the original problem, but this is what comment 2 was about, I think. roc: is this any good?
Assignee: nobody → ehsan
Status: NEW → ASSIGNED
Attachment #514987 - Flags: review?(roc)
Comment on attachment 514987 [details] [diff] [review] Patch (v1) Yes!
So is this the only thing that I need to land as part of this bug?
This needed an unbitrot, please check everything is fine. http://hg.mozilla.org/mozilla-central/rev/0ac8887f208a
Status: ASSIGNED → RESOLVED
Closed: 9 years ago
Resolution: --- → FIXED
Target Milestone: --- → mozilla2.0b12
Target Milestone: mozilla2.0b12 → mozilla2.0
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:
Unless the blacklist update somehow caused the orange.
Yep, the blacklist update caused those oranges (bug 637008).
(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!
You need to log in before you can comment on or make changes to this bug.