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.

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.

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.

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.

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.

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

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.

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

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).

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.

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.

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.

Mouse Gestures make for a good extension, but I don't believe they belong in the default build.

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