Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Google search modification in IGNORE mode stopped working #462

Closed
Mehradzie opened this issue Mar 17, 2016 · 7 comments
Closed

Google search modification in IGNORE mode stopped working #462

Mehradzie opened this issue Mar 17, 2016 · 7 comments

Comments

@Mehradzie
Copy link

@Mehradzie Mehradzie commented Mar 17, 2016

Issue type:
  • Version compatibility
Version:

Vimperator: 3.12.0
Firefox: Mozilla/5.0 (Windows NT 6.1: WOW64, rv:44.0) Gecko/20100101 Firefox/44.0

Description:

In the older versions, when I was on the result page of Google search, if I wanted to add/delete something to/from my search phrase, I pressed i to get into IGNORE mode and then started typing the changes as if you would, if you weren't using Vimperator. (Meaning Ignore mode is doing it's job right)

However, recently, the IGNORE mode somehow doesn't put me where it used to and the first character of what I have typed sets IGNORE to OFF and other characters followed, count as Vimperator commands since I am out.

Expected behavior:
  1. In the following Google search page which is searching for the phrase "Vimperator":
    https://www.google.com.au/search?q=vimperator&ie=utf-8&oe=utf-8&gws_rd=cr&ei=pTnrVuWmAqOOmwXpkImQDg

  2. I want to press i and get into IGNORE mode (so far so good), and then start typing "Labs" to add this word to my search phrase and make it "Vimperator Labs". (Which doesn't work any more as it used to)

    Note: I can do what I exactly used to do in the current version by a bit of brute force method and pressing Shift+Esc rather than i to disable the Vimperator and set IGNORE ALL KEYS mode. which means I have to do the same to pull it out after I am done.

Steps to reproduce:
  1. Go to this search page
    https://www.google.com.au/search?q=vimperator&ie=utf-8&oe=utf-8&gws_rd=cr&ei=pTnrVuWmAqOOmwXpkImQDg
  2. Press i to get into IGNORE mode and type "Labs"
    • "L" pulls you out of IGNORE mode
    • "a" brings up Completion option
    • "b" & "s" gets added to the end of completion parameter.
@Mehradzie Mehradzie changed the title Google search when IGNORE mode is Active Google search modification in IGNORE mode stopped working Mar 17, 2016
@timss
Copy link
Member

@timss timss commented Mar 19, 2016

Thank you for a very complete bug report! 👍 I only edited your hyperlink markup a bit.

Insert behavior on javascript heavy websites like Google Search can be challenging to understand, and I'm not sure if i should get you insert mode at all. In fact, i should only ignore one key, as described in the documentation (:h i):

If you only need to pass a single key to a JavaScript form field or another extension prefix the key with i. Also works to unshadow Iceweasel shortcuts like which are otherwise hidden in Vimperator.

Without being able to reproduce the old behavior myself, my guess would be that previously Google Search would eat any keys pressed after your first key ignore using i. This is no longer the case (and not necessarily a bad thing).

If all you want to do is to append to your search string, gi is the keystroke you want to use (:h gi):

Focus last used input field. If there is no last input field, it focuses the first input field. When used with [count] it directly jumps to the [count]th input field.

Does that solve your problem?

@timss
Copy link
Member

@timss timss commented Mar 19, 2016

Also, there's #384

@Mehradzie
Copy link
Author

@Mehradzie Mehradzie commented Mar 21, 2016

@timss , Thanks for the reply and the great suggestion.

nsert behavior on javascript heavy websites like Google Search can be challenging to understand, and I'm not sure if i should get you insert mode at all. In fact, i should only ignore one key, as described in the documentation (:h i):

I should say, I don't agree with that completely and more so, depends on the situation. While in the INSERT mode, Vimperator ignores all the commands and lets you type, and I believe this is why I used to get that behavior.
Previously, i was putting me in the IGNORE mode, and since typing anything in Google search page gets the focus of search-textbox instantly, Vimperator would switch to INSERT mode and off you go.

So something must have changed, either Firefox (like the bug you forwarded me in issue #384), Google's scripts or Vimperator. And no problem at all. I like your work around however there is little funny thing happening with it. g+i puts the cursor to the left far side of the text inside the search textbox which in my case isn't what I always want :) but for sure does the trick.

Thanks again for the solution recommended and keep to hear more about this 👍

@timss
Copy link
Member

@timss timss commented Mar 22, 2016

I get what you're saying about ignore vs ignore all keys behaving differently. For now let's assume #384 is the root cause, and see where it gets us :-) This issue could possibly be closed as a duplicate in that case, if you're fine with that.

I like your work around however there is little funny thing happening with it. g+i puts the cursor to the left far side of the text inside the search textbox which in my case isn't what I always want :) but for sure does the trick.

As suggested in #192, you can add a mapping which puts you in the end of the input element regardless of your previous position:

noremap gi gi<End>
@Mehradzie
Copy link
Author

@Mehradzie Mehradzie commented Mar 23, 2016

Thanks @timss. Will do.

@timss
Copy link
Member

@timss timss commented Mar 23, 2016

Great. Thanks again for your reporting.

@timss timss closed this Mar 23, 2016
@timss
Copy link
Member

@timss timss commented Mar 23, 2016

Closed as duplicate of #384

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Linked pull requests

Successfully merging a pull request may close this issue.

None yet
2 participants