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

Issue 284690 link

Starred by 16 users

Issue metadata

Status: Verified
Owner:
OOO until 2019-01-02
Closed: Oct 2013
Cc:
Components:
EstimatedDays: ----
NextAction: ----
OS: Chrome
Pri: 1
Type: Bug-Regression

Blocking:
issue 123444



Sign in to add a comment

Unable to open File.app after closing it once when delegated renderer is enabled

Project Member Reported by abod...@chromium.org, Sep 3 2013

Issue description

Google Chrome	31.0.1620.0 (Official Build 220870) dev
Platform	4636.0.0 (Official Build) dev-channel 
Please specify Cr-* of the system to which this bug/feature applies (add
the label below).

Steps To Reproduce:
Press Shift+Alt+M  or click on File.app 


Expected Result:
Should open File.app.

Actual Result:
File.app window not opened. 

How frequently does this problem reproduce? (Always, sometimes, hard to
reproduce?)
sometimes.
What is the impact to the user, and is there a workaround? If so, what is
it?

Please provide any additional information below. Attach a screen shot or
log if possible.
after reboots device, I can able to open File.app
drive-internals logs will be in next comment.

 
Cc: kinaba@chromium.org hirono@chromium.org
Labels: -Pri-2 Pri-1 ReleaseBlock-Beta Iteration-89
Owner: satorux@chromium.org
Status: Assigned
CC'ing several folks. Not sure who should take an issue like this?
Status: WontFix
Working for me. Please re-open if issue persists on newer build.

Google Chrome	31.0.1620.0 (Official Build 220870) canary
Platform	4636.0.0 (Official Build) canary-channel link
Status: Untriaged
Still device in error state. If want look I will drop at your desk.
Labels: -ReleaseBlock-Beta
Anything in the console?
Labels: ReleaseBlock-Stable
Status: Assigned
Interesting. I just hit it after downloading a file and trying to launch it. I cannot get anything to open to check the console.
After some more testing, it appears that we get into trouble once we try and download a file. Once that is invoked, Files.app/Ctrl+O/Ctrl+S stop working. You must restart.

@satorux - I think you were touching this code more recently, right?

Google Chrome	31.0.1620.0 (Official Build 220870) canary
Platform	4636.0.0 (Official Build) canary-channel link
Summary: Unable to open File.app after downloading a file (was: Unable to open File.app)
Cc: satorux@chromium.org
Owner: yoshiki@chromium.org
Yoshiki, could you take a look? I think it's unlikely that my recent changes in the file task selection business broke this, but I may be wrong...
Cc: hidehiko@chromium.org
+hidehiko who has been touching the volume manager stuff
Labels: -ReleaseBlock-Stable ReleaseBlock-Beta
Not sure we want to release a Beta with this bug. I'm finding that I hit it a lot in my normal workflow.
Josh, how often do you hit this issue?
I tried some times, but it looked much difficult to reproduce to me...

Also, if you have some procedure, could you share it with us?
Especially, I'm interested in how to download the file. Alt+click > save as > select file name (on Files.app dialog)? Or some clicking triggers downloading automatically?
Anything else?

I'm also interested in if Files.app has been opened when downloading, and new (or current) window stuck? Or Files.app is closed during the download, and when you tried to open a new Files.app then it stuck? Do you have any extra procedure?

Memo: I once experienced this in the following steps, but no luck to reproduce it twice using the same steps:

1. Add a new account and login
2. Go chrome:settings -> "Change..." the "Downloads" directory to a subdirectory under Google Drive (Google Drive/__debug__) in the Files.app dialog [it opened and worked well.]
3. Press ctrl-F5.
4. "Screenshot taken" popup shows up. Click it
5. Files.app is expected to show up, but it doesn't. Clicking launcher icon is also no-op.

