MarvellousSuspender
MarvellousSuspender copied to clipboard
Suspended tabs name with 3 dots and white page (THE PROBLEM IS BACK)
- Extension version: v7.1.6.2
- Browser name & version: Chrome Dev. 104.0.5110.0
- Browser name & version: Chrome Canary 105.0.5118.3
- Operating system & version: Win 10 21H2
The problem is back https://github.com/gioxx/MarvellousSuspender/issues/161
Same exact problem.
On Chrome stable 102.0.5005.63 and Chrome Beta 103.0.5060.42 is not present, but obviously as soon as the new 104 version will get pushed we will be in trouble.
Same here.
Extension version: v7.1.6.2 Chrome Version: 104.0.5110.0 (Official Build) dev (64-bit)
so same procedure as last time: make sure that the chromium team knows about it, and ideally identify the exact commit that caused the regression.
Same here.
Extension version: v7.1.6.2 Chrome Version: 104.0.5112.20 (Official Build) beta (arm64)
In terms of "make sure that the chromium team knows about it" β is there a clear, specific process on how to go about doing that? Why would the chromium team care about this extension no longer working?
~~FYI ... I had the same problem in "Chrome VersiΓ³n 105.0.5148.2 (Build oficial) dev (64 bits)" but I fixed it by reverting the Tab Scrolling experiment flag (chrome://flags/#scrollable-tabstrip
) to Default again (I don't remember enabling it, π€)~~
I didn't say anything, it keeps happening, π
It has been broken for a couple of weeks now. I have tried several options and can't find a way to fix it. Does anyone have any ideas on how to fix it?
Does anyone have any ideas on how to fix it?
The problem, suspended page doesn't appear automatically when user go to a particular page and if you click on that page once (somehow if didn't then double click but single click enough) and wait a moment then suspended page will appear; after that you can click again to unsuspend it as usual
(chromium edge build)
I'm running the same configuration on three different laptops and this problem has just started but on only one of the computers. Which doesn't really make sense because it's a Chrome profile that is synced across all devices. After reading the older linked post I just disabled the Camelizer extension and will see if that helps. ETA: It didn't help.
I just realized my problematic Chrome + Marvelous Suspender installation was running Chrome Beta 104.0.5112.48. Have no idea, I don't even remember installing beta in the past but once I removed it and installed a current stable version all is well. Everyone has their proper favicons and names again so it's worth a check to see if you're running Chrome Beta too.
Maybe it is not Chrome Beta that was the isse but the fact that the same Google Profile was used by different versions of Google Chrome and that messed up with the internals of TMS π€
I think I face the issue each time after Chrome gets updated and restarts all the windows/tabs.
More over I can confirm @Aikatsui observations: https://github.com/gioxx/MarvellousSuspender/issues/185#issuecomment-1177784273
if you click on that page once (somehow if didn't then double click but single click enough) and wait a moment then suspended page will appear (after that you can click again to unsuspend it as usual)
I am using Google Chrome Beta on Mac: v104.0.5112.39 And TMS has to manage ~80 suspended tabs
I don't know it all this information might help π€·π»
Maybe it is not Chrome Beta that was the isse but the fact that the same Google Profile was used by different versions of Google Chrome and that messed up with the internals of TMS π€
Nope, I stopped chrome from updating on my laptop, so I still have Chrome stable 102.0.5005.63 and Chrome Beta 103.0.5060.42 and everything works fine, on the desktop I have chrome beta 104 and I have the problem, all with the same account, so it all starts in v104 and as soon as they push it on stable chrome, the bug will be present in every version.
What @Ocel8 said π. Has someone already opened an issue with the Chromium team so we can all star it to draw attention? It's making TMS unbearable having to switch to a tab, click on the white page, wait 3+ seconds just for the suspended to appear to then click again to unsuspend it.
What @Ocel8 said π. Has someone already opened an issue with the Chromium team so we can all star it to draw attention? It's making TMS unbearable having to switch to a tab, click on the white page, wait 3+ seconds just for the suspended to appear to then click again to unsuspend it.
I'd say go ahead and open an issue with the Chromium team. You can do a search to see if a similar issue exists. If not just file a bug and worst case scenario is that if there is a similar issue already filed it will be marked as duplicate.
- Extension version: v7.1.6.2
- Browser name & version: Chrome Beta 104.0.5112.79
- Operating system & version: Mac OS 12.5
Anyone find any workarounds for this (or hear any responses from reaching out to the Chromium team)? Much appreciated.
Just updated to Google Chrome 104.0.5112.81, It's borked. And here I am again :(
Just updated to Google Chrome 104.0.5112.81, It's borked. And here I am again :(
same -___-
If it can help, I'm not using MarvellousSuspender but a cleaned (and not updated) fork of the last Suspender (https://github.com/u1735067/thesuspender) and I'm also affected, I've observed that:
- I'm affected since Chrome M104
- If I open DevTools on a bugged suspended tab, it automagically fixes it
- After enabling logs (maybe not required) and opening the background devtools view, if I switch on a bugged suspended tab, I can see the following log:
WARNING: 1767309385 15:51:29 Could not get internalTabView for suspended tab
at Object.initTab (chrome-extension://pbpjlpjdafacbpklfcdkkiehijhcamkh/js/gsSuspendedTab.js:8:15)
at initialiseSuspendedTab (chrome-extension://pbpjlpjdafacbpklfcdkkiehijhcamkh/js/background.js:889:8)
at handleSuspendedTabStateChanged (chrome-extension://pbpjlpjdafacbpklfcdkkiehijhcamkh/js/background.js:861:9)
at chrome-extension://pbpjlpjdafacbpklfcdkkiehijhcamkh/js/background.js:1746:9
gsUtils.js:54 WARNING: 1767309385 15:51:29 TypeError: Cannot read properties of null (reading 'document')
at Object.initTab (gsSuspendedTab.js:16:13)
at initialiseSuspendedTab (background.js:889:8)
at handleSuspendedTabStateChanged (background.js:861:9)
at background.js:1746:9
at chrome-extension://pbpjlpjdafacbpklfcdkkiehijhcamkh/js/background.js:891:17
Also, while I have a LOT of suspended tab (so this bug is really annoying), chrome.extension.getViews()
(and chrome.extension.getExtensionTabs()
) return a very low count of element (~15 for 200+ suspended tabs), so it looks like Chrome thinks tabs are not attached to the extension?
Edit: filled https://bugs.chromium.org/p/chromium/issues/detail?id=1349787 with those informations
Edit2: now using Marvellous Suspender :)
Edit3: error logs using Marvellous Suspender:
gsUtils.js:54 WARNING: 1767310795 14:16:40 Could not get internalTabView for suspended tab
at Object.initTab (chrome-extension://noogafoofpebimajpfpamcfhoaifemoa/js/gsSuspendedTab.js:8:15)
at initialiseSuspendedTab (chrome-extension://noogafoofpebimajpfpamcfhoaifemoa/js/background.js:885:8)
at handleSuspendedTabStateChanged (chrome-extension://noogafoofpebimajpfpamcfhoaifemoa/js/background.js:857:9)
at chrome-extension://noogafoofpebimajpfpamcfhoaifemoa/js/background.js:1723:9
gsUtils.js:54 WARNING: 1767310795 14:16:40 TypeError: Cannot read properties of null (reading 'document')
at Object.initTab (gsSuspendedTab.js:16:13)
at initialiseSuspendedTab (background.js:885:8)
at handleSuspendedTabStateChanged (background.js:857:9)
at background.js:1723:9
at chrome-extension://noogafoofpebimajpfpamcfhoaifemoa/js/background.js:887:17
Workaround after a browser start or window reopen: Session management
-> Old TGS Extension id
: put this extension id (noogafoofpebimajpfpamcfhoaifemoa
) -> migrate tabs -> this seems to reload all tabs correctly
Confirming bug is on Chromium Version 104.0.5112.79 (Official Build) Arch Linux (64-bit)
, and that @u1735067's temporary solution worked, but only for the 1 active tab per window!
Workaround after a browser start or window reopen:
Session management
->Old TGS Extension id
: put this extension id (noogafoofpebimajpfpamcfhoaifemoa
) -> migrate tabs -> this seems to reload all tabs correctly
thanks @u1735067 , it worked just had the same issue and thought I did something.
Edit: filled https://bugs.chromium.org/p/chromium/issues/detail?id=1349787 with those informations
It's been reproduced & confirmed by the Chromium team and has been assigned priority 1, so I guess a version fixing this will be released soon :) (cc @gioxx as people seems to be on https://github.com/gioxx/MarvellousSuspender/issues/188)
meanwhile, as posted on the bug portal, you can start chrome with --disable-features=AvoidEarlyExtensionScriptContextCreation command line arg as an emergency fix. I tested it and now the extension is working back again.
meanwhile, as posted on the bug portal, you can start chrome with --disable-features=AvoidEarlyExtensionScriptContextCreation command line arg as an emergency fix. I tested it and now the extension is working back again.
Figured it out you have to open the folder where chrome.exe lives in (on windows (C:\Program Files\Google\Chrome\Application)) and then open cmd or PowerShell in there and then run .\chrome.exe --disable-features=AvoidEarlyExtensionScriptContextCreation
btw if you use Chrome shortcut just go to the shortcut and then properties and add the following code after the closing " add a space then --disable-features=AvoidEarlyExtensionScriptContextCreation
On Linux you can create a temporarily modified shortcut by copying the default one, making it executable, and changing the exec line. You can change chromium
depending on your version (ex: google-chrome-beta
)
cp /usr/share/applications/chromium.desktop ~/Desktop/ && chmod +x ~/chromium.desktop && nano ~/chromium.desktop
Then edit Exec line to match: Exec=/usr/bin/chromium --disable-features=AvoidEarlyExtensionScriptContextCreation %U
On macOS you quit Chrome and run in Terminal:
open -na "Google Chrome" --args --disable-features=AvoidEarlyExtensionScriptContextCreation
On macOS you quit Chrome and run in Terminal:
open -na "Google Chrome" --args --disable-features=AvoidEarlyExtensionScriptContextCreation
Taking it one step further, I made it into an Applescript Bundle:
- Launch Script Editor [in Applications/Utilities] & make a new script...
do shell script "\"/Applications/Google Chrome.app/Contents/MacOS/Google Chrome\" --args --disable-features=AvoidEarlyExtensionScriptContextCreation > /dev/null 2>&1 &"
quit
Save your script:
- [File->Save] Save it somewhere like ~/Documents as something memorable like "Chrome Suspender" Make it executable:
- [File->Export] Select where to make the script's application bundle, like ~/Applications (your local user rather than system-wide)
- Change "File Format" to "Application"
- leave all three checkboxes empty
- Code Sign: "Sign to Run Locally"
- Click Save
- Quit Script Editor
- Run your script application bundle to open Chrome
meanwhile, as posted on the bug portal, you can start chrome with --disable-features=AvoidEarlyExtensionScriptContextCreation command line arg as an emergency fix. I tested it and now the extension is working back again.
This works, but I'm just curious - what's happening with Chrome that is breaking it?
meanwhile, as posted on the bug portal, you can start chrome with --disable-features=AvoidEarlyExtensionScriptContextCreation command line arg as an emergency fix. I tested it and now the extension is working back again.
This works, but I'm just curious - what's happening with Chrome that is breaking it?
well it's disabling the feature "AvoidEarlyExtensionScriptContextCreation", so my guess is that is what is happening with Chrome that is breaking it.
https://www.google.com/search?q=AvoidEarlyExtensionScriptContextCreation
Basically, Chrome moved extension startup earlier than it was previously, which can break things as well as slow things down. The flag tells Chrome to start extensions later
Ah, interesting that something like that would be enough to do that - but I'm glad there's a relatively easy fix.
Basically, Chrome moved extension startup earlier than it was previously, which can break things as well as slow things down. The flag tells Chrome to start extensions later.
The command-line flag specifically disables a feature called AvoidEarlyExtensionScriptContextCreation, so surely it's the opposite and parts of Chrome's extension initialisation were moved to happen later (assuming to save on resources by not allocating stuff for extension script contexts when the extensions aren't being used yet), and disabling the feature makes Chrome revert to creating the script contexts earler?