Open Bug 720189 Opened 12 years ago Updated 2 years ago

Extensions that try to filter/block/redirect requests or connections cannot handle requests that occur before extensions are loaded

Categories

(Core :: Networking, defect, P5)

x86_64
Windows 7
defect

Tracking

()

People

(Reporter: briansmith, Unassigned)

Details

(Keywords: perf, Whiteboard: [necko-would-take])

For example, if an extension implements nsIContentPolicy, (eventually) bug 644640, or other things, then it will *eventually* be able to start filtering requests/connections, once it is loaded. But, connections and/or requests can occur before extensions get loaded. And, in the near future, we will start pre-resolving/prefetching/preloading content even earlier at startup. Bug 713503 is just one example.

This is may just be something that we might have to accept, because AFAICT we can't wait to start fetching things until extensions are loaded, for performance reasons.

On the other hand, we don't want these extensions to set the prefs that disable these prefetching features (when such prefs are available, which isn't always--again see bug 713503), because these pref changes will be permanent and won't be undone after the addon is disabled/uninstalled.

So, we may need to implement some kind of mechanism where we store a flag somewhere that indicates that one or more addons have requested the ability to filter all network requests/connections/whatever, and disable the prefetching when that that flag is set. Importantly, we must regularly update this flag (e.g. at shutdown) so that we can automatically re-enable prefetching, etc. when the addon goes away. Addons would have to opt in to being counted for this, and we would have to document very closely the negative performance implications.
Whiteboard: [necko-would-take]
Bulk change to priority: https://bugzilla.mozilla.org/show_bug.cgi?id=1399258
Priority: -- → P5
Severity: normal → S3
You need to log in before you can comment on or make changes to this bug.