[Vimperator] A bunch of problems, should I post to the bug tracker?

[Martin Stubenschrott]

Hi Pierre,

On Thu, May 31, 2007 at 03:23:53PM +0100, Pierre Andrews wrote:
> 1- Exception on tab completion. (there is already a bug like that, but
> it's not the same I am reporting). This only happens on Firefox under
> OSX (FF 2.0.0.2), I tested with Firefox on a linux box and don't see
> that problem.
> If I try to tab complete the command:
> :open /ig<tab>
> I get the exception: "component returned failure...
> (NS_ERROR_FILE_NOT_FOUND) [nslFile.isDirectory] ...
> in completion.js line 523

Hmm, interesting, I thought that Mac had a similar directory structure,
please file a bug report, but I can't reproduce as I don't own a Mac.

I think this might be fixed in CVS though, so maybe someone with a Mac
should test it with a CVS build first?

> 2- If I add a new search engine to firefox, it becomes the default one
> in the search box of the toolbar. Now, if I use the command:
> :open some keywords
> Instead of opening a search on google, it opens the search on the new
> search engine I defined.
> I am not sure this is a bug, but to change the search engine used
> then, I have to show the menu bar/toolbar (:set guioptions=m), then
> change the select search engine there and finally hide the
> menubar/toolbar.

Hmm, you are using 0.4.1, right? In 0.5 CVS, the default search engine
can/must be defined with the 'defsearch' setting. The mapping of search
enginge names like "Wikipedia (fr)" to aliases "wikipedia" is not yet
reliable though.

> 3- Vimperator has problem with websites that replace their textareas
> by "WYSIWYG" editor, which are in fact iFrames with designMode set to
> 'on'. Vimperator doesn't get that I am typing in this iFrame and
> interpret the keystrokes. I have to bypass with shift+I

That's the plan, why we introduced 'I' - there just is no possible way
around this problem - the bigger problem are sites like www.msn.com
which hijack vimperator keys :(

> 4- Vimperator intercept the keystrokes on a <select> form element. So
> if I have a long <select> element and want to search in it by typing
> the first letters of the <option> in the drop down, Vimperator get
> that as commands and not as form inputs. here again, shift+I is the
> sole solution. But Vimperator might be able to detect (as it does with
> textareas) that I am in a form field.

That should change, no need to file a bug report, as the bindings for
form fields are not yet fine tuned.

> 5- I know this has already been discussed, but for some sites where
> there are javascript elements providing their own shortcuts, you have
> to use shift+I to bypass vimperator. The problem is that esc will get
> you out of this bypass, as often esc is the default key to dismiss
> modal dialogues, cancel actions, etc... so in that case, when you
> press esc, instead of the default action, you get out of the
> vimperator bypass... not sure what the solution would be there.

The solution is to use Esc to stop 'I' mode, then press Ctrl-v,Esc to
pass one key (esc) to the page, then press 'I' again. I know, it's not
the best solution, any other ideas? Maybe we could make ctrl-v,esc a
special case that the user doesn't have to escape I mode, but just
presses ctrl-v,esc to pass esc to the web page.

> I'll set up demos webpages for 4 and 5 tonight so  you can have a test
> pages to work on if you want.

no need for - i know of these problems, but thanks.

> Sorry for this long email with plenty of different topics in it, but
> it seemed better than sending 5 different emails ;)

Yup, and thanks for the reports.