Đánh giá cho TabWalk
TabWalk bởi Giorgio Maone
9 đánh giá
- Xếp hạng 5 trong số 5bởi m3n3chm0, 7 tháng trướcThis addon is awesome if you deal with more than 50 tabs in your day 😊👌
Thank you very much! - Xếp hạng 5 trong số 5bởi KxNdrLXKSUPmcImWBIYhr, 5 năm trước
- Xếp hạng 5 trong số 5bởi Mr. Qwerky, 5 năm trướcVery 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.
- Xếp hạng 5 trong số 5bởi Người dùng Firefox 12836793, 6 năm trướcThanks, should be a base feature of Firefox
- Xếp hạng 5 trong số 5bởi Người dùng Firefox 15527990, 6 năm trước
- Xếp hạng 5 trong số 5bởi sojusnik, 7 năm trướcWorks 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.
- Xếp hạng 5 trong số 5bởi HannahVernon, 7 năm trướcWorks 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.Phản hồi của nhà phát triển
đã đăng 7 năm trướcThank 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.