command-a in url box is mistaken for control-a, and opens all the sleeping tabs in a window #847
Comments
|
@jpbianchi I can reproduce this. It's a strange bug. Unfortunately, the handling of hotkeys is outside of my control. All I receive within the extension is a message to say that that particular hotkey action was triggered (incorrectly in this case). I know it's a pain, but perhaps your best option is to change the keyboard shortcuts you're using? |
|
Thx for looking into this.
After reading the link, I modified Chrome's 'Select All' command into
command-shit-A in System Settings -> Keyboard -> Shortcuts -> App Shortcuts.
I tested it outside the url box, and the new command works, and command-A
does nothing anymore, so the custom hotkey works, but now inside the url
box, command-A highlights all the text (it shouldn't) and leaves the tabs
alone, but command-shit-A triggers ctrl-A, and unfreezes all the tabs.
So, it really looks like a Chromium bug affecting the url box. But this
wasn't happening some time ago, but I can't tell you since when this has
started happening, prob a week or two. I do a lot of url copy/paste, I
would have noticed.
I'll try to live with the new custom hotkey.
Another thing I mentioned was the extreme CPU load when your app reopens
all the tabs. I agree, in this window, there's prob 60 tabs, but still. And
ctrl-s doesn't seem to work before all the tabs are re-opened. Maybe that's
something you could change so a quick ctrl-s stop the bug in its track.
Thx again, great app btw, you shouldn't give it for free
…On Mon, Feb 4, 2019 at 12:26 AM Dean Oemcke ***@***.***> wrote:
@jpbianchi <https://github.com/jpbianchi> I can reproduce this. It's a
strange bug. Unfortunately, the handling of hotkeys is outside of my
control. All I receive within the extension is a message to say that that
particular hotkey action was triggered (incorrectly in this case).
Possibly related to this chromium bug:
https://bugs.chromium.org/p/chromium/issues/detail?id=890418
—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
<#847 (comment)>,
or mute the thread
<https://github.com/notifications/unsubscribe-auth/AfTsGdH3gu5RV89Lz8myx3h1NxC0IC0Yks5vJ3AUgaJpZM4acnsv>
.
|
|
@jpbianchi For the CPU load issue. It sounds like this is happening when you accidentally unsuspend all your tabs? If this is the case, it's really a chrome issue, there's not much I can do about it unfortunately (the CPU load I mean). I'll investigate whether I can somehow interrupt the tab loading and force the tabs to suspend quickly. |
|
Yes, it happens when I accidentally unsuspend all the tabs. I know it's
Chrome reloading the tabs, but it's your app telling Chrome which tabs to
reopen right?
So maybe telling Chrome in a timely manner would help, which also would
allow you to interrupt it when the user hits ctrl-S.
Thx for your help and consideration
…On Mon, Feb 4, 2019 at 11:55 PM Dean Oemcke ***@***.***> wrote:
@jpbianchi <https://github.com/jpbianchi> For the CPU load issue. It
sounds like this is happening when you accidentally unsuspend all your
tabs? If this is the case, it's really a chrome issue, there's not much I
can do about it unfortunately (the CPU load I mean).
I'll investigate whether I can somehow interrupt the tab loading and force
the tabs to suspend quickly.
—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
<#847 (comment)>,
or mute the thread
<https://github.com/notifications/unsubscribe-auth/AfTsGVkScpjDvIKYDhlpaa6IOPGwzGmeks5vKLpdgaJpZM4acnsv>
.
|
|
I have just committed a change that allows tabs to be suspended even during loading. This should help somewhat when trying to stop all your tabs from reloading (v7.0.165). It seems that you are also suggesting that I stagger the unsuspending process when unsuspending a large number of tabs at the same time? This is a little off topic for this issue. Would you mind creating a new issue for this (as a feature request)? Thanks! |
|
Hey, thx for making that change so quickly. I'll test it.
Staggering the unsuspending lots of tabs was just a suggestion, but a
useful one I think since crazy chrome almost freezes the computer for 2
minutes, so I'll be happy to request that feature.
Thx again.
…On Tue, Feb 5, 2019 at 12:45 PM Dean Oemcke ***@***.***> wrote:
I have just committed a change that allows tabs to be suspended even
during loading. This should help somewhat when trying to stop all your tabs
from reloading (v7.0.165).
It seems that you are also suggesting that I stagger the unsuspending
process when unsuspending a large number of tabs at the same time? This is
a little off topic for this issue. Would you mind creating a new issue for
this (as a feature request)?
Thanks!
—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
<#847 (comment)>,
or mute the thread
<https://github.com/notifications/unsubscribe-auth/AfTsGeDQyTwfyB8aIwmS7N2D5-tfQY80ks5vKW7dgaJpZM4acnsv>
.
|
Please complete the following information when submitting a feature request or bug report.
It's been some time now that, when I want to select a whole url by clicking in the url box and do the usual command-a, Chrome does not, as it should, select the text at all but unfreezes all the frozen tabs in that window, as if I had typed control-a (which is my setting to do that).
It's as if the extension confuses command and control when the cursor is in the url box.
This is new, I never had this problem for a long time so I don't know what changed.
It's not a huge problem, very annoying, and when chrome re-opens 60 sleeping pages at once, my 12 cores get used up to 85% for quite some time. If I type ctrl-s to freeze all the tabs to try to stop the problem, nothing happens, the extension continues re-opening all the tabs.
So far, this happens only when the cursor is in the url box. When I do command-a everywhere else, the problem does not happen.
The text was updated successfully, but these errors were encountered: