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)

Tracking

(Not tracked)

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.
Priority: -- → P2
Whiteboard: tpi:+
Blocks: dll-jank

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
See Also: → 1677170
Severity: normal → S3
You need to log in before you can comment on or make changes to this bug.