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

Issue 877517 link

Starred by 4 users

Issue metadata

Status: Fixed
Owner:
Closed: Jan 18
Cc:
Components:
EstimatedDays: ----
NextAction: ----
OS: Linux , Windows , Chrome , Mac
Pri: 1
Type: Bug-Regression

Blocking:
issue 869919



Sign in to add a comment

Floating dialogs close on click release when they should persist for selections.

Project Member Reported by kbleicher@google.com, Aug 24

Issue description

Chrome Version: 70.0.3519.3 dev
OS: Chrome OS 10967.0.0

What steps will reproduce the problem?
(1) Go to Goldeneye (go/goldeneye)
(2) Click 'Releases' from the left pane
(3) Click in the Search box at the top to filter results

What is the expected result?
A dialog appears on click in the search box and persists to allow input.

What happens instead?
The dialog disappears at mouse click release.  It's only visible when the mouse button remains pressed.

Description:
Clicking in 'search boards' should display the dialog shown in the screen shot.  That dialog should persist with a click so options can be chosen.  Instead, I have to click and hold in that dialog for it to be displayed, which doesn't allow for making selections.

User feedback report:
https://listnr.corp.google.com/report/85617468279

URL: https://cros-goldeneye.corp.google.com/chromeos/console/listBoard
Product Version: 70.0.3519.3 dev
User Agent: Mozilla/5.0 (X11; CrOS x86_64 10967.0.0) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/70.0.3519.3 Safari/537.36
UI Language: en-US

Description:
Clicking in 'search boards' should display the dialog shown in the screen shot.  That dialog should persist with a click so options can be chosen.  Instead, I have to click and hold in that dialog for it to be displayed, which doesn't allow for making selections.

Product Specific Data (whitelisted):
        CHROME VERSION: 70.0.3519.3 dev
        CHROMEOS_ARC_STATUS: enabled
        CHROMEOS_AUSERVER: <URL: 2>
        CHROMEOS_RELEASE_BOARD: grunt
        CHROMEOS_RELEASE_DESCRIPTION: 10967.0.0 (Official Build) dev-channel grunt-unibuild (grunt careena aleena liara) test
        CHROMEOS_RELEASE_TRACK: dev-channel
        CHROMEOS_RELEASE_VERSION: 10967.0.0
        ENTERPRISE_ENROLLED: Managed
        cpu: AMD A6-9220C RADEON R5, 5 COMPUTE CORES 2C+3G

        expi:  3300119 3300132 3313324 3313338 3314461 3314480 3314518 3314570
        hardware_class: CAREENA A3B-A3F-C2F-M26-J6Q-A5C
        routes: [ ip -4 rule list ]
0:      from all lookup local
1:      from all lookup main
32766:  from all lookup main
32767:  from all lookup default

[ ip -4 route show table main ]
default via <IPv4: 16> dev wlan0 metric 1
<IPv4: 60>/22 dev wlan0 proto kernel scope link src <IPv4: 1>
<IPv4: 15>/30 dev arcbr0 proto kernel scope link src <IPv4: 10>
 
Cc: abodenha@chromium.org
Components: UI>Input Blink>Input Blink
Labels: -Pri-2 Pri-1
Owner: ----
abodenha@, can you advise on the best owner, or will the component triage process take care of that?  Thanks
No clue. This sounds like a blink issue. The best luck I've had with those is attaching the right component.
Components: -UI>Input -Blink Blink>CSS
Labels: -Type-Bug Needs-Bisect Type-Bug-Regression
On Mac 10.13.6. Able to repro on Chrome 70.0.3533.0. Confirmed regression as it does not repro on 67.0.3396.99. Requesting bisect.

The element in question is a fieldset, and it is not visible because its computed style display is none (it should be block judging by behavior in stable). Interestingly if you right click in the search box then the fieldset persists. More investigation required to figure out if this is an input issue or a style issue.
Components: -Blink>CSS
It's an onclick handler on body which triggers when clicking the input field which ends up calling showDialog(false). The body onclick handler does not seem to be triggered in Chrome 68.
Cc: gov...@chromium.org
Labels: OS-Mac
Appears to be platform; adding Mac per #4.
Cc: abdulsyed@chromium.org ligim...@chromium.org
Cc: nyerramilli@chromium.org
Labels: ReleaseBlock-Beta
Narayana, could you please someone from Inhouse for trying a bisect in Mac.
Labels: -Needs-Bisect hasbisect-per-revision RegressedIn-70 Target-70 FoundIn-70 OS-Linux OS-Windows
Owner: nzolghadr@chromium.org
Status: Assigned (was: Untriaged)
Able to reproduce the issue on Win 10, Mac & Linux using Canary 70.0.3534.4.

Broken in M70 and below is the bisect info:

Good Build: 70.0.3510.0 
Bad Build: 70.0.3512.0 

You are probably looking for a change made after 580553 (known good), but no later than 580554 (first known bad).

CHANGELOG URL:
https://chromium.googlesource.com/chromium/src/+log/0856d23e554086fb4f3a3391c48c86e1fa75efca..a48b88b4c702885da8eae04906f2f0f7fbe33744


suspect: https://chromium.googlesource.com/chromium/src/+/a48b88b4c702885da8eae04906f2f0f7fbe33744

nzolghadr@, could you please check the issue and help.


Note: Working fine in Stable 68.0.3440.106 & Beta 69.0.3497.57 on Win 10.
This was an intentional change to conform with the spec. Anyone knows who owns this page? Why do we call showDialog(false) on click handlers?
The weird behavior is that it opens the dialog on down event. 
Labels: new-click-targetting
Friendly ping to get an update as it is marked as RBB.
Thanks..!
Labels: -ReleaseBlock-Beta
I remove the RBB as the change was intentional and with the knowledge of the possibility of breaking some pages.
I filed internal bug 113899398 for Goldeneye
Cc: chrishtr@chromium.org josa...@chromium.org 877517kkaluri@chromium.org
 Issue 882010  has been merged into this issue.

Comment 16 by nzolghadr@google.com, Jan 18 (4 days ago)

Blocking: 869919
Status: Fixed (was: Assigned)
This issue is already fixed. 

Sign in to add a comment