Open ElhemEnohpi opened 5 years ago
Interesting. I'm using FF 64 on Windows 10, and I don't encounter this problem. "Site Blocked" tabs are restored when I restart FF. I will wait to see if there are other reports of the problem.
I just tried it again with Firefox 64.0.2 on macOS, and on Windows 7. Same thing happens on both. Starting with a new clean profile, I did literally nothing other than install Leechblock, set a url to block "all day", and set "Restore previous session" in preferences.
Pages showing the "page has been blocked", i.e., moz-extension://eda9e87c-cc0a-6928-b26c-d5cf244034c4/blocked.html?1&http://example.com/
don't get restored. Neither does the Leechblock Options page. If I specify a URL instead of the default page, it does get restored.
I tried looking in the sessionstore.jsonlz4 file in the profile folder after I quit Firefox. It's a bit hard to decipher, but it looks like those tabs are marked as having been closed, having a "closedAt" parameter. Seems they're maybe being closed on quit, as opposed to a problem getting restored. But I don't know that much about Firefox internals. Let me know if there's something else I can test...
I would just use the URL instead of the default block page, but I'm having another problem with that, where the page often gets stuck in an endless reloading loop with very high CPU, trying to show the URL/blank page. Still trying to figure out the steps to reproduce as it's not consistent.
Same here on Firefox 85.0.2 (64 bits) and Mac OS 10.15.7. Firefox closes the pinned blocked tab on startup.
Doesn't have this problem on Win 10 at home.
Sounds like Firefox doesn't like pinning extension pages. Perhaps try pinning a page (e.g., the options page) from a different extension and see if the same issue occurs.
I tried pinning different options pages from differents extensions and you are right. All closed on startup. This is a weird issue, happening only on Mac OS.
Thanks for the update. That is weird, but I guess I can close this issue for now!
The issue I reported had nothing to do with pinned tabs, and it hasn't been resolved. Leechblock's "site blocked" page, "moz-extension://321CBA.../blocked.html?2&https://example.com/" isn't restored on startup, on a Mac. So any tab that you were using, that happened to get blocked, will be lost from the session.
At least some other extensions' pages, for example the "group tab" from Tree Style Tab, "moz-extension://123ABC.../resources/group-tab.html?Title" are restored correctly. Firefox 85.0.2, Leechblock 1.0.11
Okay, thanks for clarifying. Do you mean restored after a crash or a normal close?
Honestly, this sounds more like an issue with Firefox than with LB. LB really has no control over which tabs are restored on startup.
It's after a normal close, with "Restore previous session" set in Preferences-General-Startup.
It might be related to the page loading a script. See https://github.com/piroor/treestyletab/issues/1670#issuecomment-350964087 although that issue affected Windows back then too. I don't know why it would affect Mac and not Windows now. It did affect Firefox on Windows when I tested it originally in 2019, I don't know why it didn't for you. I couldn't find anything in Bugzilla or documentation of that behaviour (though I didn't try very hard). I tried commenting out the <script src="blocked.js"></script>
, and the tab is restored.
Is the problem that the tab doesn't appear at all, or it does appear but with the blocking page not properly loaded?
It doesn't appear at all, it's not restored. The problem hasn't changed since my original description. It looks like the tabs are closed and removed from the session when Firefox quits. You can find them in the "recently closed tabs" menu.
Basically, the built-in blocking page can't be used (at least on a Mac), you have to use an alternate URL or a filter instead, that's what I'm doing. I actually really like the filter option, so I'm ok with that method. But if you don't know about it, you're going to lose data - blocked tabs vanish on restart.
I sadly have the same issue and I was just able to reproduce it: 1) open any page that's blocked by LeechBlock, see the "paged blocked" notification from LeechBlock 2) close and reopen Firefox -- all other tabs are stored.
At first I thought that it was an issue with the recent update (when you disable and re-enable the plugin the blocked pages are gone as well, which is somewhat inconvenient as well)
I sadly have the same issue and I was just able to reproduce it:
I haven't been able to reproduce the issue on my system. The tabs with blocking pages are correctly restored. What OS are you using?
macOS Catalina. Though if that were to be OS dependent it would be really weird.
Maybe some settings in the plugin itself?
Are internal pages from other extensions restored properly?
What would those be? Maybe extensions settings? (any example I could check?)
I've just tested this again with a fresh profile on a different computer, a Mac M1 with FF 89.0.2 and macOS 11.4, and it still happens. Maybe it's a Mac-only problem, that can happen because there are significant differences in the Firefox code for different platforms. I don't have access to a Windows machine at the moment.
As I mentioned on Feb 18, it's related to the blocked.html
page loading the script blocked.js
- I tested it by modifying the LeechBlockNG addon, editing blocked.html to comment out the script loading. If you do that (you need to turn off addon signing) then the blocked pages are restored as expected.
According to Piro (developer of Tree Style Tab) in the issue I linked to, extension HTML pages that load scripts are closed by Firefox. Seems like that's what's happening. I don't know why it would only happen on Mac though. I couldn't find more information about it, maybe you could ask Piro. He fixed it in TST by not loading a script that way.
Are internal pages from other extensions restored properly?
Stylus edit page is closed after restart, Firefox Addon-page remains open after restart.
Maybe what @ElhemEnohpi mentioned? Removing script invocation from blocked.html
page? I'd assume it's used to "restore the page" when it's available but that can be still access manually by clicking the link? I would even argue that removing this automation would be in some regard better as it wouldn't unblock page automatically.
Tested with LeechBlockNG 0.9.9 and Firefox 64 (also Waterfox/Firefox 56).
Result: Tabs from previous session are restored, except that tabs that were showing the "blocked" page are not restored.
As a partial work-around, you can go to History-Recently Closed Tabs, and restore them individually from there. Or specify a URL or blank page instead of the default blocking page, but there are currently other issues with that.