chrome:inspect for Files.app background page was broken in that state. (Inspector window opens, and some frames are drawn, but it doesn't render any text or menu or buttons; almost blank.)
I hit the situation after I did the steps in c#13. As same as c#13, I could't open the inspector of the background page (it was almost blank).

I started chrome:tracing, and I saw "ThrottledCompositor" continued working in despite of no visible Files.app window (see the attached screenshot: PID 17837 is the Files.app process). No JavaScript code run. I think the compositor might be in wrong state.

After stopping the process of the Files.app from TaskManager, it went back to normal state: Files.app can be launched without any issue.
Screenshot 2013-09-05 at 07.32.21.png
42.3 KB View Download
Cc: piman@chromium.org
+piman (who can possibly help triage this compositor issue?)

@piman - Background: Files.app suddenly stops working. See c#14 for our latest theory.
Cc: briander...@chromium.org
Cc: danakj@chromium.org
@yoshiki, can you capture a trace with the "cc.debug.scheduler" category selected and post the trace file? That'll give us a good idea if the compositor is in a funny state. 

ThrottledCompositor toggling indicates that we are drawing and swapping frames to the screen, but I wonder if we aren't accepting any new commits and get stuck drawing an old commit over and over.

Is this with impl-side-painting enabled? If so, it's also possible we are not activating the pending tree when needed.
Labels: Iteration-90
Status: Fixed
I'm no longer observing this. Please re-open if I've missed it somehow. I've tried to repro several times tonight without any luck.


Google Chrome	31.0.1625.2 (Official Build 221970) canary
Platform	4661.0.0 (Official Build) canary-channel stumpy
Still reproduced with below steps on Lumpy and link devices.
1.Download any image from images.google.com
2.Try to open File.app. 

Google Chrome	31.0.1626.0 (Official Build 222150) dev
Platform	4665.0.0 (Official Build) dev-channel
Status: Assigned
@abodeti:

a) What is your default download destination?
b) Does it repro on other downloaded files, say go to Google.com, right click on image, and click Save as?
Answers
a) What is your default download destination?- /Downloads folder
b) Does it repro on other downloaded files, say go to Google.com, right click on image, and click Save as?- yes, reproduced 
OK, thanks. Back to @yoshiki.
@abodeti: could you capture and post the trace asked in #18?
Google Chrome	31.0.1628.0 (Official Build 222659) dev
Platform	4679.0.0 (Official Build) dev-channel 

File manager window goes white or blank page after save or download file to /Downloads. there is not much workaround.  device needs to reboot open file manager.file manager can be broken again when save,copy, download. 
should mark this issue ReleaseBlock-Dev? 
Summary: Unable to open File.app after closing it once (was: Unable to open File.app after downloading a file)
I'm now seeing this quite easily (so is @kanliu). 

1) Open Files.app
2) Close it
3) Try to open Files.app <-- no op


Google Chrome	31.0.1626.3 (Official Build 222261) canary
Platform	4671.0.0 (Official Build) canary-channel stumpy
Can someone who can reproduce this bug attach a trace of the failure?

1) Open Files.app
2) Close it
3) Type "chrome://tracing" into an address bar.
4) Hit "record" on the top left.
5) Make sure "cc.debug.scheduler" is selected on the right.
6) Hit "record" on the bottom.
7) Try to open Files.app
8) Hit "Stop tracing".

Try to execute steps 6-7 pretty quickly.
Cc: patricia@chromium.org josa...@chromium.org mtomasz@chromium.org
Zel and I just got a repro with new information!

1) Open Files.app
2) Open Ctrl+O
3) Close Files.app
4) Close Ctrl+0
5) Try to open Files.app <-- no op

Interestingly, if you look in the Task Manager after Step #4, you will see a Files.app background page lingering around. If you kill that, Files.app works again. It seems like we are not off-loading that background page, which is preventing new instances of Files.app from loading. This seems limited to Ctrl+O and Ctrl+S. 

CC'ing more folks in TOK so someone can jump on this if @yoshiki doesn't have the cycles.

