707196 - [meta] Deprecate and remove ways of doing blocking I/O on the main thread in JS

Status: RESOLVED INVALID

(Core :: General, defect)

Description

[Philipp von Weitershausen [:philikon]]

Bug 699820 is hurting us in terms of snappiness. Mishaps like bug 707090 and numerous add-ons demonstrate that purely the availability of blocking I/O calls will mean that people will inadvertently implement blocking I/O on the main thread.

I propose that we deprecate and very quickly also *remove* ways to do blocking I/O on the main thread in JavaScript. I suggest starting with obvious culprits like Cc["@mozilla.org/network/file-input-stream;1"].createInstance(Ci.nsIFileInputStream), and from there we can move on to the storage APIs and so on. Can we, perhaps, remove the [scriptable] flag from the relevant interface?

Comment 1

[Kyle Huey (Exited; not receiving bugmail, old account, do not use)]

Well, the problem is not creating nsIFileInputStreams, it's reading from them synchronously ... killing nsIFileInputStream's scriptability would be a really big hammer.

Comment 2

[(dormant account)]

We could check js stacks in debug builds and abort on io on main thread from js - whitelisted legacy files.

Comment 3

[Shawn Wilsher :sdwilsh]

(In reply to Taras Glek (:taras) from comment #2)
> We could check js stacks in debug builds and abort on io on main thread from
> js - whitelisted legacy files.
That doesn't help at all in the fight against bad add-ons.

Comment 4

[(dormant account)]

(In reply to Shawn Wilsher :sdwilsh from comment #3)
> (In reply to Taras Glek (:taras) from comment #2)
> > We could check js stacks in debug builds and abort on io on main thread from
> > js - whitelisted legacy files.
> That doesn't help at all in the fight against bad add-ons.

Indeed. Doesn't meant we shouldn't start somewhere.

Comment 5

[Gregory Pappas [:gregp]]

Closing inactive metabugs