Tab-Wheel-Scroll
Tab-Wheel-Scroll copied to clipboard
mthamil
Port to WebExtensions
Mozilla has plans to remove non-WebExtensions addon support with the release of Firefox 57 (Developer Edition in August, Stable in November) so, if you need them to add a new API before you can port this extension, you have to get on Bugzilla A.S.A.P. and start the discussion about what it'll look like.
I really don't want to have to resort to X11-based "capture mouse input between these window-relative X and Y offsets if Firefox is in the active window class, then inject fake Ctrl[+Shift]+Tab keypresses" hackery to keep my muscle memory happy when that happens.
(I'm taking this very seriously.)
I've been periodically checking up on web extension developments to see whether an api has been made available that I could use. So far, I haven't seen one that fit the bill. I've been dreading this myself since I use so many extensions that I'm sure aren't going to be compatible. I will file an issue on Bugzilla and see what happens.
Unfortunately, I have to say: don't get your hopes up. The primary driver for api additions in this space are likely to be bigger addons like Tab Mix Plus. Maybe that will work out in our favor.
Still, it's important that you at least try to get them talking about it.
(I'd be sure to mention that your extension implements functionality that Chrome offers as built-in and default, which will become unavailable by any means in Firefox once XUL goes away.)
So I attended a triage meeting for add-on issues, and the bug was rejected. It was said to be out of scope since they don't intend to allow event handlers to be attached to UI components, particularly since extensions can run out of process. It was also stated that WebExtensions are focused on interactions with web content, not chrome elements. I brought up the existence of the current tabs api, but they don't intend to offer such functionality through the existing api.
I think I was the only attendee who showed up for this issue, which is disappointing, since other, larger extensions could possibly have thrown some more weight behind it. To me, it seems this focus will basically kill a large swath of add-on types.
They mentioned a "work-around" as creating my own UI element (ie. a sidebar) and controlling tab switching that way. I suppose that could be explored, but I'm not really a fan of this solution. Maybe a button could be added, but I don't know if you can even listen to scroll events on UI elements you create yourself. I see an example that listens to a click, but that is expected.
Here is a link to the meeting minutes.
Ugh. Looks like I'll have at least one reason to write an input proxy then. (And, as a result, one reason to avoid Wayland, since the technique overlaps with what keyloggers do.)
(ie. Something which monitors the active window, overlays a transparent window on the top X pixels of ones detected to be Firefox (I need to write code to watch changes to window position for QuickTile anyway to fix long-standing bugs), and allows most events through to the window below, but translates wheel events into synthesized Ctrl[+Shift]+Tab keypresses.)
(Because it'll be less ongoing work than maintaining my own patched builds of Firefox as updates roll out.)
Bug 1285812 is about offering this as part of the browser itself and the last comment seems to indicate that the issue is lack of priority rather than lack of willingness to accept the feature. (ie. The last comment boils down to "If you want it so badly, write a patch or pay someone to do it.")
Personally, I use a lot of add-ons and most of them are NOT related to web content, so this shift in focus is a big blow to usability for me.
I'm lucky in that most of what I want from Firefox falls into one of the following categories:
- Default (I made my Firefox's UI Chrome-like before it was cool)
- Offered via
about:config(eg. un-hidinghttp://and remembering the download directory on a per-origin basis) - Can be worked around using input proxying (eg. scroll-wheel tab switching)
- Can be retrained (eg. Tapping Alt to show the "must be retained for the OSX port" menu bar rather than reaching for the menu button I currently get via Classic Theme Restorer.)
- Will actually be better once the browser only hosts a thin integration shim for an external application (eg. I'm designing a PIM tool where browser bookmarks and saved sessions are just two filter views into the same, much-broader data store)
- Content-oriented (eg. uMatrix, AMO's policy of requiring ported Chrome WebExtensions to disable their analytics if they're running under Firefox, etc.)
That said, if QWebEngine ever gains support for WebExtensions, I'm dropping Firefox like a hot potato in favour of maintaining my own PyQt-based browser frontend.
Is there any hope to see this extensions ported to the new WebExtensions API ?
Unfortunately, no. Mozilla has determined that the sorts of changes that would be required to surface the necessary functionality is out of scope of WebExtensions.
However, the last time (to my knowledge) it was discussed for inclusion in the browser itself, it was declined as "it can be done in an extension", so the next step would be to push them to reconsider that.
Given that, on Linux, this is a case of Firefox deviating from all other Linux applications including Chrome, I think a solid case can be made for including it in the browser itself.
https://github.com/eoger/tabcenter-redux/pull/109 may contain some useful information.
Tab-Wheel-Scroll uses advanceSelectedTab to find and switch to the next tab. As near as I can tell there is no such thing in WebExtensions, and the method is similarly not reproducible, which is why I ended up doing index modifying.
I appreciate the link, but I believe that is for a reimplementation of the tab bar as a sidebar. Since they are creating the UI elements, they can do pretty much whatever they want with it.
Given that, on Linux, this is a case of Firefox deviating from all other Linux applications including Chrome, I think a solid case can be made for including it in the browser itself.
Agree. They should consider adding a simple setting in Firefox itself.
Can you please pester mozilla to consider adding APIs for this or to just add this very useful functionality to the core (or even better: both)?! Being able to scroll through tabs is incredibly useful and it'd be a shame to lose this when old extensions go away...
Is it possible for web extensions to add .js-files to the userChrome-Directory? Then maybe you are able to get some inspiration here: https://github.com/ardiman/userChrome.js/tree/master/tabwheelscroll
I think userChrome.js is not something supported out of the box by Firefox. userChrome.css is, for now anyway. userChrome.js support was added by an extension as far as I can tell, and I'm pretty sure that would be a legacy addon now too.
For Windows users coming here for a workaround, there are now numerous AutoHotkey scripts doing this. My version also works if Firefox is not the active window: https://gist.github.com/fm3/e3d9f13dd368ec91b352071ba7ecb642 Are there any X11 wizards around who could make something like that for Linux? I believe there are AutoHotkey-like tools too? The good news is that 1285812 has an assignee now, let’s keep voting!
I have plans to do something similar for X11, but not immediately because Firefox's legacy extension support isn't the only thing that's going away on me, and the others have deadlines looming months closer than the end of support for Firefox 52ESR.
@fm3 1285812 has more than an assignee, it has a patch! I added that patch to my distro's package script and rebuilt the package, and it works great.
@Photon89 arch, but it hardly matters. Simply review your distro's method for automatically packaging firefox, then apply the patch either in the script or manually before building.
@RX14 : Actually, I am also an Arch user but the PKGBUILD doesn't look like it would apply any patch: https://aur.archlinux.org/cgit/aur.git/tree/PKGBUILD?h=firefox-extension-tabwheelscroll
@Photon89 no, I meant I modified the pkgbuild locally and built it, not that i'm a distro maintainer.
@Photon89 the pkgbuild you linked is for the extension, the extension is 100% dead forever.
The patch linked doesn't make the extension work, it adds the functionality into vanilla firefox with no extensions, and such you need to recompile the whole of firefox.
@RX14 - Mind sharing the patchfile for the PKGBUILD in a gist or something? (I'm aware it's probably quite small).
Check out the PKGBUILD from the ABS svn, cd into firefox/repos/extra-x86_64 and then apply the patch just by copying one of the other patch lines in prepare() and modifying it. The patch is available at https://reviewboard.mozilla.org/r/199738/diff/raw/.
If you can't figure that out, you probably shouldn't be building your own firefox :smile:.
If you're using Gentoo Linux, you can just put the patch from https://reviewboard.mozilla.org/r/199738/diff/raw/ in the folder /etc/portage/patches/www-client/firefox/ and then rebuild Firefox. This enables scrolling with the mouse wheel on the tab bar.
