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

Issue 761144 link

Starred by 1 user

Issue metadata

Status: Fixed
Owner:
Last visit > 30 days ago
Closed: Sep 2017
Cc:
Components:
EstimatedDays: ----
NextAction: ----
OS: Linux
Pri: 2
Type: Bug



Sign in to add a comment

File upload dialog unresponsive on Linux / Chome / Scratch.

Project Member Reported by adobefla...@gmail.com, Aug 31 2017

Issue description

FAIL: Ubuntu 64/Chrome 56/24.0.0.121
FAIL: Ubuntu 64/Chrome 56/23.0.0.10
PASS: Ubuntu 64/FF/24.0.0.123

The scratch editor (written in flash) has a button to upload files from your local disk. Upon clicking this button, the file browser opens but it is totally unresponsive to mouse clicks. Keyboard input does work OK.

What steps will reproduce the problem?
1. Go to https://scratch.mit.edu/projects/editor/ the bottom
2. At the bottom left there is a button where you can upload a new backdrop - it's like an open folder with an arrow coming up out of it. Click it.

Actual Result:
File browser opens but it's totally unresponsive to mouse clicks.

Expected Result:
File browser opens and can be used with the mouse.

Any Workarounds:
Use Firefox.

This Chromium change seems to be the injection point:
https://chromium.googlesource.com/chromium/src/+/df7f78e35f95dfae098dd6197b012e0506f68e0f
 
Cc: joone....@intel.com e...@chromium.org thomasanderson@chromium.org
Components: Internals>PlatformIntegration Internals>Plugins>Flash
Labels: -Pri-3 OS-Linux Pri-2
Owner: timbrown@chromium.org
Status: Assigned (was: Untriaged)
Hey Tim/ Tom,

Could you take a look at this?  This appears to be a Linux specific issue and appears to readily reproduce (at least for my own local tests), locking up the entire UI.

Thanks in advance.
Status: Started (was: Assigned)
I can reproduce it too. Looking into it more now...
Issue is that the mouse has been captured. By disabling event listening, the mouse is never released - presumably it is normally released after the dialog is shown.

The one line fix is simply to release the capture immediately before we disable event listening.
Project Member

Comment 4 by bugdroid1@chromium.org, Sep 20 2017

The following revision refers to this bug:
  https://chromium.googlesource.com/chromium/src.git/+/ee78727e1b88b5cd3310fc09f5be55c853ac8e37

commit ee78727e1b88b5cd3310fc09f5be55c853ac8e37
Author: Tim Brown <timbrown@chromium.org>
Date: Wed Sep 20 17:41:15 2017

Linux: Ungrab pointer when showing dialog

In some instances, such as when the dialog is shown from the flash
plugin, the mouse is captured before we disable event listening. This
causes the mouse to never be released, but the window which has captured
the mouse doesn't receive events until the dialog is closed using the
keyboard.

Bug:  761144 
Test: Follow reproduction steps in  crbug.com/761144 
Change-Id: Ia046fa484072027d508ebb1a13669ce0ce379edd
Reviewed-on: https://chromium-review.googlesource.com/674326
Reviewed-by: Elliot Glaysher <erg@chromium.org>
Reviewed-by: Thomas Anderson <thomasanderson@chromium.org>
Commit-Queue: Tim Brown <timbrown@chromium.org>
Cr-Commit-Position: refs/heads/master@{#503191}
[modify] https://crrev.com/ee78727e1b88b5cd3310fc09f5be55c853ac8e37/chrome/browser/ui/libgtkui/select_file_dialog_impl_gtk.cc

Status: Fixed (was: Started)

Comment 6 by hdodda@chromium.org, Sep 21 2017

Cc: hdodda@chromium.org
Labels: TE-Verified-M63 TE-Verified-63.0.3221.0
Verified the issue on ubuntu 14.04 using chrome M63 #63.0.3221.0 and issue seems to be fixed.

Followed the steps mentioned in comment #0 and file browser opens and can be used.

Attached screencast for reference.

Adding TE-verified labels.

Thanks!
761144.ogv
1.3 MB View Download

Sign in to add a comment