@patricia/@josafat - I think we should keep this ReleaseBlock-Beta and release note it - i.e. explain how you can go to Task Manager and "End process" for Files.app to get back to a good state.
josh@, bincheng@, abodeti@, could you please try the logging step of #28? That'd help a lot.
(We in TOK are trying to reproduce the bug but unfortunately we're seeing it only quite rarely...)

Comment 31 Deleted

My link has a issue on about:tracing. the page with "cc.debug.scheduler" option is not there. 
Screenshot 2013-09-12 at 17.14.25 - Display 1.png
857 KB View Download
 Issue 289601  has been merged into this issue.
Chrome Version: 31.0.1629.0 (offical build 222938)dev
Chrome OS Version: 4684.0.0 dev-channel
https://storage.cloud.google.com/?arg=chromiumos-test-logs/cros_284690#chromiumos-test-logs%2Fcros_284690
Cc: yoshiki@chromium.org mbollu@chromium.org ligim...@chromium.org
 Issue 285734  has been merged into this issue.
We should add a regression test, which should be easy. I can help in case of problems.
Looks like this bug is in the M-31 dev channel. As of today, 3 Googlers have reported it already on chromeos-discuss@.
Repro'ed locally once: one notable thing caught my eye in cc.debug.scheduler trace was the
"SchedulerStateMachine (Did Not Finish)" item. (I wish I could save and upload the trace, but
I couldn't save because Files.app is stuck ;p)

Selected slice:
Title	
"SchedulerStateMachine"
Category	
"disabled-by-default-cc.debug.scheduler"
Start	
"3403.831 ms"
Duration	
"9050.702 ms"
Args	
 state	
{major_state: {commit_state: "COMMIT_STATE_WAITING_FOR_FIRST_DRAW",
               forced_redraw_state: "FORCED_REDRAW_STATE_IDLE",
               next_action: "ACTION_DRAW_AND_SWAP_IF_POSSIBLE",
               output_surface_state_: "OUTPUT_SURFACE_ACTIVE",
               readback_state: "READBACK_STATE_IDLE",
               texture_state_: "LAYER_TEXTURE_STATE_ACQUIRED_BY_IMPL_THREAD"},
 major_timestamps_in_ms: {0_interval: 16.716,
                          1_now_to_deadline: 3.77,
                          2_frame_time_to_now: 12.946,
                          3_frame_time_to_deadline: 16.716,
                          4_now: 4904834.987,
                          5_frame_time: 4904822.041,
                          6_deadline: 4904838.757},
 minor_state: {active_tree_needs_first_draw_: true,
               can_draw: true,
               can_start: true,
               commit_count: 4065,
               consecutive_failed_draws: 0,
               current_frame_number: 10031,
               did_create_and_initialize_first_output_surface: true,
               draw_if_possible_failed: false,
               has_pending_tree: false,
               inside_begin_frame: true,
               last_frame_number_swap_performed_: 10030,
               last_frame_number_where_begin_frame_sent_to_main_thread: 10030,
               last_frame_number_where_update_visible_tiles_was_called: -1,
               main_thread_needs_layer_textures: false,
               needs_commit: false,
               needs_manage_tiles: false,
               needs_redraw: true,
               pending_tree_is_ready_for_activation_: false,
               swap_used_incomplete_tile: false,
               visible: true}}
Uhm, #38 might have been a fake. Second time I didn't see it
It'll be quicker to try bisection. Started:

4610: good
4625: bad
4636: bad (the original report #0)
GOOD: 4615.0.0 / 31.0.1615.0 (Official Build 220256) canary link / Blink 537.46 (@156861)
BAD: 4625.0.0 / 31.0.1617.1 (Official Build 220719) canary link

No more releases in this range.
Bisection pointed out http://crrev.com/220638:
@piman, @danakj:
Do you have any idea on what's going on here? Comment #34 is the about:tracing log.

> commit f357c0411e0983dc8d0152d834467f75112072e2
> Author: piman@chromium.org <piman@chromium.org@0039d316-1c4b-4281-b951-d872f2087c98>
> Date:   Fri Aug 30 20:25:54 2013 +0000
>     Force delegated renderer on Aura
>     BUG= 123444 
>     Review URL: https://chromiumcodereview.appspot.com/22797008

As far as I tested manually, indeed the bug is observed only after this point.
(Test steps: repeat pressing alt-shift-M, ctrl-W, alt-shift-M, ctrl-W, ... for every second.
On buggy versions, Files.app stops appearing after a while.)

Those who have reproducing environment:
Could you try disabling "--delegated-renderer" in about:flags and check if it resolves the issue?

Comment 43 by piman@chromium.org, Sep 19 2013

delegated renderer has been disabled on trunk.


What logic makes it that the window doesn't show? Delegated renderer changes things on the renderer side, but shouldn't affect what the UI layers do.
As far as I observed by task manager (sorry I haven't conducted deeper investigation yet),
at the buggy state, the background page of the app is failing to shutdown cleanly.

That prevents the app to reuse or relaunch the background page that listens onLaunched event and show a window.
Summary: Unable to open File.app after closing it once when delegated renderer is enabled (was: Unable to open File.app after closing it once)
> delegated renderer has been disabled on trunk.
Today's canary is having the flag disabled, and Files.app started working fine for me.

How is the schedule for re-enabling the flag? If it won't come before the branch cut, I think we can remove the ReleaseBlock label from this bug at least.

Comment 46 by piman@chromium.org, Sep 20 2013

Labels: -M-31 -ReleaseBlock-Beta M-32 Cr-Internals-Compositing-Ubercomp
Owner: piman@chromium.org
It's not currently planned to re-enable on 31.

Comment 47 by piman@chromium.org, Sep 20 2013

Blocking: chromium:123444
 Issue 297982  has been merged into this issue.
I just tried this on Tip of tree on a link with Delegated Rendering enabled in about:flags (--enable-delegated-renderer)

0) Open a chrome window
1) Open Files.app
2) Open Ctrl+O  <-- in the chrome window
3) Close Files.app
4) Close Ctrl+O  <-- in the chroeme window
5) Try to open Files.app <-- no op

#5 worked fine for me. Is this fixed? Can someone verify? Or are my steps incorrect?
The steps are correct, but the comment #27 is easier.
It reproduces the issue only randomly. In September, I had to repeat the steps 10 or 20 times each time during bisection.

(I'm ooo and cannot verify by myself today. Can someone verify?)
Status: Fixed
Ok well I am able to open and close Files.app over and over. So I think this is fixed then.
Status: Verified
Google Chrome	32.0.1684.0 (Official Build 231271) dev
Platform	4879.0.0 (Official Build) dev-channel

Sign in to add a comment