Attaching trace of when this happens in the Chromium issue wizard.

Deleted: trace_trace.json.gz 1.1 MB

trace_trace.json.gz 1.1 MB Download

Unable to reproduce the issue on chrome reported version 66.0.3359.181 using Windows-10 with steps mentioned below:
1) Launched chrome reported version and navigated to URL: https://www.niagaracruises.com/checkout/
2) Tried to fill the form, able to enter the text and able to select the option from the dropdown without any issues

@Reporter: Please find the attached screencast for your reference, try to test this issue by creating new person with no apps and extensions in it and let us know if the issue still persists.

Thanks!

Deleted: 844887.mp4 5.1 MB

	844887.mp4 5.1 MB View Download

Clicking on the country field is triggering the bug for me sometimes. It happens even in Incognito mode, so I don't think it's a user or extensions problem. I tried reinstalling the Intel Graphics Driver and Chrome but it didn't work.

Thank you for providing more feedback. Adding the requester to the cc list.

For more details visit https://www.chromium.org/issue-tracking/autotriage - Your friendly Sheriffbot

Re-checked the issue on reported chrome version 66.0.3359.181 using Windows-10 with the exact steps mentioned in comment#0(...comment#3) As we are unable to see any blank screen up on clicking text fields or dropdown menu, hence adding label "TE-NeedsTriageHelp" and requesting some one from Dev team to have a look into this and help in further triaging it.
Note: Tentatively adding component "Blink>Forms" please change if this isn't apt.

Thanks!

Sounds like a GPU handling issue?

Original submitter: Can you post the contents of your about:gpu here as an attachment?

Without a repro, it is unlikely that we can do anything about this, but that might help.

I'm reproducing this on M69 with Windows 7.  I've seen this on just about every dropdown list as well.  If I turn HW Acceleration OFF then the bug doesn't reproduce.  I didn't see this in M68, so it's something that changed in M69.

For easy reproducible step:

Go here:  https://jobs.protingent.com/
Click on STATE/PROVINCE dropdown and the dropdown UI will turn solid black; however I can still use the keyboard cursor keys to select an option in the dropdown.  

I've seen this on multiple sites now and it's especially annoying. I've had to disable HW acceleration for the time being.

Here are my launch switches:  

69.0.3497.81 (Official Build) (64-bit) (cohort: 69_win_81)
Revision	032b3ca19e9af20182f9bd03deefc0faf4695558-refs/branch-heads/3497@{#869}
OS	Windows
JavaScript	V8 6.9.427.19
Flash	30.0.0.154 C:\Users\Administrator\AppData\Local\Google\Chrome\User Data\PepperFlash\30.0.0.154\pepflashplayer.dll
User Agent	Mozilla/5.0 (Windows NT 6.1; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/69.0.3497.81 Safari/537.36
Command Line	"C:\Program Files (x86)\Google\Chrome\Application\chrome.exe" --enable-native-gpu-memory-buffers --flag-switches-begin --enable-zero-copy --ignore-gpu-blacklist --enable-features=WebRTC-H264WithOpenH264FFmpeg --flag-switches-end

If you need any more details then please let me know.  

PS.  I use a Nvidia GTX1080 with latest retail drivers as my GPU.

Please upgrade to P1 as this issue is highly visible and needs to be addressed ASAP.

About:GPU Attached.

Thank you for providing more feedback. Adding the requester to the cc list.

For more details visit https://www.chromium.org/issue-tracking/autotriage - Your friendly Sheriffbot

Re-attaching About:GPU here. 

Deleted: About GPU.txt 12.1 KB

About GPU.txt 12.1 KB View Download

I've attached my GPU info as well.

Deleted: gpu39907.txt 9.8 KB

gpu39907.txt 9.8 KB View Download

zmo: Do we need to blacklist some driver here? Assigning to you for Windows graphics triage/investigation.

I'm using Nvidia and the bug writer is using Intel.  It's not a driver issue.  This is a Chrome bug.  I tried recording the screen but the extensions I used don't record the bug properly.

Okay, so I downloaded the latest dev release.  The issue didn't reproduce.  I then added my chrome switches and it failed.  If I remove the chrome switch "--enable-zero-copy" then the issue DOES NOT REPRODUCE.  

So it looks like zero copy tile update mode is broken.  One copy mode works fine.

Victor, Eric, any recommendation who should take a look at this zero-copy rasterization bug?

I am skeptical that this is a zero copy bug, despite comment #17.  The reason is that looking where that code is used, we only use it in the renderer, and gpu rasterization (Rasterization: Hardware accelerated, in both of those gpu infos) takes priority over the zero copy code.

See: https://cs.chromium.org/chromium/src/cc/trees/layer_tree_host_impl.cc?sq=package:chromium&q=layertreehostimpl&g=0&l=3044

UI also uses zero copy, but it's a separate --enable-ui-zero-copy flag.

Does this bug repro 100% of the time with zero copy and 0% of the time without zero copy?  How many times did you try with each?  Sorry for what seem like silly questions, but I am quite confused here.


zmo: we don't have anybody who is a "zero copy" expert anymore. reveman would have been it, but he isn't around any more.  This code hasn't changed in a very long time in the renderer and is used on Mac as well.  If anything, it is likely the case that some underlying GpuMemoryBuffer code on Windows has a synchronization issue in gpu code.

FYI, I just upgraded to the newest release build today (69.0.3497.92 (Official Build) (64-bit) (cohort: 69_win_92)) and after enabling zero-copy again, this issue doesn't reproduce.

I enabled zero-copy on the other dev build and it still reproduces.  

RE: #19, Yes it reproduces 100%.  

Looks like this issue was addressed in another bug: 
 https://bugs.chromium.org/p/chromium/issues/detail?id=881303

per #20, assigning to sunnyps@ to close this.

#20 by earlier dev build you mean a version older than 69, or dev channel version 71?

By default there's no real zero-copy on Windows.  The only "gpu memory buffers" that work on Windows are backed by shared memory, and uploaded to textures in the GPU process.

When you pass --enable-native-gpu-memory-buffers you're enabling DXGI handle backed buffers in the renderer, but these don't implement Map() so the renderer will most likely crash with nullptr dereference if it tries to use it.

What might be happening is that we switch from GPU raster to zero copy when you click on a form (msaa slow content maybe?).  And then the renderer crashes.  It's not clear how a crash in Chrome could cause your entire screen to go blank.  Maybe just creating the GMB triggers a driver bug?  Who knows?

Anyway this isn't a code path we support even for testing.  If you really want to use zero copy, you should be able to do it without --enable-native-gpu-memory-buffers.  Zero copy will most likely not give you any performance benefit over one copy since it only defers the texture upload.