Closed Bug 76537 Opened 23 years ago Closed 20 years ago

Mozilla should support mouse gestures

Categories

(SeaMonkey :: UI Design, enhancement)

enhancement
Not set
normal

Tracking

(Not tracked)

RESOLVED WONTFIX

People

(Reporter: bischoff, Assigned: bugzilla)

References

()

Details

(Keywords: helpwanted, Whiteboard: parity-opera)

Attachments

(1 file)

2.93 KB, application/octet-stream
Details
From Bugzilla Helper:
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:0.8.1+)
Gecko/20010417
BuildID:    2001041704

As mentioned on Slashdot today, Opera now supports mouse gestures for navigation
(http://slashdot.org/article.pl?sid=01/04/18/1245245&mode=nested). "You can
perform a bunch of common actions with simple gestures, such as holding down the
right mouse button moving left and releasing to go back, or moving up then down
while holding the button to reload the current page."

The complete list of gestures (about a dozen) are listed on Opera's site
(http://www.operasoftware.com/windows/mouse.html). I think this could make for a
large boost in browser usability. And, the gesture configuration that Opera uses
makes sense, so Mozilla could even implement those same settings.

Reproducible: Always
except right mouse button should bring up a context menu and allow you to move
the cursor to select context menu items...
Boris: that's right. Gestures could only be used if the user doesn't release the
mouse button (see url for examples, if this doesn't make sense). But,
click-and-release would bring up the context menu, as normal.
If you've noticed, click-hold _also_ brings up a context menu in mozilla. 
Context menus should not require two clicks.
I can only speak for the win32 build but, at least there, I can't trigger the
context menu through click-and-hold. On the other hand, I am aware that Mac
Mozilla uses click-and-hold (and perhaps other non-win32 platforms).

But, this functionality isn't mutually exclusive to mouse gestures. If someone
clicks-and-holds without moving the mouse, then it would make sense to see the
context menu. However, if the user issued a gesture (while holding), but did so
before the context menu appeared, then the gesture could be activated.
The whole point of right-click-and-hold bringing up the context menu (it does
this on linux, btw) is that you can start moving toward the menu item before the
menu is even up... on mac things are even more confusing, since there is only
one button and click-hold can mean context menu or drag depending on mouse
motion.  Fitting in gestures could be interesting.

Which is why I've cced mpt, so he can address the UI aspects of this.
I think that we could implement something like this if we actually popped up 
pictures around the mouse and had the user release over one of them.

it would probably look a bit messy, but you'd end up w/:
        *        *
  Close   Home     Maxim
*                        *
  Minim   cursor  /-Menu-\
*                 | ...  |
  Clone   Reload  | ...  |
        *        *
This ascii art is not drawn to scale, the buttons would probably be square in 
aspect with (three? timees) more whitespace between them than they take up.

If the mouse hits any of the * regions, the buttons and their 'gesture' 
functionality should go away.

This way you could still create selections.
confirming rfe.
Status: UNCONFIRMED → NEW
Ever confirmed: true
Um...this is weird.  I can't see myself getting used to this, but I'll have to 
try out Opera.  Anyways, I don't think I'll be doing this any time soon, if 
ever...lamenting Bugzilla's inability to store bugs without owners and 
reassigning to nobody@mozilla.org.
Assignee: blakeross → nobody
Keywords: helpwanted
I'd prefer 4.x-style gestures (bug 49844).
Mine.

I think the best way to implement this, in the short term, would be to fix two 
bugs: bug 49844 and bug 75338.
Assignee: nobody → mpt
Component: XP Apps: GUI Features → User Interface Design
QA Contact: sairuh → zach
Matthew: I agree that fixing bug 49844 (please!) and bug 75338 could be a good
compromise for the short term.

Timeless: Your ASCII art is a pretty good representation of mouse gestures. Even
better, though, as some of the multi-direction gestures
(http://www.operasoftware.com/windows/mouse.html). For instance, Opera supports
"move up, then down" (while holding down the secondary mouse button) for Reload.

Another handy gensture -- but one without mouse movement -- is "Back" via "hold
secondary button and press primary button" ("Forward" is just the reverse). I
wouldn't think this would be too hard to implement either :).
I only drew the gestures that made sense based on my bias.  [Which is really 
something like: I don't want gestures that can't be seen as clicking on 
buttons.]

The back/forward by abusing mouse clicks is something i really don't like.  
Microsoft has a "better solution": more mouse buttons.
As someone who has used both Black&White and Opera, I can say that gestures are
indeed an ingenius way of doing things. If the right mouse button is only going
to bring up the context menu on mouseup, then this feature could be implemented
very easily and still leave the context menu working. In Opera's implementation
(One that I feel is very good, but still needs more) the first time a user uses
gestures, it pops up a window asking whether they want to use them. This way
people who accidentally make a gesture don't do something drastic. (like
minimize the window :-) 

We could implement the same idea quite easily I think. We might even be able to
do it all in Javascript in the front end as well. I believe it is possible to
detect an OnMouseDown event and track the coordinates where the mouse moves.
Using that, we can make simple calls to history.go(-1) or history.go(1) -- I
think those are right...
and for reload it would work similarly. The problem I see is determining when to
show the context menu and when not to. If a gesture is made, and gestures are on
then the context menu should not pop up. Otherwise it should. (although i still
wish it popped up on mouse down)
For the Opera feature where a link is opened in new window (The greatest thing
in a browser.) We'd need to know not to bring up the link context menu.
(If you don't know, the gesture is right-drag down till over a link and let go)

The idea of a menu at the compass directions on mouse down is another intriguing
idea. You could make it almost of a shortcut to the shortcut menu.
right-click-down and you get a list of the/your four most used features... then
release and get the full right-click menu, or move over a choice and release to
choose it. 
Why don't use middle button for gestures instead of right one?
It will leave the context menu as it is, and allow for gestures too.
Or maybe it should be a configurable item:

Follow link => Button 1
Context => Button 2
Gesture => Button 3
as default, but possibility to change this
1)  There is not always a middle button on mice
2)  The middle button already has various mappings (including paste and "open in
    new window") on Unix
for reference also see Sensiva's implementation of mouse gestures at
http://sensiva.com

Well, it's beyond me to figure out the XP context menu stuff, but I have a fancy
to give this a shot. In such a way that the activation semantics are easily
configurable, of course, so people can argue about them all they want.

Don't want to scare off any other volunteers: I have to get friendly with XPCOM
first. Hopefully that won't take too long. Perhaps PyXPCOM...

Anyway, I'll let the list and this bug know when and if I'm ready to roll.
Attached file mouse gesture using DOM —
I've created attachment with DOM implementation of Mouse Gestures for Mozilla.
Check it out. Some insider should take over it, because I don't know Mozilla's
internal working in this field, so I can't create a valid patch. Hope you'll
like it.
--mondo
That attachment is zip file. Sorry for the spam.
I was skeptical about gestures until I tried it in Opera and got immediatly
hooked. Browsing fast with the mouse only. Not reaching ui buttons or menus. I
think it's great and people should try it before dismissing it. Really impresive
stuff and improves user experience. Also not very hard to learn for a user. I
tried the JS patch posted by Pavol Vaskovic and it's looking goog for a first JS
only try, to me that knows nearly nothing about mozilla anyway.  I modifed it to
be able to actually try it on 2 pages, and with only back, forward & reload,
it's nice.
Keywords: oeone
I've taken Pavol's patch and made it a toolbar.  I'll upload the XPI when I get 
a bit further (some doCommand invocations left), but you can get it and monitor 
status at http://surfmind.com/mozgest/
Optimoz project on MozDev is implementing this bug. See
http://optimoz.mozdev.org/gestures/
Version 0.3 is very usable. But to implement all the features that has Opera, we
are lacking support for minimizing, restoring and maximizing window. That's
because this functionality is not exposed in any XPCOM component/interface. That
is bug 30529. Therfore marking dependance.
--mondo
Depends on: 30529
FWIW, the freeware win32 program "StrokeIt" gives gestures support for Windows
in general, but also Mozilla specifically: http://www.tcbnetworks.com/strokeit/
I don't think this should be built in to Mozilla.  There are add-on programs
already that supply this functionality, like the one mentioned in comment 24. 
This, in my opinion, is a geek feature that does not apply to a large enough
segment of the population to warrant the added overhead of Yet Another Feature.
Marking wontfix.
I think Blake's right.  It's definitely not something everyone or even a
majority of people would want when I look back at it now.  I think it can be
perfectly fine remaining as an XPI installer as all the hooks seem to be
available in mozilla since bug 30529 is fixed now.

My only complaint about this is that each time I install a mozilla build I have
reinstall all additional xpi addons, correct?  Although, this really isn't the
place to talk about this, as it's a separate issue.

CC'ing myself and removing my vote.
Keywords: mozilla1.0
Keywords: oeone
A 2002 CHI paper suggests that gestural navigation, at least for "back", is 
efficient and highly liked by users.
http://www.cosc.canterbury.ac.nz/~andy/papers/shortCHIGesture.pdf

The http://optimoz.mozdev.org/gestures/ add-on has the following goals prior to 
a campaign for inclusion in the tree:
  * Convert to JS Service
  * Add support for mail, chatzilla, and composer
  * Provide API for other applications to use gestural commands
  * Provide robust way for users to customize gestures
At the risk of creating a bloated browser, I think this really does need to be a
built-in feature. Mouse gestures was the feature which switched me back to
Mozilla, and if you look at the OptiMoz guestbook, everybody rants positivly
about the feature.

<rant>
It is these types of features that Mozilla needs to make it surpass other
browsers. Leaving features as 'add-ons' makes them seem to ordinary users
like... well... an 'add-on'; easily overlooked by users briefly checking out
Mozilla.

If you really boil it down, the lack of them in the default installation may
make the difference between a Mozilla user and an Internet Explorer user.

MultZilla was merged into the official codebase and is now loved by (almost)
all, why not OptiMoz?
</rant>
> MultZilla was merged into the official codebase

As a digression, is that true?  I thought it got
re-implemented due to NIHism.
i'd love to see this feature too :)
MultiZilla was not integrated into Mozilla, as I understand it, primarily 
because it was ridiculously complicated for a mass-market browser. The same 
applies, currently, to OptiMoz.

I think having gestural navigation in Mozilla would be a good idea, because it 
is both useful and invisible.

Mini-spec:
*   During normal selection of text with the mouse, do not begin highlighting
    the selected text until 0.5 seconds has passed since the mousedown. (This
    shouldn't be noticable normally, but it will prevent weird artifacts while
    performing gestural navigation.)
*   Go Back when the mouse is jerked left while the primary mouse button (e.g.
    the left button) is down for less than 0.5 seconds.
*   Go Forward when the mouse is jerked right while the primary mouse button is
    down for less than 0.5 seconds.
*   Do not have any other gestures in the initial implementation. At all.
*   *Never* have any gestures for window management, because the inconsistency
    of Mozilla windows responding to such gestures while other windows did not
    would be considerably worse than no windows responding to them at all.
*   Do not have any prefs for it. At all.

--> XP Apps: Drag and Drop
Assignee: mpt → blaker
Component: User Interface Design → XP Apps: Drag and Drop
QA Contact: zach → tpreston
I'm also for integrating the mouse gesture of Optimoz into Mozilla. It is
already working nearly perfect, however, it would work better as native
component (right now it's a pure XUL/JS implementation). The main problem is
right now that Optimoz can't prevent that the context menu opens on Linux/UNIX

http://optimoz.mozdev.org/gestures/index.html

Why can't this go into Mozilla, but I-Search can???

http://bugzilla.mozilla.org/show_bug.cgi?id=30088

I see not how I-Search is a much different component than Mouse Gestures (it's
keyboard gestures so to day).

And I'm also for window gestures. I love to be able to minimize and maximize the
window, even if the window title bar is hidden by another window at the moment
(I'm using X-Mouse in Windows and a window can have focus without being on-top).
I also love it to close Mozilla, open tabs and close tabs via gesture, to open
links in a new window via gesture (I do it via middle mouse to open in a new
tab) and so on. I'm for adding the full Optimoz Mouse Gesture set. Since this
set is customizable (even though a graphical interface and the right preference
entries are still missing to cutomize them, currently you can only select where
mouse gestures are working and with which mouse button in the preferences), all
functionality should be there and users can then add new gestures or remove
existend ones (that is all stored in the prefs.js so it survives a browser
upgrade, currently it does not).
> The main problem is right now that Optimoz can't prevent that the context menu
> opens on Linux/UNIX

Then it's doing something wrong.  A _web_page_ can prevent the context menu
opening.  Any chrome component should be able to, trivially.

typeaheadfind is not just i-search.... it's an accessibility feature for
keyboard-only users.  Notice that the default mode searches only links... this
is not an accident.

Lastly, typeaheadfind does not affect performance in any way (when it did, at
first, it was turned off).  Last I tried optimoz, it made window opening slower
(and god knows we're slow enough at opening windows as it is).

Oh, and nothing's preventing Optimoz from storing prefs in prefs.js... if it
does not, that's again its own fault.
> Then it's doing something wrong.  A _web_page_ can prevent the context menu
> opening.  Any chrome component should be able to, trivially.

But then it will never open again anymore, what is of course not desired. The
problem is that at Windows Mozilla triggers right button-release event (pressing
right mouse button down does nothing), but on *NUX Mozilla triggers the
button-down event. See: http://mozdev.org/bugs/show_bug.cgi?id=657

>> This fix is for Windows only, exactly because of reason you state - on other
>> platforms context menu appears on mousedown. There is no way to distinguish
>> between context menu request & mouse gesture.

So either the context menu never appears anymore or it will appear, even if you
are making a gesture. Optimoz can't prevent it from opening, wait for a gesture
and if no valid gesture is detected, request from Mozilla to open it as if the
mouse button had been pressed again. This doesn't work for a XUL/JS program.
However, this could work if mouse gestures were a hardcoded XP feature that can
trigger mouse events before the trigger for the conext menu ever sees them.

> Lastly, typeaheadfind does not affect performance in any way (when it did, at
> first, it was turned off). 

According to RFD for i-search, only the prefs were removed, as they caused the
performance drop.

> Last I tried optimoz, it made window opening slower (and god knows we're slow 
> enough at opening windows as it is).

Leaving aside that I see no such slower opening of windows on my PC and never
did (and I always have mouse gestures installed), how about that: i-search is
native code, optimoz is XUL/JS and such must be compiled at each start-up of
Mozilla (or isn't that what the XUL.mfl file (aka XUL cache) is for in your
profile directory?). So of course it takes a little bit extra time during
start-up, but only the first time if it's cached and of course this were not the
case if it were native code. Another argument that speaks for making this a
native XP feature.

Also nobody forces you to insall or use it (just like type-ahead), but it's a
great enhancement, making browsing much more pleasing and making the browser
much easier to handle, that's why it is hardcoded into Opera. If it were a XP
feature, it would not cause any of the problems you described here and it would
simply be en-/disabled via a preference setting and if it's disabled, it's not
even loaded (currently you can en-/disable optimoz as well, but since it's
XUL/JS, it has to be loaded anyway, because it must check its own preference
settings to know that it shall not work).
Ah, you want to be able to drag the mouse around with the right mouse button
down... you're right, you can't do that.  Nor could you do it if you were
implemented in C++, unless it were hardwired into the event handling code (which
I would strenously recommend against).

Have the optimoz developers considered a request for a way to trigger the
context menu?  That would be the approach to take whether the code is "in the
tree" or not....

For i-search, with the pref off, the DLL is not even loaded into memory.  So
removing the pref removes the whole thing.  That would be the only benefit of
moving the optimoz stuff into a C++ component, as you note -- people who want to
disable it could do it.  Of course the current impl could use a small stub that
checks the pref and loads the rest if it's wanted (which is what the C++ impl
would have to do).

XUL.mfl is indeed the compiled version of all the XUL you used last time
(_including_ optimoz).  The hit I measured was for window open, not startup, but
the way (and I wasn't _looking_; I ran the window open perf test).

One reason that isearch _does_ have for being in native code is that the actual
searching would be painfully slow if done from JS...
> Nor could you do it if you were implemented in C++, unless it were hardwired
> into the event handling code (which I would strenously recommend against).

That's how it is done in Opera, that's why you can make gestures in Opera,
regardless on which platform you use it.

> Have the optimoz developers considered a request for a way to trigger the
> context menu?  That would be the approach to take whether the code is "in the
> tree" or not....

Even if they can prevent the context menu from opening, what if no mouse gesture
is detected and they want to open it then? Can you open the context menu without
the right mouse button being pressed? That's why triggering mouse-up would be
the best solution and this seems to not be possible at XServer ports.

> The hit I measured was for window open, not startup

And how is this aused by Optimoz? What kind of Optimoz function is called when a
new window opens and what for? Optimoz consists just out of 6 JS files, one has
nothing but the stored gestures inside (that should actually be a preference
instead) and out of 3 XUL files (one only to add a new tab in the preference
window where you can configure it). BTW, it's actually not called Optimoz, but
Mozgest, as it only consists out of the mouse gestures so far.

> One reason that isearch _does_ have for being in native code is that the actual
> searching would be painfully slow if done from JS...

I think having a mouse trigger, that always is activated when a certain button
is pressed and then gets permanently called whenever the mouse has just moved a
single pixel, so it can keep track of mouse movent and create a string
consisting out of U, D, L and R and then compare it to a list of stored strings
to find out if this is a known gesture or not is no task one should do in JS either.

ISearch still has not even a preference tab to customize it, something Mozgest
already has for long. So it looks much more like a "part" of Mozilla than
ISearch does, but ISearch is allowed to go into the tree and Mozgest not?
> > Have the optimoz developers considered a request for a way to trigger the
> > context menu?
> Can you open the context menu without the right mouse button being pressed?

Why do I get the feeling you didn't read what I said?  I repeat "if you can't
that needs to be fixed".  For what it's worth, Mozilla/Mac opens the context
menu on a click-hold with the single mouse button, so there are other ways of
triggering it.  If those ways are not scriptable, they should be.  If the
Optimoz people produced a patch to make that happen, it would most likely be
incorporated into the tree... The benefits would accrue to other mozilla-based
things that want control over the context menu, not just to optimoz.

> And how is this aused by Optimoz?

If I knew, I would have sent them a patch.  I didn't have time to dig into it in
detail.

Note that I'm not saying that isearch should have gone in here.  I'm just saying
that the arguments for optimoz being incorporated into the guts of the
(platform-specific) event code are bogus (not to mention that it would need at
least 4 version of optimoz, more likely 6-10).


Pulled latest nightly build and made a clean install on my system. Then I pulled
the window-open test, which was only opening ten windows. I altered the JS file,
so it opens 20 windows and repeated the test three times.

Without Mozgest (sorted from low to high): 292, 300, 307 -> Average: 299.6
With Mozgest installed (sorted like above): 297, 301, 304 -> Average: 300.6

1 ms is only 0.3%, that is too small, you must at least allow 1% inaccuracy in
every measurement.


Regarding native code, I say that whatever reason there was to make i-search
native, it also applies to mouse gestures. If it's speed, then it's speed. See,
Mozgest must call the following JS method for every pixel the mouse moves:

function processCoordinates(e){ // e is browser's event object
  var x_dir = parseInt((e.clientX-old_x)/grid);
  var y_dir = parseInt((e.clientY-old_y)/grid);

  //only add if movement enough to make a gesture
  if ((x_dir != 0) || (y_dir != 0))
  {
    var last_dir = gesture[gesture.length-1];
    if (x_dir > 0 && last_dir != "R"){
      gesture.push("R"); localizedGesture.push(R); }
    else if (x_dir < 0 && last_dir != "L"){
      gesture.push("L"); localizedGesture.push(L); }
    else if (y_dir > 0 && last_dir != "D"){
      gesture.push("D"); localizedGesture.push(D); }
    else if (y_dir < 0 && last_dir != "U"){
      gesture.push("U"); localizedGesture.push(U); }
    old_x = e.clientX;
    old_y = e.clientY;
    window.status = bundle.getString("g.gesture") + " " + localizedGesture;
    lastGestureTime = e.timeStamp; 
}

This is eating CPU resources like movie visitors eat popcorn; it works. If that
works, I dare to claim that isearch in JS had worked as well and not slower than
mouse gestures are working now (of course slower than in native code, but
mozgest would also work faster and need much less CPU power than it does now).
good to hear that window open perf is no longer an issue here.

The isearch could be in JS, sure.  But it has to do a hell of a lot more work
than the code you show there (combining adjacent text nodes throughout a
document many thousands of times per keystroke, eg, not to mention that it can
use some DOM-related structures which are simply unavailable from JS to speed up
some things).

Looking at the mozgest code in question, there's lots of room for perf
improvement event without going to native code.  The bundle.getString() call
(which is quite slow) is called every single time through the function instead
of caching the result in a global const and reusing it, for example...

Yes, it would likely be faster if silly things like that were fixed and likely
faster yet if it was C++.  And would be much less maintainable too, of course...

So do the mozgest people really want to take that leap?  And maintain the
various toolkit versions of mozgest?  If so, perhaps some more specifics on
exactly how they propose this would help.... it's a lot easier to get code added
to the tree if you have a patch, you know. ;)
> The bundle.getString() call(which is quite slow) is called every single time
> through the function instead of caching the result in a global const and 
> reusing it, for example...

No, it's only called if you have moved the mouse at least 50 pixels (or whatever
you wrote into the configuration tab of Mozgest; it's 50 by default) and if a
something that looks like a gesture is detected. But Mozilla's source code is
full of such stupidity. No reasonable programmer that already has to use
JavaScript (which is always slower than native) will write code like that:

this.showItem( "context-back", !( this.isTextSelected || this.onLink ||
this.onImage || this.onTextInput ) );
this.showItem( "context-forward", !( this.isTextSelected || this.onLink ||
this.onImage || this.onTextInput ) );
this.showItem( "context-reload", !( this.isTextSelected || this.onLink ||
this.onImage || this.onTextInput ) );
this.showItem( "context-stop", !( this.isTextSelected || this.onLink ||
this.onImage || this.onTextInput ) );
this.showItem( "context-sep-stop", !( this.isTextSelected || this.onLink ||
this.onImage || this.onTextInput ) );

Every reasonable programmer would do it the following way:

var showNav = !(this.isTextSelected || this.onLink || this.onImage ||
this.onTextInput);
this.showItem( "context-back", showNav );
this.showItem( "context-forward", showNav );
this.showItem( "context-reload", showNav );
this.showItem( "context-stop", showNav );
this.showItem( "context-sep-stop", showNav );

Leaving aside that showItem is a stupid helper function that performs an
unnecessary check (to add a functionality that is nowhere used and even if it
were used, one could probably work around it easily) and could as well be
inlined without that check. And tons of code like this is executed every time
the context menu opens (this is from the nsContextMenu.js file in comm.jar).

> So do the mozgest people really want to take that leap?

Do they own a patent on mouse gestures in Mozilla? This RFE is not about having
the people from Mozgest implementing Mouse Gestures permanently into Mozilla,
but about having the Mozilla developers implementing it as permanent part into
Mozilla (that's why we are discussing it here and not at the bugzilla page of
Optimoz). How they do that (if they take the work of the Optimoz people and
improve it, or write it from the scratch) is their business and such their
choice. They make the decisions.

This is the same situation like tab-browsing went into Mozilla, which first was
just an external add-on, too, but it was considered useful and it was demanded
by people, so it was added and since it was added, a lot more people have
discovered it to be highly useful (that didn't even know about tabs in browsers
before and had never discovered that feature if it were not integrated and as
fixed part of the browser).
>Every reasonable programmer would do it the following way:

very well, so file a bug for that please.
> but about having the Mozilla developers implementing it

Who are these mythical "Mozilla developers"?  They're people like me or you, who
just happen to decide to work on something....  For both of the features you
have mentioned (tabbed browsing and isearch), the development process went like
this:

1)  Some one person decides it's a cool idea they want to use
2)  This one person codes it up
3)  This person submits the patch
4)  The patch gets reviewed and checked in

So you're saying that someone should decide that mouse gestures are a really
cool idea, basically.  Controlling people's thoughts is a tall order... ;)

Basically, this will happen as soon as, and no earlier than, someone decides to
do it because it scratches their itch and codes it up.
I'm Optimoz developer working Mozgest so I'll probably have enough insight into
the problems you are discussing now. Let me comment on come points:

ad comment 31 :
While I'm aware of all your arguments Mathew, I have to disagree with you in
more points. To implement Back and Forward gestures only is waste of time. I and
a few other people using Mozgest I know, use it primarily for speeding up tabs
operation. That is the main point for me personally to have gestures. ...& I
don't want to go into heated discussion about your position on tabs.
Second thing are preferences. With the wast differenes between platform and
default mouse buttons' uses we need to expose some configuration solely because
of this. Though I'm interested how does Opera mouse gestures work on Mac. Could
you please tell me how the've solved problem with only mouse button & text
selection (which is our mayor inssue with primary mouse button config)?

ad Boris and tgos comments:
Don't spam this bug with unrelated discussion, please. Boris, get a clue about
optimoz before commenting on it and offending other developers, ok?
There is no point for mouse gestures to go to native code. JS is just fine.
There is nothing that can be speeded up by such move. tgos, in comment 40 you've
cited code that is not from mozgest.

Optimoz is not ready for the tree incorporation yet, because it is done as
overlay which is not desired. There is rewrite to JS Service in progress right
now. When mozgest 0.4 will be fully tested, that will be time when we'll attempt
to get it to the tree (possibly).
Component: XP Apps: Drag and Drop → XP Apps: Cmd-line Features
Just to comment abouse usefulness: I'm using it mainly for back/forward
operations, no matter where I am right now on a page and to minimize and close
windows without going to the title bar first.

> Don't spam this bug with unrelated discussion, please.

This bug is about adding mouse gesture support to Mozilla (please note "mouse
gesture support", not optimoz or mozgest! Mozgest may not be the only way how it
can be done and it may not be the best way how it can be done; it is just one
way how it can be done). It states RFE (Request For Enahancement) and that's
exactly what is discussed here. Saying "We don't need mouse gesture support
because there is an add-on that does this" is not valid, as this bug is about
having something in Mozilla and not about having it as add-on.

> There is no point for mouse gestures to go to native code.

Drawing a simple mouse gesture needs 50% of all my CPU resources on a 1 GHz
machine. If you compare this to i-search, which does a much more processing
intensive task, it only needs 3% to periodically search all over a medium sized
webpage.

If there were a way to have the native mouse handler just call a JS function
whenever a certain event took place (e.g. whenever the mouse moved 50 pixels
from it's original position with a button pressed or so), then it wouldn't make
much difference if the rest of the handling is native or JS, but we are speaking
here of more more than 200 JS functions calls a second (and that no matter if
this results in a gesture at all or not). There were other pieces of code in
Mozilla where certain JS functions have been called on short intervalls and most
of these have been removed, using the argumentation that they eat up plenty of
CPU time to do trivial tasks (because most time is lost by jumping in and out of
the JS fucntion, not by the JS function itself!)

> There is nothing that can be speeded up by such move.

No, but it would maybe need 5% CPU resources as native code and being
integerated  into the C code that creates mouse events (the one that creates the
events you are receiving in your JS function right now), it would probably be
trivial to prevent text marking or context menu when that's desired.

> tgos, in comment 40 you've cited code that is not from mozgest.

No, it is from nsContextMenu.js (maybe the file that will one day help you to
prevent opening context menu if right mouse button has been configured to be
gesture button) and was just included as example that most parts of Mozilla are
programmed and optimized for "beautiful and easy to understand code" and not for
raw speed and minimal memory usage.

> Optimoz is not ready for the tree incorporation yet, because it is done as
> overlay which is not desired.

Exactly because of that it should be in the tree. As long as it's an add-on, it
will have to stay an overlay, that's the way how add-ons work. How are you going
to get it working without overlay? This will only work if it is a fixed part of
Mozilla and it can only become such a fix part if it's in the tree. Sounds like
a vicious circle to me.

And to comment 42 :

> So you're saying that someone should decide that mouse gestures are a really
> cool idea, basically.

No, someone has already decided so and that's Alex, the person who started this
bug and I fully agree with him.
>> Don't spam this bug with unrelated discussion, please.
> ... bla bla bla ...
You did it again. 

I got an advice for you: stop ranting and start coding if you thing mozgest
isn't enough for you or that it couldn't be incorporated to tree.

> Drawing a simple mouse gesture needs 50% of all my CPU resources on a 1 GHz
machine. 
It is not fault of mozgest. Try selecting text with mouse and you'll get almost
the same performance hit (+-10% on 800MHz). It's the way mouse events are
handeled. Your rant is of kind: let's make wait loop faster, it's take 98% of my
CPU time!

Mozgest JS service is not done via overlays. That has nothing to do with XPIs.
Study more... I'm not going to comment more on these kind of things. Sorry for
the spam to the rest of cc'ers.
Component: XP Apps: Cmd-line Features → XP Apps: GUI Features
Summary: [RFE] Mozilla should support mouse gestures → Mozilla should support mouse gestures
Considering the new roadmap and MozillaFirebird's goals (being a light-weight
but extensible browser), I guess Mouse Gestures will stay an optional (albeit
popular) extension. We (optimoz.mozdev.org) could live with that, but the
current situation on Linux somehow prevents users from gesturing with the right
mouse button.

Although the context menu (@ mousedown) *could* be blocked, bug 195191 needs to
be fixed so that an extension can deliberately show it at mouseup (if no gesture
was done).

Adding dependency.
Depends on: 195191
Whiteboard: parity-opera
Should this bug be closed?

A new bug could be created for something specific like "add optimoz gestures to
mozilla suite", but this bug seems pretty closed to me.
Product: Core → Mozilla Application Suite
Mouse Gestures make for a good extension, but I don't believe they belong in the
default build.
Status: NEW → RESOLVED
Closed: 20 years ago
Resolution: --- → WONTFIX
Component: XP Apps: GUI Features → UI Design
I don't understand why so many essential features are marked as "Won't fix",
just because there is an extension. If Seamonkey is not more feature-rich than
Firefox (already advertised as minimalist), then what's left for Seamonkey? I'm
sure many people expect Seamonkey to be feature-rich. This is the fundamental
difference between the two application:
 - User wants a simple and extensible browser: Firefox
 - User wants a rich Internet suite with a number of features working out of
the box: Seamonkey
You need to log in before you can comment on or make changes to this bug.