-
-
Notifications
You must be signed in to change notification settings - Fork 29
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Reopened window not associated with tree node after Windows restart #119
Comments
I think you mean that, before you click to re-open a window, there is a "recovered tabs" entry that duplicates the saved entry, but without the window name. After you click, the "recovered tabs" entry has taken over and the saved entry is untouched. Is that correct? If so, I think I might know why --- at present, merging assumes only one window has a given set of tabs (e.g., here). If a Recovered entry had the same tabs as a saved entry, only one would win. For this one, I want to be sure I am testing the behaviour you are actually seeing. Would you please give me a step-by-step walkthrough of how to get into the situation you describe? Please begin from creating a new, unsaved window, and go all the way through. I will follow the steps you give me. If I also experience the problem (as I expect I will), it should be no trouble to fix. Thanks! |
No, not before click to re-open. After Chrome starts, tabfern shows everything correctly. All windows that were open (2 windows)/closed (several windows) before start are in closed state and with correct name. There are no "recovered tabs" visible, just like it should be. After I click a window name to restore the windows + tabs therein, instead of opening the window I clicked at, the whole window + tabs therein are duplicated. Actually I do not now remember did they open as "Recovered tabs" or just unnamed window. I will test this again later this week. Edit: I just checked tabfern, and I remembered wrong - they were not "Recovered tabs" but "Unsaved". So now I have 2 copies of the same windows + tabs therein, one named window and one "Unsaved" window. |
That is very strange! What version/bitness of Chrome; what OS/version/bitness? I don't recall ever experiencing a situation like that. The two open windows - were they open when you last exited Chrome, or last restarted? What happened prior to Chrome startup? It is true that merge checking doesn't happen when you manually click a window to open it. I looked through the code and didn't see anything that looked directly connected to what I understand from your description. There was a race condition that would cause problems if somehow you asked to open two windows at once, so I changed that. On the plus side, the function that opens windows ( |
Running latest version of Chrome: Version 65.0.3325.162 (Official Build) (64-bit) I make a step-by-step list: |
It is not a big problem, just wanted to let you know. |
This is to mitigate a possible race condition. Possibly related to #119.
Thanks for the list, and the compliment! :D I will try it out. |
@bluikko I am sorry to say I was not able to reproduce the issue. Would you be willing to email me a TF backup file with only the windows that are exhibiting the problem? I am wondering if perhaps some of the specific tabs in question are redirecting, and there's a race condition somewhere in TF. |
There are 2 windows and initially both of them do open under the named node. I will try a process of elimination to find out which tabs cause it. On the first window there are only 7 different sites (most sites have several tabs open). Some of them are complex web applications like https://www.asana.com/ and on the second window there are also complex web applications. |
I have just tried the following:
After restart all windows are still correctly named, even after I tried to play around and make it "forget" the window names. So right now I am unable to reproduce this issue. I will keep on taking notes what I do with Chrome and TabFern and see if I can reproduce the problem. The "complex" tabs moved to their own windows:
|
It seems I did manage to get two tabs on different windows to be in bold typeface in TabFern list at the same time. |
OK, the "Unsaved" windows just happened. Still not sure what made it happen; but it only happened to tabs from 1 window (both "complex" and "normal" web apps) and the second window kept all tabs named. The tabs on the "Unsaved" windows are exactly same as when I opened and I did not interact with them much - but I did browse to several sites on new tabs and closed the tabs (and a new window with new tabs). So now I have same tabs in the 2 "Unsaved" windows as I did before Windows restart. Will continue to narrow the tabs/sites down... Edit: I closed a new window with 4 tabs with alt-F4, now the whole window is still in tabfern as "Recovered tabs" with the 4 tabs contained therein - is this as designed? |
Thanks for the updates. Bold text sometimes has issues because of how Chrome reports focus changes, and I'm not sure I can get it rock-solid. Alt+F4 is a new one on me - I'll give it a try. I suspect that means Chrome isn't shutting down the TF window cleanly. Do you have the Fast Close option set? I know that causes problems with TF. |
If you mean the Chrome flag "#enable-fast-unload" then no - it is disabled. |
I think I found the problem. The act of moving a tab from a window to another makes both recipient and destination windows to become "Unsaved". Edit: additionally, moving a tab out of a window to become a new window (tab moved out of a window, destination is new window and not an existing window with tabs), and then hitting Alt-F4 does in some case make the just-closed window to become "Recovered tabs". |
@bluikko Thanks for the updates - please keep me posted if you learn anything else. Also, if you see any warning or error messages in the TabFern developer console when the problem occurs, please send those (click on the TabFern window and hit Ctl+Shift+I). I have not been able to reproduce the moving-tab-between-window problem in 0.2.0-pre.1 (is that a good thing?). I am buried at work at the moment, but will get back to testing this as soon as I can. |
@bluikko I hope all is going well! Alt+F4 appears to be working for me on recently-released v0.1.17. Are you still experiencing the problems you were seeing earlier in the year? |
Currently on 0.1.16 tabfern there is a slight inconvenience regarding "merging" (?) of windows, referenced in #55.
All windows (and tabs therein) are now correctly recovered after Chrome restart/Windows restart/Windows bluescreen - I tested those. After Chrome is started again, all windows+tabs are listed correctly and with windows having their set names.
But, when the windows are re-opened by clicking on them in tabfern, tabfern opens them as new "copy" of window+tabs named "Recovered tabs", instead of opening the previously closed (and named) tree.
Is it by design that the old window stays in a closed state in tabfern tree and a copy of it as new window is created?
The inconvenience is that I need to delete the old windows and give the name again to the "Recovered tabs" windows, to continue browsing from the pre-restart state.
If this is by design, could there be another button "open as this window" in addition to the default "open as copy window"? Or maybe configuration setting?
I would assume most people want to not "clone"/"copy" the old named windows on re-open. I would assume they would want to continue browsing with the old window.
The text was updated successfully, but these errors were encountered: