User Help for Seamonkey and Mozilla Suite
I can't find any setting to disable the newly introduced tab scrolling with mouse wheel, to avoid unintended scrolling (jumping) to another tab, when I touch the mouse wheel.
I find it annoying too.
Maybe something here, [url=http://kb.mozillazine.org/About:config_entries#Mousewheel.]Mousewheel.[/url] ?
(The board is breaking the link. The closing dot (.) in the URL is important for the jump to the "anchor" to work.)
Mozilla/5.0 (Windows; U; Windows NT 6.1; en-US; rv:184.108.40.206) Gecko/20110420 SeaMonkey/2.0.14 Pinball CopyURL+ FetchTextURL FlashGot NoScript
Err, great ... so, how do you override a single handler (event="DOMMouseScroll" phase="capturing") in a binding (id="tabbrowser-tabs"), e.g., using the userChrome.xml extension? The install.rdf of that extension doesn't include SeaMonkey, but should be straightforward to copy-paste.
One could probably create a complete copy of the binding as a userChrome.xml definition with that handler omitted, or maybe it's possible to just extend the existing binding overriding the handler with an empty one, but this looks like a little bit of try and error to make it work...
Edit: https://addons.mozilla.org/seamonkey/addon/tab-mix-plus/ redirects to Firefox, thus it's not declared compatible with SeaMonkey.
As a quick guess (completely untested!), the following might work as a userChrome.xml definition:
assuming that handlers can be overridden in this way, combined with the following in userChrome.css:
For the User Chrome extension, add an entry to install.rdf for SeaMonkey with this UUID (taken from DOMi):
Well, that didn't work. It's failing already when trying to simply open a new tab:
That's in the "tabbrowser" binding, apparently the extending part didn't work and the method definitions for "tabbrowser-tabs" are gone entirely despite supposedly being inherited from the underlying base binding...
Anyway, maybe a good starting point for anyone who wants to pick this up. The other option (for experienced users) is obviously to just hack omni.jar and to remove the "DOMMouseScroll" handler from "tabbrowser-tabs" manually.
It appears that the User Chrome extension itself may not be working correctly, possibly related to the switch to omni.jar as common JAR file. It seems to be searching for userChrome.xml as part of the extension itself. Typing in the chrome: URL from the userChrome.css file manually gives me the following error:
Thus, it may be ignoring the "../.." part in chrome.manifest for some reason. Making it "../../../.." didn't help either.
Ok, so as a last attempt I've added chrome/userChrome.xml directly into the extension and it is now found when directly entering the chrome: URL, so that part worked, and it should be found with the userChrome.css code now. It's still happily scrolling tabs though, thus the handler-overriding part still didn't work out for some reason. I'm giving up at this point...
One subproblem solved thanks to Bozz: To allow chrome.xpi install "the old way", go into about:config and toggle extensions.alwaysUnpack so that it becomes "true", then the userChrome.xml file can go into the "chrome" folder again and is properly found there.
It appears to me that the <handler> definitions are executed for both the code of the base binding as well as of the extending binding. For example, adding "<![CDATA[throw(9999);]]>" as the executable content to that handler will still execute the tab scrolling and throw an "uncaught exception 9999" from the additional code in the extended binding. Thus, it may not be possible to override handlers with such custom bindings in general.
Hah, I've got an "evil hack" utilizing that parallel behavior by simply compensating for the action in the main binding with a counteraction in the extended binding (copied from Phil's patch and reversed):
In result, the tab scrolls one to the left and then immediately to the right, or first to the right followed by an immediate to the left. This works for all intermediate tabs, for the left-most tab you can have one scroll to the right though; and, for the right-most tab, one scroll to the left. That probably could be accounted for by really checking on which tab we are and which action is to be performed, thus not counteracting a "no-op" action of the main binding because it's the first or last tab.
Here yet another not quite working solution. This one doesn't try to avoid handling the events but basically just removes the action defined for "this.advanceSelectedTab()" so that the events are practically ignored. Unfortunately, it seems to affect more than desired and has some unexpected effects (uneven tab sizes, no [x] closing box, etc.), so that's not usable in this form yet either, but here the code:
Last edited by rsx11m on June 24th, 2011, 6:06 pm, edited 1 time in total.
Ok, this is better. The suite's "tabbrowser-tabs" extends in tabbox's "tabs" itself, thus extending the former rather than the latter (even though the latter inherits the "advanceSelectedTab" definition from the former) restricts the change to the actual tabbrowser tabs and won't disable the suite-specific "tabs" extensions. In addition to the mouse wheel, this solution also prevents navigating the tabs with the cursor-left/right keys, though.
userChrome.css: (updated per Mc.'s feedback on tabmail issues)
Last edited by rsx11m on June 25th, 2011, 9:33 am, edited 2 times in total.
With this code tab bar is not visible at all for me, even with just your code in userChrome.css (and userChrome.xml in the profile).
Who is online
Users browsing this forum: No registered users and 2 guests