Mouse Gestures in Mozilla

Jedbro writes: "I have really enjoyed the mouse gestures in Opera since its release, since then I have come across an awesome new project at Mozdev, called OptiMoz. OptiMoz (a.k.a. MozGest) is a XPI for Mozilla allowing Mouse Gestures to be available. It works great with Mozilla 0.9.4 and nightly builds. It currently has Gestures for: *New Tab Window (Moz Tabs!!) *Forward in History *Backward in History *Reload *New Document *Up a directory in the URL *View Source *View Cookies for Current Domain *View Meta Data for Domain and *Access Homepage."

Comments

Slashdot to thank

[abischof]

In a way, Slashdot is to thank for this. Back when Mozilla 0.9.2 was released, there was a +5 comment on the possibility of Opera-like gestures. That led people to read about gestures in bug 76537 and, from there, the community stepped up to the plate (specifically, Andy Edmonds). Nice.

Now, if only we could work together and get some working spellchecking for Mozilla :).

how about additional mouse buttons ?

[mbyte]

I got an M$ Intellimouse with 5 buttons + wheel
(if u count the wheel as buttonts, then it has 7)

In IE the 4th button is the Page back feature .. this is WAY more convinient than every possible guesture, just press ur thumb , and page back.

Any way to configure Mozilla to have the same behavior ? The best i found is using key for page pack, but as written below u need 2 hands for that ... Any ideas ? Do i need to fill out a mozilla bug ? :)

Re:Didn't work for me

[brunes69]

Also, from the experience I've had, the user you're running mozilla under has to be able to write to the mozilla directory to install plugins. So I su root, install the plugin, then re-start in user mode. The plugin then appears.

Re:Even better

[litheum]

you must not spend much time looking at porn..

vim mode?

[The Pim]

Use keyboard shortcuts. They're quicker.

It's not just that keyboard controls are good on general principles; it's also the ridiculous extent to which browsers neglect them. Do you realize that when the focus is in the page (> 90% of the time), almost every single keypress does absolutely nothing? What a waste!

I would give my left foot for a vim-like mode in mozilla. Flexible and powerful navigation, visual selection, one-key incremental regex searches, marks and jumps, macros. Some modifications would be necessary for a browser environment, but I think most of the endearing non-editing properties of vim could be carried over.

So, anyone want to write this?

Can Slashdot help them stop adding features?

[Tony Shepps]

I'm just about at the end of my wick over certain mozilla bugs, such as the myriad problems with cursor management in textareas. Over the last six months to a year, I swear Moz has moved backwards in getting rid of these kinds of piddling little problems - problems which, in my opinion, absolutely prevent its wider acceptance.

The usual reply is that you can't prevent people from working on what they want to work on. Well guess what, if the piddling little bugs aren't fixed, there won't BE an open source browser for you to add your favorite little quirks to.

I'm composing this in Moz and if I hit the right arrow button at the end of a line, the cursor will go to the top of the text area. If I hit the down arrow key, it will create a hidden EOL. Sometimes entire lines of text just disappear and then re-appear. Sometimes unhighlighted text remains highlighted. Once in a while it even crashes, which I like because then at least something has a chance of getting attention.

It's so bush, too, that's the problem with it. Looks like Moz can manage to claim compatibility with important WWW standards but CAN'T MANAGE STANDARD TEXT EDITING.

You can complain about me complaining, but my contribution is not coding, and all my words are out of frustration for seeing these stupid little bugs live on for month after month. To live to make it into milestone after milestone. And the worst part is, IT USED TO WORK PERFECTLY. At some point, probably last spring, text editing was BROKEN. WTF, people?

And I won't even mention how many times the window focus problems have changed but not improved in the last six months. And to think that, a year ago, I though Moz was three months away from "ready".

Re:Can Slashdot help them stop adding features?

[Eloquence]

You make valid points. I am not very familiar with the Bugzilla interface. But I tend to think that interfaces mean a lot, and with slight changes there often come great increases in productivity and changes in direction.

The problem that important bugs remain unfixed seems to stem from a lack of knowledge and motivation for developers to concentrate on the important stuff. All bugs are considered equal. So when everything is equal, it seems to be logical to do what looks "cool" to you instead of what may actually be important. On the other hand, if fixing important bugs increases your status in the Mozilla community more than adding features, the problems you describe are likely to go away soon.

I notice that Bugzilla already has a voting system. That is good. However, it seems to be mostly unused. That is bad. Why is that so? Probably because the voting interface is deeply integrated into the complex Bugzilla interface, which most end users will never access directly (let alone create an account for, which is necessary to vote) but only through the templates -- but you need the end users to vote on the most annoying bugs. How can that be changed? Perhaps all reported bugs should also be automatically submitted to a collaborative weblog like Kuro5hin. Scoop, the K5 engine, is open source. It allows users to vote on "stories" submitted, either to the front page or to a page section. In this specific application, users would have to decide which bugs and feature suggestions are very important, which ones are relatively important, and which ones are irrelevant.

This seems to be the simplest solution -- many others are possible, from improving the Bugzilla interface to integrating Bugzilla bugs into an existing weblog. You could also create a new native interface to report and rate bugs (and to rate the users who rate bugs), but that is the most time-intensive approach (if the most promising).

In general, I think that the current state of Mozilla reveals a clear weakness in the development model, one which is likely to only show up in very large projects. Improving the interface(s) to rate bugs and feature suggestions and to find the bugs that really matter should be a priority -- and the tools to do that could be useful to others, as well.