[e10s] File input sometimes doesn't close

REOPENED
Unassigned

Status

()

Core
Widget: Cocoa
P3
normal
REOPENED
2 years ago
2 years ago

People

(Reporter: mconley, Unassigned)

Tracking

50 Branch
Unspecified
Mac OS X
Points:
---

Firefox Tracking Flags

(e10s+)

Details

(Whiteboard: tpi:+)

Attachments

(1 attachment)

I've only ever seen this with e10s enabled on my OS X machine.

Basically, if I've got a session I've been running for a while, and then I happen to try to upload a file, when I choose a file from the file picker, the dialog doesn't get dismissed. In the background, the window is still responsive (in fact, in the most recent case, it looks like the upload of the file I selected goes on successfully), but the dialog is stuck in the way and is not dismissable. I can only get rid of the dialog when I restart Firefox.
Component: Layout: Form Controls → Widget: Cocoa
Is it possible that another modal dialog was opened behind the file picker, by web content for example? I just had a look at bug 1260850 today and this report looks eerily similar.
Flags: needinfo?(mconley)
(In reply to Stephen A Pohl [:spohl] from comment #1)
> Is it possible that another modal dialog was opened behind the file picker,
> by web content for example? I just had a look at bug 1260850 today and this
> report looks eerily similar.

Hard to say. The File Picker can't be moved or shrunk, so if there's one hidden behind it, I can't tell. I can move the Firefox window (which seems to function just fine in this state), but I can't say for certain if there's another window stuck behind it. I suppose I could check the "Window" list next time this occurs in case something new is listed there.
Flags: needinfo?(mconley)
Not sure if you're running a local build, but if you do, you could try running with attachment 8784382 [details] [diff] [review] applied to see if this fixes it. It's a suggested approach to fix bug 1260850.

Updated

2 years ago
Depends on: 1260850
Priority: -- → P2
Whiteboard: tpi:+

Updated

2 years ago
tracking-e10s: --- → +
Flags: needinfo?(mconley)
Yes, the patch in bug 1260850 appears to fix it!

Should we dupe this bug over to that one?
Flags: needinfo?(mconley) → needinfo?(spohl.mozilla.bugs)
Yes. It would be great if you could add a comment there to give my patch/approach further credibility. :-) Thanks for checking this out!
Flags: needinfo?(spohl.mozilla.bugs)
Flags: needinfo?(mconley)
Done. :)
Flags: needinfo?(mconley)
Thank you!
Status: NEW → RESOLVED
Last Resolved: 2 years ago
Resolution: --- → DUPLICATE
Duplicate of bug: 1260850
Unfortunately, I still see this from time to time. :/ I thought that bug 1260850 fixed this, but I think I was wrong.

So, some more facts:

1) This bug seems to manifest only after a longer session, which makes me wonder if it's due to the fact that we can't allocate a large enough shmem due to fragmentation?
2) Is only easily reproduced with a large file (400MB, for example)
Status: RESOLVED → REOPENED
Resolution: DUPLICATE → ---
Created attachment 8795812 [details]
Process sample with file dialog up

I took a process sample while the file dialog was up.
I still see this almost daily. :/

Hey jimm, does this fall under Platform Integration?
Flags: needinfo?(jmathies)

Comment 11

2 years ago
(In reply to Mike Conley (:mconley) - (high latency on reviews and needinfos) from comment #10)
> I still see this almost daily. :/
> 
> Hey jimm, does this fall under Platform Integration?

It is, we gave it a P2. Only one report of this happening.. makes me wonder if it's something specific to your use of the browser?

spohl has a few things on his plate right now, and he's ooto for a week. We'll try to fit it in though once he's back.

spohl, were you ever able to reproduce this?
Flags: needinfo?(jmathies) → needinfo?(spohl.mozilla.bugs)
I was only able to reproduce bug 1260850 and it looked like a duplicate, but given comment 8 I can't say that I've ever been able to reproduce this bug here.
Flags: needinfo?(spohl.mozilla.bugs)
(In reply to Stephen A Pohl [:spohl] from comment #12)
> I was only able to reproduce bug 1260850 and it looked like a duplicate, but
> given comment 8 I can't say that I've ever been able to reproduce this bug
> here.

Since I'm able to reproduce this pretty reliably (usually on Wednesdays when I upload my Joy of Coding videos to YouTube and AirMo) is there a good place for me to set breakpoints to get data on what's going wrong here?
Flags: needinfo?(spohl.mozilla.bugs)
I would try to set breakpoints in the changes made in attachment 8789485 [details] [diff] [review]. In particular, it would be great to verify that the file picker is indeed detected as being appModal in nsWindowWatcher.cpp. Another thing to check might be the Console.app for any relevant messages.

You could also try and reproduce this in a debug build (launched from Terminal) and watch for relevant output in the Terminal. But you mention that this only occurs after a long session, so not sure how feasible (or painful) that would be. This does sound like more of a memory issue than an issue related to being appModal though.
Flags: needinfo?(spohl.mozilla.bugs)
Mike, are you still seeing this? Did you have any luck with the suggestions in comment 14?
Flags: needinfo?(mconley)
Priority: P2 → P3
I'll try again tomorrow - that's when I usually do my large file uploads for Joy of Coding.
So I was sorta able to reproduce, but it actually behaved a bit differently.

I selected the video file, and the dialog stayed up despite the upload beginning in the background. However, I also took this opportunity to get up and leave the room to do a few other things. When I got back, the dialog was gone.

So I think the dialog goes away _eventually_. It just takes a loooooong time to do it.

Is there a message that we wait for from the content process to close that dialog?
Flags: needinfo?(mconley) → needinfo?(spohl.mozilla.bugs)
Unfortunately, I don't know off-hand. We'll have to investigate once we get to it.
Flags: needinfo?(spohl.mozilla.bugs)
You need to log in before you can comment on or make changes to this bug.