search

anmar7889 / chromiumembedded

Automatically exported from code.google.com/p/chromiumembedded
0 stars 1 forks source link

Text fails to paint in some cases with large negative margin & positive padding #1452

Closed GoogleCodeExporter closed 9 years ago

GoogleCodeExporter commented 9 years ago 
Note: this bug occurs in cefclient 3.2171.1902 but *not* in a similar version 
of Chrome, 39.0.2171.65.

What steps will reproduce the problem?
1. Download & unzip this code: 
https://files.acrobat.com/a/preview/e4344683-3149-4c1c-b59d-ff70fd2e2026
2. Start a local web server pointed to that folder, and load index.html in 
cefclient
3. If the "src" folder is visible in the sidebar at left, click it

Result:
Initially, the tree view at left shows "samples" but the labels for the two 
folders below it ("src" and "test") are missing. As soon as you mouse over the 
tree area, the other two labels appear.

When you click the "src" folder, all the folders shown underneath it also have 
no label. This time, mousing over the tree doesn't help. If you switch focus to 
a different app, most of the missing text appears, but as soon as you 
reactivate the cefclient window the text disappears again.

If you open developer tools on the cefclient content and select one of the 
elements with missing text, you'll see its bounds are correctly highlighted 
where the text *should* be.  If you add `color: red` directly to the element 
using dev tools, the text becomes visible, and if you remove the `color: red`, 
it stays visible! -- This strongly implies this is a repainting bug, not a 
layout issue.

Expected:
Item text is consistently painted, as it is in Chrome browser.

OS: Windows 7

Removing the padding and margin from `.jstree-brackets li > a` causes the bug 
to go away. These styles use a combination of a large negative margin plus 
equally large positive padding. This makes me wonder if the bug is some sort of 
clipping miscalculation...

Removing the `webkit-filter` from `.jstree-brackets .jstree-no-dots 
.jstree-open > ins` and `.jstree-brackets .jstree-no-dots .jstree-closed > ins` 
significantly changes the bug: the text is briefly invisible, but always 
repaints a moment later. It never seems to stay persistently missing.

Original issue reported on code.google.com by ytp...@gmail.com on 24 Nov 2014 at 7:55

GoogleCodeExporter commented 9 years ago 
Here's a further simplified repro case: 
https://files.acrobat.com/a/preview/89e94f00-f292-4176-90cb-df1dff3c2021

One other observation: adding `box-shadow: none;` to `.jstree-brackets li > a` 
also changes the bug behavior: after expanding 'src', if you mouse out of the 
tree area then most of the text becomes visible (similar to the appearance if 
you blur the window, in the original steps). Again, none of this changes 
anything about the behavior in Chrome, though.

Original comment by ytp...@gmail.com on 24 Nov 2014 at 11:20

GoogleCodeExporter commented 9 years ago 
Attaching screenshots that illustrate the bug

Original comment by ytp...@gmail.com on 24 Nov 2014 at 11:21

Attachments:

GoogleCodeExporter commented 9 years ago 
2171 branch is currently at Chromium version 39.0.2171.36. This may be fixed 
once that branch updates to 39.0.2171.65 or newer.

Original comment by magreenb...@gmail.com on 24 Nov 2014 at 11:24

GoogleCodeExporter commented 9 years ago 
That seems possible - although nothing in the changelog 
(https://chromium.googlesource.com/chromium/src/+log/39.0.2171.36..39.0.2171.65?
pretty=fuller&n=10000) jumped out as an obvious fix. There's one clipping fix 
(https://code.google.com/p/chromium/issues/detail?id=427467) but it's very 
specific to solid color backgrounds. Didn't see any changes with text rendering 
that looked related either... Guess we'll just have to wait and see :-)

Original comment by ytp...@gmail.com on 25 Nov 2014 at 8:35

GoogleCodeExporter commented 9 years ago 
@#3: The Chromium version was updated to 39.0.2171.65 in revision 1932. Builds 
should be available on http://cefbuilds.com/ soon.

Original comment by magreenb...@gmail.com on 25 Nov 2014 at 8:43

GoogleCodeExporter commented 9 years ago 
@#5: Judging by http://cefbuilds.com/, it looks like only the Mac & Linux 
builds were updated. Windows is still showing as 39.0.2171.36...

Original comment by ytp...@gmail.com on 2 Dec 2014 at 5:24

GoogleCodeExporter commented 9 years ago 
Confirmed this is no longer an issue with CEF Test App 3.2171.1949 for Windows 
32, downloaded from http://cefbuilds.com.

Original comment by MGerbe...@gmail.com on 6 Dec 2014 at 10:25

GoogleCodeExporter commented 9 years ago 
Confirmed here too -- although I can still reproduce this in the older 
cefclient 3.2171.1902, I cannot repro in cefclient 3.2171.1949.  So I think 
this can be closed as fixed.

Original comment by ytp...@gmail.com on 9 Dec 2014 at 1:42

GoogleCodeExporter commented 9 years ago 
Thanks for the update.

Original comment by magreenb...@gmail.com on 9 Dec 2014 at 1:09