Open
Bug 1321097
Opened 9 years ago
Updated 3 years ago
windows file picker janks entire browser (event chrome UI in e10s mode)
Categories
(External Software Affecting Firefox :: Other, defect, P3)
External Software Affecting Firefox
Other
Tracking
(Not tracked)
NEW
People
(Reporter: bkelly, Unassigned)
References
(Blocks 1 open bug)
Details
(Whiteboard: tpi:+, widget-next)
Here are the steps to reproduce for me:
1. Setup a SMB share on a vmware instance
2. Click on "add attachment" on a bugzilla page.
3. Try to select a file from the SMB share
4. Observe entire browser UI jank while the file picker tries to attach to the SMB share
I realize a network drive can take time to attach (although this is entirely local to my machine) it seems odd to me we jank our entire UI in the process. It seems like we should be able to continue painting other parts of the browser while OS is working on the directory contents.
Perhaps this is a consequence of the file picker being a modal dialog.
Updated•9 years ago
|
Priority: -- → P2
Whiteboard: tpi:+
Comment 1•6 years ago
|
||
I see this as well. the source of this is dll loading, which can also be made worse by third party installs. We could improve this by preloading system dlls, shipping the file picker to a background process, and blocking 3rd party injection.
Component: Widget: Win32 → Other
Priority: P2 → P3
Product: Core → External Software Affecting Firefox
Whiteboard: tpi:+ → tpi:+, widget-next
Updated•3 years ago
|
Severity: normal → S3
You need to log in
before you can comment on or make changes to this bug.
Description
•