Κριτικές για το TabWalk
TabWalk από Giorgio Maone
9 κριτικές
- Βαθμολογία 5 από 5από m3n3chm0, ένας χρόνος πρινThis addon is awesome if you deal with more than 50 tabs in your day 😊👌
Thank you very much! - Βαθμολογία 5 από 5από KxNdrLXKSUPmcImWBIYhr, 6 χρόνια πριν
- Βαθμολογία 5 από 5από Mr. Qwerky, 6 χρόνια πρινVery handy. Though the description doesn't tell you, the shortcuts may be edited on your Add-Ons page. I changed mine to Ctrl-Alt-Arrow, as it is slightly easier to reach than Shift-Alt-Arrow; and nicely matches Alt-Arrow which move back/forward in the tab's history.
- Βαθμολογία 5 από 5από Χρήστης Firefox 12836793, 6 χρόνια πρινThanks, should be a base feature of Firefox
- Βαθμολογία 5 από 5από Χρήστης Firefox 15527990, 6 χρόνια πριν
- Βαθμολογία 5 από 5από sojusnik, 8 χρόνια πρινWorks great! Would be even better, if it would be possible to switch tabs with Ctrl + ^ (the key above "tab" and to the left of "1" on a German keyboard). In this way Ctrl + "tab" would switch sequentially and Ctrl + ^ chronologically.
- Βαθμολογία 5 από 5από HannahVernon, 8 χρόνια πρινWorks perfectly as advertised. Only applies to tabs that have been opened after you install the add-on - i.e. it doesn't know about tabs that were already open prior to installation. Also, CTRL + [Arrow Key] is commonly used to skip between words when entering text, this add-on overrides that functionality, so it would be great if you could have an option to use CTRL + ALT + [Arrow Key] for tab-switching functionality.
As you said in your reply below, checking to see if the caret is inside a content-editable element might work perfectly to allow the CTRL + [Arrow Key] functionality to work as expected when editing content.Απάντηση προγραμματιστή
δημοσιεύτηκε στις 8 χρόνια πρινThank you for your feedback. No way to know "tab usage history" for the add-on until it's installed, as there's no built-in API for that and so tab selections must be tracked with custom code. Nice hint about the overridden text-editing functionality, I completely overlooked it: maybe a solution would be checking whether a content-editable element is currently focused and ignoring the keystroke in that case.