New issue
Advanced search Search tips
Note: Color blocks (like or ) mean that a user may not be available. Tooltip shows the reason.

Issue 875018 link

Starred by 2 users

Issue metadata

Status: Assigned
Owner:
Cc:
Components:
EstimatedDays: ----
NextAction: ----
OS: Linux , Windows
Pri: 1
Type: Bug-Regression



Sign in to add a comment

Rendering problem in web application

Reported by trevor.a...@gmail.com, Aug 16

Issue description

Chrome version: Version 68.0.3440.106 (Official Build) (64-bit)

URLs (if applicable) : No public URL.  I do have a repro sample (see below).

Other browsers tested:
  Add OK or FAIL, along with the version, after other browsers where you have tested this issue:
     Safari: 
    Firefox: OK (Firefox Quantum 61.0.2 (64-bit))
       Edge: OK (Microsoft Edge 40.15063.674.0, Microsoft EdgeHTML 15.15063)

What steps will reproduce the problem?

(1) Unzip the attached Chromium render bug.zip file into a folder that is served by a web server (e.g. somewhere under C:\inetpub\wwwroot). (Note: A web server is needed to make ajax requests)
(2) Navigate to the index.html file in Chrome.
(3) Wait for data to appear in the grid
(4) Click the Search button with the mouse

What is the expected result?
Grid should show a subset of data (6 rows)

What happens instead?
(1) Grid appear blank under the column headers
(2) Slowly mouse down into the blank grid area. Results will suddenly render

Note: While it is usually reproducible, if it doesn’t reproduce the first time, try refreshing the browser while leaving the mouse hovered over where the Search button appears. You’ll need to refresh the browser in between each repro attempt; clicking Search repeatedly without refreshing the browser won’t reproduce the problem.  It's even more reproducible in our real application, as opposed to the attached sample application. In the sample application, I reproduced this on a laptop with a resolution of 1600x900, with the Chrome browser maximized (bookmarks bar is visible).

Please provide any additional information below. Attach a screenshot if possible.

The sample repro application, contained in Chromium render bug.zip, is based on our real enterprise app, which is built on the Sencha ExtJS framework.  The sample application was built by using the original HTML captured from our application’s DOM, along with the original CSS/resouces & a little bit of javascript code which leverages the Sencha grid.  I stripped out some extraneous HTML; the ExtJS framework itself adds a lot of html content in the DOM, some of which will be visible in the sample application.  I originally tried to reproduce the bug without any javascript, but I was unsucessful (my guess it is timing related).

Through a process of elimination, within my real application (not the attached Chromium render bug.zip), I discovered that applying border-radius styling to a grid element triggers a bug in Chrome.  By trying the various archived Chromium builds, I was able to determine that the rendering problem didn't occur in chromium 511560 but started appearing in the next archived version (511590).  Next, I used git bisect on the Chromiums source code and I was able to determine the problem was introduced here:

eeaf4c2326de12c9b36324a805e46ab933057e54 is the first bad commit commit eeaf4c2326de12c9b36324a805e46ab933057e54 Author: sunxd <sunxd@chromium.org> Date: Wed Oct 25 20:52:18 2017 +0000   cc: Enable mask tiling   This CL enables the mask tiling flag in layer_tree_settings.   Bug:  567293  Cq-Include-Trybots: master.tryserver.blink:linux_trusty_blink_rel Change-Id: Ia86c95ca11af2bdafdd6214f9736f4c09592299f Reviewed-on: https://chromium-review.googlesource.com/735751 Commit-Queue: Xianda Sun <sunxd@chromium.org> Reviewed-by: enne <enne@chromium.org> Reviewed-by: Chris Harrelson <chrishtr@chromium.org> Cr-Commit-Position: refs/heads/master@{#511579} 

That commit had this change:

bool enable_mask_tiling = true; 

in cc/trees/layer_tree_settings.h.  I then changed the enable_mask_tiling to false (otherwise keeping the code the same), rebuilt the Chromium code, and then the problem in our application disappeared.

I tried the latest Chromium build 70.0.3525.0 (Developer Build) (64-bit)/ b85f3ffc2ddbd70a838418fa202d2e1b33420221-refs/heads/master@ {#583742}.  The bug is still reproducible in that build.

Please see attached screenshots:
1. before clicking search.PNG
2. after clicking search.PNG
3. after mousing down over previously blank grid

 
1. before clicking search.PNG
83.3 KB View Download
2. after clicking search.PNG
27.0 KB View Download
3. after mousing down over previously blank grid.PNG
44.5 KB View Download
Chromium render bug.zip
3.5 MB Download
Labels: Needs-Triage-M68
Cc: viswa.karala@chromium.org
Labels: Needs-Bisect Triaged-ET OS-Linux OS-Windows
Status: Untriaged (was: Unconfirmed)
Able to reproduce the issue on chrome reported version# 68.0.3440.106 and on latest chrome# 70.0.3528.0 using Windows-10 and Ubuntu 14.04 with steps mentioned in comment# 0. But the issue is not seen on M-60(60.0.3112.0), hence marking this issue as Untriaged and adding Needs-Bisect label to it, will update the bisect information soon.
Note: Issue is not seen on MacBook Air 10.12.6 and MacBook Pro 10.13.3.

Thanks!
Components: Internals>Compositing
Labels: -Type-Bug -Pri-3 -Needs-Bisect hasbisect-per-revision RegressedIn-64 Target-69 Target-70 M-70 FoundIn-70 Target-68 FoundIn-68 FoundIn-69 Pri-1 Type-Bug-Regression
Owner: sunxd@chromium.org
Status: Assigned (was: Untriaged)
Able to reproduce the issue on reported version 68.0.3440.106 and latest chrome 70.0.3530.0 using Ubuntu 14.04 and Windows-10, hence providing Bisect Info
Note: Issue is not seen on Mac 10.12.6
Bisect Info:
================
Good build: 64.0.3249.0  
Bad build: 64.0.3250.0

You are probably looking for a change made after 511578 (known good), but no later than 511579 (first known bad).
https://chromium.googlesource.com/chromium/src/+log/8c7e87211aa02c337795f9260705c47d8a277e5b..eeaf4c2326de12c9b36324a805e46ab933057e54
Change-Id: Ia86c95ca11af2bdafdd6214f9736f4c09592299f
Reviewed-on: https://chromium-review.googlesource.com/735751

@sunxd: Please confirm the issue and help in re-assigning if it is not related to your change.

Thanks!
It seems that the damage is not computed correctly when search button is clicked, will investigate.
Cc: trchen@chromium.org
If I enable paint flashing or layer borders in devtools, it can be rendered correctly.

Hi trchen@, do you have any suggestions where I should look into?
Cc: chrishtr@chromium.org
I recall seeing chrishtr@ investigating a similar bug (non-stacking-context scroller with border radius and composited descendants) last week.
Probably not related. The scroller in this bug is a stacking context.

By the way I hit this DCHECK if I enabled layer borders in devtools:
[1:8:0904/145005.611641:FATAL:render_surface_impl.cc(625)] Check failed: (((temp_color) >> 24) & 0xFF) == solid (100 vs. �)
Not sure if related.
Seems to be premature activation. The mask layer in question does not have any drawable tiles at draw time. It generated a checkerboard quad instead: https://cs.chromium.org/chromium/src/cc/layers/picture_layer_impl.cc?rcl=bcb00131cddcbb3022b118f8351418f291ec4e1d&l=528
Anything I can do (as an outsider to chromium's internals) to help move this along?

I have a workaround in my application that involves not applying border radius. The problem with this bug from my perspective is that it's not easy to discover (as web developer) if a regression in the application occurs.  Working on a team of web developers, it's easy to for someone to introduce some styling that causes the problem to recur.  I know border radius triggers the problem, but I'm not sure if there are other triggers.  Furthermore, because of the nature of the problem, it's not something I can test for with any automated tests.
@sunxd, any ideas?

One thing you can try is to force complete damage and see if that fixes the bug.
Sure I'll try it.

Sign in to add a comment