User Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:63.0) Gecko/20100101 Firefox/63.0 Build ID: 20180906162647 Steps to reproduce: I've found big performance issues when I my add-on "Group Speed Dial" is combined with some other add-ons, mostly "Flash Video Downloader". My add-on is loading images as data URL encoded as base64 from IndexedDB. For each image, the "browser.webRequest.onBeforeRequest" handler fires in all installed add-ons. Due to some bug (or bad design) in "Flash Video Downloader", this causes big load times of my add-on page, sometimes even showing the yellow warning saying that my add-on page is slowing down your browser. Steps to reproduce: 0) watch the attached video 1) install Group Speed Dial add-on: https://addons.mozilla.org/en-US/firefox/addon/groupspeeddial/ 2) create two groups with 2x2 dials 4) add the dials and wait for them to create thumbnails 5) install "Flash Video Downloader" add-on: https://addons.mozilla.org/en-US/firefox/addon/flash-video-downloader/ 6) open new tab and try to switch between groups Actual results: New tab is frozen and the yellow warning is displayed saying that your tab is slowing down your browser. Expected results: 1) I'm not sure "browser.webRequest.onBeforeRequest" should fire for "data:" URLs images 2) add-ons should not be able to affect each other in a way that one can block execution of another

Video available here: https://youtu.be/cUT9DWZ-big (it's too big for upload here 18MB)

There's not much we can do about this. Data URIs are just expensive, especially large ones. The preferred way to load data from IndexedDB is to store it as a Blob and load it as a blob: URI.

I've been refactoring my add-on to blobs and I can confirm this fixes the compatibility bug. But the problem was the **** handling of those data URIs in the "Flash Video Downloader" add-on. Without it, it was blazing fast even before (and probably even faster than now with blobs, which loads one by one, asynchronously, because are not part of html like data URIs).

(In reply to juraj.masiar from comment #3) > probably even faster than now with blobs, which loads one by one, > asynchronously, because are not part of html like data URIs). That is not accurate. Images are loaded in parallel by a decoder pool, with off-thread data offloading from the network stream that the images come from. As a rule, data: URIs are significantly slower to process than most other types of network channel, but regardless, the same type of asynchronous decoding happens.