Mousewheel scroll on tab bar should change tab in Suiterunner

RESOLVED DUPLICATE of bug 643294

Status

()

RESOLVED DUPLICATE of bug 643294
11 years ago
8 years ago

People

(Reporter: InvisibleSmiley, Unassigned)

Tracking

Trunk
Points:
---

Firefox Tracking Flags

(Not tracked)

Details

Attachments

(1 attachment)

(Reporter)

Description

11 years ago
User-Agent:       Mozilla/5.0 (Windows; U; Windows NT 5.1; de-AT; rv:1.8.1.11) Gecko/20071128 SeaMonkey/1.1.7
Build Identifier: Mozilla/5.0 (Windows; U; Windows NT 5.1; de-AT; rv:1.8.1.11) Gecko/20071128 SeaMonkey/1.1.7

See Bug 356675: Switching the active tab through the use of the mousewheel was implemented for XPFE builds. That improvement was lost through the transition to Toolkit.

Reproducible: Always
(Reporter)

Updated

11 years ago
Depends on: 356675
Version: unspecified → Trunk

Updated

11 years ago
Status: UNCONFIRMED → NEW
Ever confirmed: true

Comment 1

11 years ago
Created attachment 321346 [details] [diff] [review]
updated patch for toolkit

just helping (I hope) by porting the previous patch forward. tested it and it works for me
(Reporter)

Comment 2

11 years ago
(In reply to comment #1)
> just helping (I hope) by porting the previous patch forward. tested it and it
> works for me

I can confirm that your patch works. :-) I think that the real file to be patched is /toolkit/content/widgets/tabbox.xml, though. Your patch seems to be against the packaged file (toolkit.jar).

So, I guess this is a toolkit bug/RFE then? Who needs to be consulted whether this can go in (given that adapting the patch to the real file is easy)?

Comment 3

11 years ago
Changing to Toolkit->XUL Widgets
Assignee: guifeatures → nobody
Component: XP Apps: GUI Features → XUL Widgets
Product: Mozilla Application Suite → Toolkit
QA Contact: xul.widgets

Comment 4

11 years ago
Comment on attachment 321346 [details] [diff] [review]
updated patch for toolkit

>-          var next = startTab[aDir == -1 ? "previousSibling" : "nextSibling"];
>+          var next = aDir < 0 ? startTab.previousSibling : startTab.nextSibling;
>           if (!next && aWrap) {
>             next = aDir == -1 ? this.childNodes[this.childNodes.length - 1] :
>                                 this.childNodes[0];
Fortunately this particular line of code doesn't have a problem because aWrap is never true during a mouse scroll, but this function then calls _selectNewTab which also compares aFallbackDir == -1 which would fail in this case, so you should fix all the == -1 tests for consistency.

On a side note I wonder why toolkit fiddles about with childNodes instead of using the first/lastChild properties.
(Reporter)

Comment 5

11 years ago
It only occured to me now that if this is actually changing Toolkit files we'd either have to go for a global solution (i.e. one that FF people accept) or somehow make it SM-specific. As far as SM is concerned, this had already been implemented for XPFE builds, thus it's a regression. Looking at that XPFE bug 356675 you'll see in the initial comment that there are bugs for both core (bug 108524, WONTFIX'd) and FF (bug 281192, including patches against tabbox.xml and adding a pref) but that the latter was considered to be unneccessary for SM. I don't know how to proceed here. :-/

Updated

10 years ago
Duplicate of this bug: 408173
another totally forgotten bug?
There is an extension, called Tab Wheel Scroll - maybe it's possible to copy some part of it's code to make the patch for this bug?

Comment 8

8 years ago
Now that bug 484968 is fixed, the scrollable tabbar eats the wheel events.  But on Linux builds, you can still use the scroll wheel to change tabs, as long as you hover over the tab picker or the new or close tab buttons.
(Reporter)

Comment 9

8 years ago
(In reply to comment #8)
> Now that bug 484968 is fixed, the scrollable tabbar eats the wheel events.

Yeah, one of these cases where one groups wins and one loses, and I'm in the latter group though I was first (as far as SM is concerned). :-(

> But on Linux builds, you can still use the scroll wheel to change tabs, 
> as long as you hover over the tab picker or the new or close tab buttons.

Ah. I wonder whether that can be extended to work on all platforms, maybe with a modifier like Ctrl (Accel).

If everything goes wrong we can resort to providing an extension for this but I'd surely appreciate it if it was fixed in the application (so that the extension doesn't break in the future).
(Reporter)

Comment 10

8 years ago
Workaround: I just discovered that the following add-on works with both SM 2.0 and latest trunk (so quite probably also with 2.1 final):
<https://addons.mozilla.org/de/seamonkey/addon/tab-wheel-scroll/>
(Reporter)

Comment 11

8 years ago
So, since I originally filed this for SeaMonkey and it has been fixed for that now in bug 643294 (thanks Ratty!), I'm duping this bug to that one. IFF anyone's interested in having this for Firefox, please open a new bug for that if none exists yet.
Status: NEW → RESOLVED
Last Resolved: 8 years ago
Resolution: --- → DUPLICATE
Duplicate of bug: 643294
Since the bug is alive in Firefox and there's no need to file a new one, just undo the status reset from "duplicate" to "new" for this bug.
(Reporter)

Comment 13

8 years ago
(In reply to comment #12)
> Since the bug is alive in Firefox and there's no need to file a new one, just
> undo the status reset from "duplicate" to "new" for this bug.

That's not the point. Some facts:
1. I reported the bug so I receive all bugmail for it
2. As the summary indicates, this was a request for Suiterunner (an intermediate version of SeaMonkey) and was only moved to Toolkit since SeaMonkey's move to it was what regressed it
3. The actual issue has only recently been fixed for SeaMonkey, just in another bug
4. Filing bugs is cheap.

So from a SeaMonkey perspective, both bugs really are the same, thus the duplicate resolution. If however this is transformed into a bug/request for Firefox, there will likely be a (lengthy) discussion whether or not to do this at all (for Firefox). To be honest, I'm not interested in that discussion at all, yet I'd receive all comments added to this bug. I'd have to filter out the whole bug in that case. For that reason, please take that to another bug.

The only valid reason for reopening this bug IMO would be if a decision would be made to actually do this for Firefox (with the discussion and decision happening elsewhere!) and fix it in Toolkit (so that SeaMonkey's overriding code could be removed). But even then this could be done in another bug.
You need to log in before you can comment on or make changes to this bug.