Open
Bug 1203498
Opened 9 years ago
Updated 2 years ago
Improve the e10s code paths to notify the content process to dispatch a 'change' event before the the results of a directory picker selection are dispatched
Categories
(Core :: DOM: Core & HTML, defect, P3)
Core
DOM: Core & HTML
Tracking
()
NEW
People
(Reporter: jwatt, Unassigned)
References
(Depends on 1 open bug, Blocks 1 open bug)
Details
Right now the e10s paths for directory picking involve collecting up the picked items, stat'ing them and caching the results of the stat'ing, passing the list over to the content process, then firing the 'change' event. This means that the 'change' event blocks on I/O for the stats which may block the page from being notified that the user picked something for some time. The directory picking spec is designed to allow the 'change' event to be fired before I/O has occurred though. (See my description of this in https://github.com/WICG/directory-upload/issues/8 for more.) To take advantage of this we would need the chrome process to separately notify the content process to dispatch a 'change' event. Right now this is low priority because we currently only support directory picking of a single directory (bug 1203495) and because file picking doesn't have a mechanism to bypass the I/O before dispatching the 'change' event like directory picking does (see https://github.com/WICG/directory-upload/issues/11 for more on that one). Obviously stat'ing a single directory is much less likely to block for a noticeable length of time than stating thousands of files. If either of those things changes though we should fix this bug.
Updated•9 years ago
|
tracking-e10s:
--- → +
Updated•8 years ago
|
Priority: -- → P3
Assignee | ||
Updated•5 years ago
|
Component: DOM → DOM: Core & HTML
Updated•2 years ago
|
Severity: normal → S3
You need to log in
before you can comment on or make changes to this bug.
Description
•