-
-
Notifications
You must be signed in to change notification settings - Fork 27
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
window size/pos update only with correct values #192
Conversation
sync from upstream
When resizing/moving, now take window's infos from chrome.windows.get()
Thank you, and good question! I'll take a look. There are numerous places in the codebase that trigger ASQ sequences off Chrome callbacks, so I don't think ordering will be a problem if we need it. |
@Procyon-b I updated the logic in |
Just a quick remark before leaving keyboard (and before testing). |
I've just installed git, node.js & all, downloaded the latest code (easy, no problem), and tried. Picture this. I rarely maximize TF, but sometimes do it to view the dialog ("edit text"), or to view a particularly long tab's title. If somehow chrome gets closed, I'm in the same situation as I'm currently regarding the minimized values. |
Fair point. I was thinking of the flip side - if a person on a multi-monitor setup leaves TF maximized on one monitor, we would be throwing that away. I think we can:
What do you think? |
I understand why maximized could be important too. With the chrome window we get the Store the "state" parameter as well. Update it when value is "normal" or "maximized", ignore when it is "minimized". Then, when TF opens its window, add a step:
This way the user can go in and out of maximized mode while retaining the "normal" window size. Edit: |
@Procyon-b Sorry for the delay in responding!
I look forward to a PR update at your convenience! |
I had a big cold, and tonight I'm finally feeling ok. ;) |
Sorry you've been under the weather — glad to hear you're back on your feet! If you want to talk live sometime, we can discuss on Gitter if you like. |
I'm not forgetting but I had other things to do before this. ;) |
Question: |
@Procyon-b Thanks! No need to open a new PR. When you push your latest commit(s), GitHub will tell you if there are any conflicts. If not, I will be able to merge cleanly. If there are conflicts, either of us can add a commit to fix them. I am happy to do that if necessary. From a quick look at the commits since your branch split off, I don't anticipate any significant conflicts. At work, we have to merge/rebase/fix commits all the time --- this situation is not a problem :) . (Note: take a look at the network graph --- you'll see lots of places where parallel commits were merged together.) |
stores the correct values for size and position stores the state of the window restores the state of the window when TF is opened
PR updated. Here is how it works:
|
No conflicts :D . Thanks - I'll take a look! |
- The last saved geometry persists until the window has a different geometry _and_ is in the `normal` state. - The window is assumed to start out in the `normal` state, which seems to be what Chrome does. (Is it what Vivaldi does when the TF panel is docked, though?) - Bump the resize debouncing interval from 200 ms to 300 ms per my own empirical testing. - Added utility functions K.dups(), ErrorMessageString().
@Procyon-b I apologize for the long delay in looking at this! I agree with your approach of only saving The changes relevant to this PR are in 55524bd. I have merged in some unrelated bugfixes I made this morning, which is why there are five other commits before 55524bd in the PR now. Edit I have added a few explanatory comments in 55524bd. I hope they help! If not, please disregard them. |
I've completely forgotten about this. Sorry. |
No problem! That's what happens when neither of us is paid to work on this :D :D 😆 |
I'm back. My mind is lighter. I had an extension (Tiny Proxy) that was stuck in eternal "pending review"/"Rejected" state. :) I've tested this code, and it still works as expected.
|
I'm still using version 0.2.0. I'm using chrome with windows maximized (small screen). When I click in TF (no maximized) to open a saved set of tabs, it sometimes uses weird size values for the opened window.
I haven't look at the code, but could this be related to the problem we had to solve here? The actual size of the window is lost when the page is not |
Good point - that is very possible! The code was originally trying to simulate the Ctrl+N size/pos because of apparent Chrome limitations. First, I should check whether those limitations still exist. If so, code like this may be very helpful. Congratulations on finally getting your extension approved! I currently can't physically access my desk :) but will get this merged as soon as I can! |
It was approved, but updates where denied. In early december, the last approved update took 7-8 days to be accepted. The previous update, not too long before, was immediate. I've submitted the next update the day of the approval, but it took more than 10 days to be rejected. Fortunately the extension was not blocked. What is difficult is getting information from google. The email warning states that you can ask questions and the "developper support team" will follow up. The fact is that they don't. Except for replying with a similar error message. I even followed someone's advice by mailing another dev team. It was mid-december and the (nice) reply only came mid-january. But they couldn't help with that specific problem. I let it rest for a month (or more), and finally wrote a new email with very specific questions. The reply came with the usual error message, but with a little hint on which permission was at fault. But not why. So, I replace "activeTab" with "<all_urls>" and after 5 days of review, the update was accepted. In fact I don't think that they know exactly what they have to do. When submitting the new update, the dev dashboard asked me if I didn't want to replace "<all_urls>" by "activeTab". Which is contrary to what I was asked/hinted to do by the support team. What could have made a difference is that I had to fill the "privacy" form of that extension in the new dashboard interface. There you can comment/explain each permission. Comments that are passed to the reviewer. |
Wow --- crazy! Thanks for the tip --- I will make sure to fill in the privacy section if I ever have to change permissions. |
Note that when the update was rejected, the manifest hasn't been modified. Only some bugs fixed in options.js and background.js. |
If you want to know this is the online help. |
I have merged this into the current rc branch for testing! |
[off topic] In the old dashboard, they have replaced the link to the new dashboard with an "opt-in now" link. Fortunately there is an hidden "opt-out" link in the new interface. |
Thanks for the tip! I will do likewise. |
TF |
0.2.1 is pending review - fingers crossed! I'm not going to tag or merge to |
Fixes #189.
eventOnResize() and timedResizeDetector() use chrome.windows.get()
then
getWindowSize(window);
replaced bygetWindowSizeFromWindowRecord(cwin);
Only basicInit() (from main() ) still uses getWindowSize().
Since all things must be done in order, and chrome.windows.get() is async, if we decide to also use a cwin there, is there a danger of
newWinSize
being read during main() before it is actually set?