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

Issue 785272 link

Starred by 1 user

Issue metadata

Status: Archived
Owner: ----
Closed: Nov 29
Cc:
Components:
EstimatedDays: ----
NextAction: ----
OS: ----
Pri: 3
Type: Bug



Sign in to add a comment

DCHECK in WinScreenKeyboardObserver::OnKeyboardVisible

Project Member Reported by ekaramad@chromium.org, Nov 15 2017

Issue description

Chrome Version: 64.0.3268.0 (Developer Build) (64-bit)
OS: Win10

(1) Navigate the browser to data:text/html, <input style="margin-top: 1000px;"/>
(2) Scroll down until the input is barely visible.
(3) Touch the input.

What is the expected result?
The virtual keyboard shows and input is scrolled up.

What happens instead?
DCHECK fires because |bounds_in_screen| covers part of keyboard (in my experiment with a browser window maximized vertically on a HD screen, the bounds bottom is at y = 768 while the keyboard is at y = 767. The keyboard in the experiment was maximized horizontally.
 
Description: Show this description
Running the same experiment and using Spy++ it appears that the rect for the content inside the tab should end at 766. So perhaps window_->GetBoundsInScreen() is not what we need here (assuming that it is returning the correct value?).
Project Member

Comment 3 by sheriffbot@chromium.org, Nov 15

Labels: Hotlist-Recharge-Cold
Status: Untriaged (was: Available)
This issue has been Available for over a year. If it's no longer important or seems unlikely to be fixed, please consider closing it out. If it is important, please re-triage the issue.

Sorry for the inconvenience if the bug really should have been left as Available.

For more details visit https://www.chromium.org/issue-tracking/autotriage - Your friendly Sheriffbot
Components: Blink>Input
Status: Archived (was: Untriaged)
This code has changed quite a bit and particularly we have migrated from using taptip to inputpane api. I don't see any DCHECK in that function either. Closing this for now as it doesn't seem to be reproducible. Reporter, if you happen to see this issue again that would be great to comment here or file a new issue with the new related information. Thanks.

Sign in to add a comment