Issue metadata
Sign in to add a comment
|
Page turns out white blank when scroll moves fast (depends on frame tag)
Reported by
1000...@gmail.com,
Aug 7
|
||||||||||||||||||||||||
Issue descriptionUserAgent: Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/68.0.3440.84 Safari/537.36 Example URL: https://blogpeople.blog.me/221325078658 Steps to reproduce the problem: 1. Go any page that document has <frameset> tag. 2. Move scroll fast. 3. Turns out white blank, no contents displayed. What is the expected behavior? Show all contents clearly regardless of frame or frameset tag exists What went wrong? 1. It happens when document has <frameset> tag. 2. Only fast scroll make this situation (not other click or keyboard event). 3. Wrong only Chrome latest vesrion in Mac OS Does it occur on multiple sites: Yes Is it a problem with a plugin? No Did this work before? Yes 67.0.3396.99, and latest Chrome beta also works. Does this work in other browsers? Yes Chrome version: 68.0.3440.84 Channel: stable OS Version: 10.13.6 Flash Version:
,
Aug 8
Unable to reproduce the issue on reported chrome version 68.0.3440.84 using Mac 10.13.5. Attaching screen-cast for reference. Steps: --------- 1. Launched reported chrome 2. Navigated to given URL " https://blogpeople.blog.me/221325078658 " 3. Scrolled page faster as per screen-cast As we are not seen blank page. @Reporter: Please find the attached screen-cast and let us know if we have missed anything in the process. Request you to retry this issue with fresh profile without any extensions/apps or reset all the flags and let us know if issue still persists. Thanks.!
,
Aug 8
@phanindra.mandapaka@chromium.org Thank you for your comment. But it still happens without any extensions/apps. You can reproduce LATEST macOS High Sierra 10_13_6. I attached my version status. Please try again latest os version with latest Chrome stable.
,
Aug 8
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
,
Aug 8
For more information, I also attached my screen-cast. To make sure it is not cause of extension/apps, I used secret mode. When white blank shows and some click event fired, it turns normal.
,
Aug 8
Test folks: Could we try reproing with 10.13.6? 1000zzy: Could you attach your chrome://gpu, please? Assigning to Compositing, just in case.
,
Aug 8
@fs...@chromium.org Yes, I found only 10.13.6. Attached my gpu results in this comment. And I can give you bunch of other gpu cases. If you need, please let me know. I have very big trouble because of this unexpected user experiences. I look forward to your positive reply. Thank you.
,
Aug 9
Tested this issue Unable to reproduce on reported chrome 68.0.3440.84 using Mac 10.13.6 High Sierra.Hence removing Needs-Bisect label. Attaching chrome://gpu details to it. CC'ing fserb@chromium.org for further inputs on it. @fserb@chromium.org: Requesting you to please have a look in it.Attaching screen-cast for reference. Thanks..!
,
Aug 9
,
Aug 9
It is too sad that it can not reproduce. :( But me and my friends case, their always reproduce. Unlike yesterday, I found latest Chrome version is changed. But my problem is never resolves. Also realized that the scroll event not have to be fast. Scorll make happens without speed. I gathered some of gpu results. They are all diffrent computers. (besides, I can give you more) Espacially case 3 that I attached, it shows same issue despite of OS version is different. The only common thing of these cases are using latest Chrome. It will be grateful any tips you can suggest me to resolve this. Thank you for your support.
,
Aug 9
I can reproduce this. It only happens on the initial load, and resizing the window causes it to paint again. Reloading brings up the page fine. This is in Chrome 68.0.3440.75 on Mac 10.13.6 (Mid 2012 MacBook) I'll try bisecting, but I'm not hopeful.
,
Aug 9
Bisect is failing. Whatever this is, it only occurs under very specific circumstances. Given that subsequent releases are reported to resolve the problem, and resizing the window or reloading resolves the problem, we are not likely to spend resources trying to fix the underlying cause. Could you please confirm my finding that the problem does not recur on reload and that resizing the window also fixes the issue? Could you tell us which version you found to be working correctly?
,
Aug 10
@schenney So thankful that you can reproduced it! I am unfamilier of Chromium, therefore I couldn't understand what "Bisect" means at first. But finally I found "bisect-builds-py", and tested it my self. I found the point that turn into bug and also fixed. (revision numbers) error START : 561592 -> 561629 Log : https://chromium.googlesource.com/chromium/src/+log/96986fc8452fca738796bd1b914b59bd134e8792..189566cde90c8b255de5c315a919a80a0e627cc4 error FIXED : 563957 -> 563958 https://chromium.googlesource.com/chromium/src/+log/8fd698baad2716d78d3d4cc25fdd7694fa3c2422..07a1071502f4699d445d0b7f46f3ca27d10efef0 I am a developer for the URL that I attached before. And it is one of biggest service in South Korea. I want most of my users using service without any barriers in Chrome. I hope this log result will help solve the problem. P.S My answer of your questions are all YES.
,
Aug 10
Maybe I can wait until latest version applied in stable, but it needs time too long :( I want a more hopeful answer... Thanks!
,
Aug 10
2nd P.S Small tip for reproduce; I can always seen the white page after first tap opened. When try to load next tab, you can reproduce what I said. (after that, bug situation continues)
,
Aug 10
Can you try Chrome Canary and see if the issue still exists there?
,
Aug 10
There nothing in the blame list that jumps out, but the fix revision seems plausible for sure. I've commented on the code review for that to see if it's really a plausible candidate and if it's mergable.
,
Aug 10
I bisected to the same error start / end revisions in bug 870404 , and the symptom sounds very similar.
,
Aug 10
Looking at that I would say it's a duplicate. Marking it so.
,
Aug 12
I tested all types of releases. Canary: Issue not exists. Dev: Issue not exists. Beta: Issue not exists. Stable: Issue "still" exists. The web service that attached by URL is for not only developer but also all kinds of user. Most of our users are not known about experimental Chrome browser is exist. Until the bug fixed code adapted in the stable version, they face the problem without knowing why. I would appreciate your consideration. Thanks. |
|||||||||||||||||||||||||
►
Sign in to add a comment |
|||||||||||||||||||||||||
Comment 1 by viswa.karala@chromium.org
, Aug 7