I found a difference scenario in which I can systematically reproduce `data:image/x-icon` entries in uBO's memory report. There is no need to disable uBO. - New Firefox session with only one pinned tab, `about:addons` - Have uBO as the only extension, ensure all up to date lists to avoid spurious memory usage - Go to `https://news.ycombinator.com/` - Middle-click every news entry link on the page - Click "More" at the bottom, repeat above step - Click "More" at the bottom, repeat above step - So now there should be around 90 tabs opened - Be sure "Restore previous session" is enabled - At this point, there should already be `data:image/x-icon` for uBO in `about:memory`, but I prefer to restart with a clean slate - Quit Firefox - Restart Firefox - Leave idle for 1-2 minutes - New tab to `about:memory`, click "Measure" (forcing CC/GC makes no difference) - Go to WebExtensions section - Under uBO's `js-zones`/`strings`, expand the list of `tiny` strings - Result: entries with `data:image/x-icon;base64,...` Since uBO does not store or even access `faviconUrl`, the challenge at this point is to identify why are these strings in uBO's heap. There are not many calls to `tabs.get`/`tabs.query` in uBO's code base, and so far I have been unable to identify anything wrong where these calls appear, the tab object returned by `tabs.get`/`tabs.query` is never stored, it's only used locally and thus should be GC'ed when the exiting the scope.
Bug 1652925 Comment 18 Edit History
Note: The actual edited comment in the bug view page will always show the original commenter’s name and original timestamp.
I found a difference scenario in which I can systematically reproduce `data:image/x-icon` entries in uBO's memory report. There is no need to disable uBO. - New Firefox session with only one pinned tab, `about:addons` - Have uBO as the only extension, ensure all up to date lists to avoid spurious memory usage - Go to `https://news.ycombinator.com/` - Middle-click every news entry link on the page - Click "More" at the bottom, repeat above step - Click "More" at the bottom, repeat above step - So now there should be around 90 tabs opened - Be sure "Restore previous session" is enabled - At this point, there should already be `data:image/x-icon` for uBO in `about:memory`, but I prefer to restart for a clean slate - Quit Firefox - Restart Firefox - Leave idle for 1-2 minutes - New tab to `about:memory`, click "Measure" (forcing CC/GC makes no difference) - Go to WebExtensions section - Under uBO's `js-zones`/`strings`, expand the list of `tiny` strings - Result: entries with `data:image/x-icon;base64,...` Since uBO does not store or even access `faviconUrl`, the challenge at this point is to identify why are these strings in uBO's heap. There are not many calls to `tabs.get`/`tabs.query` in uBO's code base, and so far I have been unable to identify anything wrong where these calls appear, the tab object returned by `tabs.get`/`tabs.query` is never stored, it's only used locally and thus should be GC'ed when the exiting the scope.
I found a difference scenario in which I can systematically reproduce `data:image/x-icon` entries in uBO's memory report. There is no need to disable uBO. - New Firefox session with only one pinned tab, `about:addons` - Have uBO as the only extension, ensure all up to date lists to avoid spurious memory usage - Go to `https://news.ycombinator.com/` - Middle-click every news entry link on the page - Click "More" at the bottom, repeat above step - Click "More" at the bottom, repeat above step - So now there should be around 90 tabs opened - Be sure "Restore previous session" is enabled - At this point, there should already be `data:image/x-icon` for uBO in `about:memory`, but I prefer to restart for a clean slate - Quit Firefox - Restart Firefox - Leave idle for 1-2 minutes - New tab to `about:memory`, click "Measure" (forcing CC/GC makes no difference) - Go to WebExtensions section - Under uBO's `js-zones`/`strings`, expand the list of `tiny` strings - Result: entries with `data:image/x-icon;base64,...` (around 10-15 on my side) Since uBO does not store or even access `faviconUrl`, the challenge at this point is to identify why are these strings in uBO's heap. There are not many calls to `tabs.get`/`tabs.query` in uBO's code base, and so far I have been unable to identify anything wrong where these calls appear, the tab object returned by `tabs.get`/`tabs.query` is never stored, it's only used locally and thus should be GC'ed when the exiting the scope.
I found a difference scenario in which I can systematically reproduce `data:image/x-icon` entries in uBO's memory report. There is no need to disable uBO. - New Firefox session with only one pinned tab, `about:addons` - Have uBO as the only extension, ensure all up to date lists to avoid spurious memory usage - Go to `https://news.ycombinator.com/` - Middle-click every news entry link on the page - Click "More" at the bottom, repeat above step - Click "More" at the bottom, repeat above step - So now there should be around 90 tabs opened - Be sure "Restore previous session" is enabled - At this point, there should already be `data:image/x-icon` for uBO in `about:memory`, but I prefer to restart for a clean slate - Quit Firefox - Restart Firefox - Leave idle for 1-2 minutes - New tab to `about:memory`, click "Measure" (forcing CC/GC makes no difference) - Go to WebExtensions section - Under uBO's `js-zones`/`strings`, expand the list of `tiny` strings - Result: entries with `data:image/x-icon;base64,...` (around 10-15 on my side) Since uBO does not store or even access `faviconUrl`, the challenge at this point is to identify why are these strings in uBO's heap. There are not many calls to `tabs.get`/`tabs.query` in uBO's code base, and so far I have been unable to identify anything wrong where these calls appear, the tab object returned by `tabs.get`/`tabs.query` is never stored, it's only used locally and thus should be GC'ed when exiting the scope.
I found a difference scenario in which I can systematically reproduce `data:image/x-icon` entries in uBO's memory report. There is no need to disable uBO. - New Firefox session with only one pinned tab, `about:addons` - Have uBO as the only extension, ensure all up to date lists to avoid spurious memory usage - Go to `https://news.ycombinator.com/` - Middle-click every news entry link on the page - Click "More" at the bottom, repeat above step - Click "More" at the bottom, repeat above step - So now there should be around 90 tabs opened - Be sure "Restore previous session" is enabled - At this point, there should already be `data:image/x-icon` for uBO in `about:memory`, but I prefer to restart for a clean slate - Quit Firefox - Restart Firefox - Leave idle for 1-2 minutes - New tab to `about:memory`, click "Measure" (forcing CC/GC makes no difference) - Go to WebExtensions section - Under uBO's `js-zones`/`strings`, expand the list of `tiny` strings - Result: entries with `data:image/x-icon;base64,...` (around 10-15 on my side) Since uBO does not store or even access `faviconUrl`, the challenge at this point is to identify why are these strings in uBO's heap. There are not many calls to `tabs.get`/`tabs.query` in uBO's code base, and so far I have been unable to identify anything wrong where these calls appear, the tab object returned by `tabs.get`/`tabs.query` is never stored, it's only used locally and thus should be GC'ed when exiting the scope. **Edit 1:** I notice that the set of `data:image/x-icon` is always the same each time the same session is reloaded. The top one consuming most memory is the favicon from `http://www.pyrunner.com/weblog/2016/05/26/compressed-sensing-python/`, a data URI of 132,929 characters.
I found a difference scenario in which I can systematically reproduce `data:image/x-icon` entries in uBO's memory report. There is no need to disable uBO. - New Firefox session with only one pinned tab, `about:addons` - Have uBO as the only extension, ensure all up to date lists to avoid spurious memory usage - Go to `https://news.ycombinator.com/` - Middle-click every news entry link on the page - Click "More" at the bottom, repeat above step - Click "More" at the bottom, repeat above step - So now there should be around 90 tabs opened - Be sure "Restore previous session" is enabled - At this point, there should already be `data:image/x-icon` for uBO in `about:memory`, but I prefer to restart for a clean slate - Quit Firefox - Restart Firefox - Leave idle for 1-2 minutes - New tab to `about:memory`, click "Measure" (forcing CC/GC makes no difference) - Go to WebExtensions section - Under uBO's `js-zones`/`strings`, expand the list of `tiny` strings - Result: entries with `data:image/x-icon;base64,...` (around 10-15 on my side) Since uBO does not store or even access `faviconUrl`, the challenge at this point is to identify why are these strings in uBO's heap. There are not many calls to `tabs.get`/`tabs.query` in uBO's code base, and so far I have been unable to identify anything wrong where these calls appear, the tab object returned by `tabs.get`/`tabs.query` is never stored, it's only used locally and thus should be GC'ed when exiting the scope. **Edit 1:** I notice that the set of `data:image/x-icon` is always the same each time the same session is reloaded. The top one consuming most memory is the favicon from `http://www.pyrunner.com/weblog/2016/05/26/compressed-sensing-python/`, a data URI of 132,929 characters. The URL for the favicon as per `view-source` is `http://www.pyrunner.com/static/favicon.ico`.
I found a difference scenario in which I can systematically reproduce `data:image/x-icon` entries in uBO's memory report. There is no need to disable uBO. - New Firefox session with only one pinned tab, `about:addons` - Have uBO as the only extension, ensure all up to date lists to avoid spurious memory usage - Go to `https://news.ycombinator.com/` - Middle-click every news entry link on the page - Click "More" at the bottom, repeat above step - Click "More" at the bottom, repeat above step - So now there should be around 90 tabs opened - Be sure "Restore previous session" is enabled - At this point, there should already be `data:image/x-icon` for uBO in `about:memory`, but I prefer to restart for a clean slate - Quit Firefox - Restart Firefox - Leave idle for 1-2 minutes - New tab to `about:memory`, click "Measure" (forcing CC/GC makes no difference) - Go to WebExtensions section - Under uBO's `js-zones`/`strings`, expand the list of `tiny` strings - Result: entries with `data:image/x-icon;base64,...` (around 10-15 on my side) Since uBO does not store or even access `favIconUrl`, the challenge at this point is to identify why are these strings in uBO's heap. There are not many calls to `tabs.get`/`tabs.query` in uBO's code base, and so far I have been unable to identify anything wrong where these calls appear, the tab object returned by `tabs.get`/`tabs.query` is never stored, it's only used locally and thus should be GC'ed when exiting the scope. **Edit 1:** I notice that the set of `data:image/x-icon` is always the same each time the same session is reloaded. The top one consuming most memory is the favicon from `http://www.pyrunner.com/weblog/2016/05/26/compressed-sensing-python/`, a data URI of 132,929 characters. The URL for the favicon as per `view-source` is `http://www.pyrunner.com/static/favicon.ico`.
I found a difference scenario in which I can systematically reproduce `data:image/x-icon` entries in uBO's memory report. There is no need to disable uBO. - New Firefox session with only one pinned tab, `about:addons` - Have uBO as the only extension, ensure all up to date lists to avoid spurious memory usage - Go to `https://news.ycombinator.com/` - Middle-click every news entry link on the page - Click "More" at the bottom, repeat above step - Click "More" at the bottom, repeat above step - So now there should be around 90 tabs opened - Be sure "Restore previous session" is enabled - At this point, there should already be `data:image/x-icon` for uBO in `about:memory`, but I prefer to restart for a clean slate - Quit Firefox - Restart Firefox - Leave idle for 1-2 minutes - New tab to `about:memory`, click "Measure" (forcing CC/GC makes no difference) - Go to WebExtensions section - Under uBO's `js-zones`/`strings`, expand the list of `tiny` strings - Result: entries with `data:image/x-icon;base64,...` (around 10-15 on my side) Since uBO does not store or even access `favIconUrl`, the challenge at this point is to identify why are these strings in uBO's heap. There are not many calls to `tabs.get`/`tabs.query` in uBO's code base, and so far I have been unable to identify anything wrong where these calls appear, the tab object returned by `tabs.get`/`tabs.query` is never stored, it's only used locally and thus should be GC'ed when exiting the scope. --- **Edit 1:** I notice that the set of `data:image/x-icon` is always the same each time the same session is reloaded. The top one consuming most memory is the favicon from `http://www.pyrunner.com/weblog/2016/05/26/compressed-sensing-python/`, a data URI of 132,929 characters. The URL for the favicon as per `view-source` is `http://www.pyrunner.com/static/favicon.ico`. --- **Edit 2:** Given the above findings, I reduced the repro steps to only two tabs: - `https://news.ycombinator.com/` - `http://www.pyrunner.com/weblog/2016/05/26/compressed-sensing-python/` Relaunching the browser with the two tabs above will cause the stray `data:image/x-icon` entry to occur **if and only if** upon restore the `https://news.ycombinator.com/` is the default one and the other tab is **not** activated. I will keep trying to narrow.
I found a difference scenario in which I can systematically reproduce `data:image/x-icon` entries in uBO's memory report. There is no need to disable uBO. - New Firefox session with only one pinned tab, `about:addons` - Have uBO as the only extension, ensure all up to date lists to avoid spurious memory usage - Go to `https://news.ycombinator.com/` - Middle-click every news entry link on the page - Click "More" at the bottom, repeat above step - Click "More" at the bottom, repeat above step - So now there should be around 90 tabs opened - Be sure "Restore previous session" is enabled - At this point, there should already be `data:image/x-icon` for uBO in `about:memory`, but I prefer to restart for a clean slate - Quit Firefox - Restart Firefox - Leave idle for 1-2 minutes - New tab to `about:memory`, click "Measure" (forcing CC/GC makes no difference) - Go to WebExtensions section - Under uBO's `js-zones`/`strings`, expand the list of `tiny` strings - Result: entries with `data:image/x-icon;base64,...` (around 10-15 on my side) Since uBO does not store or even access `favIconUrl`, the challenge at this point is to identify why are these strings in uBO's heap. There are not many calls to `tabs.get`/`tabs.query` in uBO's code base, and so far I have been unable to identify anything wrong where these calls appear, the tab object returned by `tabs.get`/`tabs.query` is never stored, it's only used locally and thus should be GC'ed when exiting the scope. --- **Edit 1:** I notice that the set of `data:image/x-icon` is always the same each time the same session is reloaded. The top one consuming most memory is the favicon from `http://www.pyrunner.com/weblog/2016/05/26/compressed-sensing-python/`, a data URI of 132,929 characters. The URL for the favicon as per `view-source` is `http://www.pyrunner.com/static/favicon.ico`. --- **Edit 2:** Given the above findings, I reduced the repro steps to only two tabs: - `https://news.ycombinator.com/` - `http://www.pyrunner.com/weblog/2016/05/26/compressed-sensing-python/` Relaunching the browser with the two tabs above will cause the stray `data:image/x-icon` entry to occur **if and only if** upon restore the `https://news.ycombinator.com/` is the default one and the other tab -- the one "leaking" a data URI -- is **not** activated. I will keep trying to narrow.
I found a difference scenario in which I can systematically reproduce `data:image/x-icon` entries in uBO's memory report. There is no need to disable uBO. - New Firefox session with only one pinned tab, `about:addons` - Have uBO as the only extension, ensure all up to date lists to avoid spurious memory usage - Go to `https://news.ycombinator.com/` - Middle-click every news entry link on the page - Click "More" at the bottom, repeat above step - Click "More" at the bottom, repeat above step - So now there should be around 90 tabs opened - Be sure "Restore previous session" is enabled - At this point, there should already be `data:image/x-icon` for uBO in `about:memory`, but I prefer to restart for a clean slate - Quit Firefox - Restart Firefox - Leave idle for 1-2 minutes - New tab to `about:memory`, click "Measure" (forcing CC/GC makes no difference) - Go to WebExtensions section - Under uBO's `js-zones`/`strings`, expand the list of `tiny` strings - Result: entries with `data:image/x-icon;base64,...` (around 10-15 on my side) Since uBO does not store or even access `favIconUrl`, the challenge at this point is to identify why are these strings in uBO's heap. There are not many calls to `tabs.get`/`tabs.query` in uBO's code base, and so far I have been unable to identify anything wrong where these calls appear, the tab object returned by `tabs.get`/`tabs.query` is never stored, it's only used locally and thus should be GC'ed when exiting the scope. --- **Edit 1:** I notice that the set of `data:image/x-icon` is always the same each time the same session is reloaded. The top one consuming most memory is the favicon from `http://www.pyrunner.com/weblog/2016/05/26/compressed-sensing-python/`, a data URI of 132,929 characters. The URL for the favicon as per `view-source` is `http://www.pyrunner.com/static/favicon.ico`. --- **Edit 2:** Given the above findings, I reduced the repro steps to only two tabs: - `about:addons` (I pinned it in my case) - `http://www.pyrunner.com/weblog/2016/05/26/compressed-sensing-python/` Relaunching the browser with the two tabs above will cause the stray `data:image/x-icon` entry to occur **if and only if** upon restore the `about:addons` is the default one and the other tab -- the one "leaking" a data URI -- is **not** activated. I will keep trying to narrow.
I found a difference scenario in which I can systematically reproduce `data:image/x-icon` entries in uBO's memory report. There is no need to disable uBO. - New Firefox session with only one pinned tab, `about:addons` - Have uBO as the only extension, ensure all up to date lists to avoid spurious memory usage - Go to `https://news.ycombinator.com/` - Middle-click every news entry link on the page - Click "More" at the bottom, repeat above step - Click "More" at the bottom, repeat above step - So now there should be around 90 tabs opened - Be sure "Restore previous session" is enabled - At this point, there should already be `data:image/x-icon` for uBO in `about:memory`, but I prefer to restart for a clean slate - Quit Firefox - Restart Firefox - Leave idle for 1-2 minutes - New tab to `about:memory`, click "Measure" (forcing CC/GC makes no difference) - Go to WebExtensions section - Under uBO's `js-zones`/`strings`, expand the list of `tiny` strings - Result: entries with `data:image/x-icon;base64,...` (around 10-15 on my side) Since uBO does not store or even access `favIconUrl`, the challenge at this point is to identify why are these strings in uBO's heap. There are not many calls to `tabs.get`/`tabs.query` in uBO's code base, and so far I have been unable to identify anything wrong where these calls appear, the tab object returned by `tabs.get`/`tabs.query` is never stored, it's only used locally and thus should be GC'ed when exiting the scope. --- **Edit 1:** I notice that the set of `data:image/x-icon` is always the same each time the same session is reloaded. The top one consuming most memory is the favicon from `http://www.pyrunner.com/weblog/2016/05/26/compressed-sensing-python/`, a data URI of 132,929 characters. The URL for the favicon as per `view-source` is `http://www.pyrunner.com/static/favicon.ico`. --- **Edit 2:** Given the above findings, I reduced the repro steps to only two tabs: - `about:addons` (I pinned it in my case) - `http://www.pyrunner.com/weblog/2016/05/26/compressed-sensing-python/` Relaunching the browser with the two tabs above will cause the stray `data:image/x-icon` entry to occur **if and only if** upon restore the `about:addons` is the default one and the other tab -- the one "leaking" a data URI -- is **not** activated. I will keep trying to narrow. --- **Edit 3:** Observation, if I add the instruction `tab.favIconUrl = '';` [inside this loop](https://github.com/gorhill/uBlock/blob/a400799115feca8925dd78a36a220a27cfa64626/src/js/start.js#L65), the stray data URI disappears in the revised scenario above. So far, my understanding is that the WebExtensions framework is using the extension's heap to allocate memory for the `favIconUrl` upon calling `tabs.query()`, but it's never released afterward even though the owner `Tab` object goes out of scope.
I found a difference scenario in which I can systematically reproduce `data:image/x-icon` entries in uBO's memory report. There is no need to disable uBO. - New Firefox session with only one pinned tab, `about:addons` - Have uBO as the only extension, ensure all up to date lists to avoid spurious memory usage - Go to `https://news.ycombinator.com/` - Middle-click every news entry link on the page - Click "More" at the bottom, repeat above step - Click "More" at the bottom, repeat above step - So now there should be around 90 tabs opened - Be sure "Restore previous session" is enabled - At this point, there should already be `data:image/x-icon` for uBO in `about:memory`, but I prefer to restart for a clean slate - Quit Firefox - Restart Firefox - Leave idle for 1-2 minutes - New tab to `about:memory`, click "Measure" (forcing CC/GC makes no difference) - Go to WebExtensions section - Under uBO's `js-zones`/`strings`, expand the list of `tiny` strings - Result: entries with `data:image/x-icon;base64,...` (around 10-15 on my side) Since uBO does not store or even access `favIconUrl`, the challenge at this point is to identify why are these strings in uBO's heap. There are not many calls to `tabs.get`/`tabs.query` in uBO's code base, and so far I have been unable to identify anything wrong where these calls appear, the tab object returned by `tabs.get`/`tabs.query` is never stored, it's only used locally and thus should be GC'ed when exiting the scope. --- **Edit 1:** I notice that the set of `data:image/x-icon` is always the same each time the same session is reloaded. The top one consuming most memory is the favicon from `http://www.pyrunner.com/weblog/2016/05/26/compressed-sensing-python/`, a data URI of 132,929 characters. The URL for the favicon as per `view-source` is `http://www.pyrunner.com/static/favicon.ico`. --- **Edit 2:** Given the above findings, I reduced the repro steps to only two tabs: - `about:addons` (I pinned it in my case) - `http://www.pyrunner.com/weblog/2016/05/26/compressed-sensing-python/` Relaunching the browser with the two tabs above will cause the stray `data:image/x-icon` entry to occur **if and only if** upon restore the `about:addons` is the default one and the other tab -- the one "leaking" a data URI -- is **not** activated. I will keep trying to narrow. --- **Edit 3:** Observation, if I add the instruction `tab.favIconUrl = '';` [inside this loop](https://github.com/gorhill/uBlock/blob/a400799115feca8925dd78a36a220a27cfa64626/src/js/start.js#L65), the stray data URI disappears in the revised scenario above. So far, my understanding is that the WebExtensions framework is using the extension's heap to allocate memory for the `favIconUrl` upon calling `tabs.query()`, but it's never released afterward even though the owner `Tab` object goes out of scope. --- **Edit 4:** Observation, it appears this has to do with calling `tabs.executeScript()` on a tab which `discarded` property is `true`. If I call `tabs.executeScript()` only for when `Tab.discarded !== true`, the data URI entry disappears in the above scenario.