New Feature: site-specific exclusions

[IMeanReallyNow]

Hi. Just started using FindBar-Tweak after FindAll became incompatible with FF 25. I'm liking it a lot. Just signed up here to make this request.

Would it be possible to create a list of sites on which FBT will not start searching automatically when you start typing?

I am finding that when I try to use site-specific shortcut keys that do not require Ctrl/Shift/Alt (eg, when working on a Google Sites site), FBT starts searching right away, which in this case is really inconvenient. The keys are still passed to the browser as shortcuts, but the letters that I typed get highlighted on the page.

I don't want to turn that option off, because I use it all the time, including in other tabs while I am also working at the site I want to exclude.

I'd still want to be able to bring up FBT with Ctrl F and have it get focus, so I don't want to disable it.

What would be really great is if there could be an option on the find bar that would let you toggle instant search on and off.

Thanks for reading. And thanks for this great extension!

[Quicksaver]

A site specific exclusion for the quick find bar is, technically, possible. Although, it could be troublesome, and could perhaps decrease performance in all pages. But I do understand how troublesome this can be in pages with it's own shortcuts.

Before we go any further, tell me something. If you disable FBT, then try to use the quick find bar, by typing in those pages, does it still work? (You need to make sure it's activated of course; the default option, without FBT enabled, is at Tools menu - Options - Advanced tab - Search for text when I start typing.)

[IMeanReallyNow]

WOW! Thanks for that FFFFFAST reply, :-D

What seems to be happening when I disable FBT is (testing at Google Sites where I am the owner):

If FBT is disabled and FF's native typeaheadfind is ON, then when I start to type, the keys are passed to google sites AND ALSO get highlighted if they appear on the page (this is what we're trying to avoid)

If FBT is disabled and FF's native typeaheadfind is OFF, then when I type they get passed to GS as expected, without any highlighting on the page .

IF FBT is ENabled and FF's native typeaheadfind is OFF, then when I type, FBT proceeds to find matches.

That last one kind of surprised me, but then I found that FBT is directly changing that setting.

Does this tell you what you need to know?

Thanks!

[Quicksaver]

I had never tried this specific scenario, so I didn't know if firefox's handler also catches those keypresses (FBT uses Firefox's handler, it doesn't actually have its own).

Can you tell me another thing? (I have never used google sites) Are those shortcuts global to some kind of google sites mechanism or are they specific to your pages? Because if they're specific to your pages, you can just preventDefault() and stopPropagation() the key events in your own scripts when your sites handle them, so they won't (or shouldn't) go through to firefox. This is what most sites with shortcuts typically do at least, as far as I know.

[IMeanReallyNow]

The shortcuts are global within GS.

They take the form of: g then p g then m g then r

And also Shift + letters.

They've made the g key into a kind of control key.

The behavior is a bit inconsitent. The m key is supposed to open the main menu where these other options and shortcuts are found, but it doesn't do it consistently.

Google has little incentive to make their services play nice in FF or IE, etc. They seem to be living up to my low expectations.

[Quicksaver]

Well, it's true that things can be a bother as they are now. I'll see if I can somehow automate this process, or if I can't, I'll try to work in an exclusion list.

[IMeanReallyNow]

I will be very happy to test anything you come up with. Just let me know. (Do you have access to my address?)

[Quicksaver]

I'll post here when I have something and you should receive an automatic e-mail notification about it (as long as you provided a valid address when you registered).

[Quicksaver]

Just like you should be receiving now. :)

[IMeanReallyNow]

great! thanks!

[UMLAUTaxl]

Also on GitHub: :smile: http://tosbourn.com/2013/06/development/some-useful-github-shortcuts/

[Quicksaver]

Actually, on github it's working well for me, it's not opening the quick find bar when I hit 'c' in the issues page to create a new issue, or when I hit 'g c' to open the code page. Is this not happening for you? (Thanks for that btw, I didn't know about those shortcuts :) )

[UMLAUTaxl]

Ah, it's the other way around. I thought this was about not wanting to use the shortcuts. But I'm glad I could show you something new. :smile: Kind of weird that they are not well documented here. (Just like GitHub's Markdown. But I guess [b]bold[/b] is [b].) edit: ... not.

[Quicksaver]

I wouldn't want to disable the site's shortcuts from within the add-on, even if that was made as an option. That would be very hard to keep consistent, and the list wouldn't really be user-made as every site is different, so the add-on would have to behave differently for each site (a specific code for a specific site).

But I didn't understand now. This is what's expected: in https://github.com/Quicksaver/FindBar-Tweak/issues, if you hit 'c', it should load the "Create new issue" page and not open the quick find bar; if instead you hit 'a', it should trigger the quick find bar (as 'a' isn't a shortcut). Is this not happening for you?

[IMeanReallyNow]

Hmmm. I'mj finding something strange. Here's what just happened (or appeared to happen.)

I had FBT's typeahead turned off because I was working in Google Sites. (FBT itself was still enabled.)

• When I read this message above, I turned FBT's typeahead back on by right clicking the find bar and setting it in Options.
• When I typed the letter c from the github issues page, it was passed through to the page (in Firefox), BUT it also triggered the search bar.
• Then I tried g then c (another github shortcut) and it did the same thing.
• Then after going back to the issues page, I tried both of those shortcuts again, and they worked as expected BUT did NOT open the find bar.
• I then typed other non-shortcut keys, and FBT worked as expected.
• When I next tried shortcut keys, they also worked as expected AND the findbar didn't 't respond.
• I was unable to get the findbar to "misbehave" again. It refused to open when I typed github shortcut keys but would instantly respond to other keys

Weird. Then I went to Google Sites and tried some shortcuts.

The commands were passed to the page as expected, but the findbar also popped up. I was unable to somehow get it to respond the same as at github. Even after turning FBT's typehead off and back on (thinking that might have had something to do with it.)

Strangely, at GS, typing the letter m is supposed to open the More menu, and I believe I have seen that work. But now, with one exception, it doesn't do that even when FBT is disabled. The exception: immediately after a GS page is loaded (or reloaded with F5), pressing m opens the More menu. After closing the menu with ESC, the m key refuses to work again, even though other GS shortcuts do.

Maybe there's a clue in there somewhere?

FWIW, I'm also seeing strange page jumps when I type, even as I type these words. The words appear as usual, but with certain keys (or maybe it's just every so often no matter what keys, it's hard to tell), the entire the page does a very fast scroll up, maybe 3 or 4 lines worth, then returns to where it was...most of the time. A moment ago, it was ending up in a position where it was hiding the bottom of this post form, and I couldn't see the area where I was typing this very paragraph. I'd manually scroll so I could see it, but then the jumping took over again. I selected and copied all the text, went back to the issues list, reopened this issue, pasted this in, and typed the 2nd half of this post. With things working as expected.

I swear, officer, I haven't had a thing to drink all morning! :-)

[Quicksaver]

I'm afraid I still have to write you a ticket! :)

Here's what I think is happening. Sometimes, when just turning on quick find, it might not apply the handlers properly on the currently opened pages. A page reload would in theory fix this, which is why after navigating to another github page everything started working as expected. Or maybe this is not it at all... Honestly, I can't get it to show both the find bar and trigger a shortcut handler in github at the same time, no matter how I enable or disable the feature or the add-on. Perhaps you get bad page loads more often than you should, which makes it so the github shortcut handlers don't run properly? (Just speculation here.)

The fact it always misbehaves in google sites might be because GS handles the shortcut key, but still sends the key event to firefox (and thus the quick find bar), while github probably stops that event after it handled it (which is the correct way to do it).

Is there some way you could reach GS support and ask about they handle the shortcuts, and if this is something they could fix on their own code? You're probably not the only one suffering from this issue. I tried taking a look to the GS source code, but as everything google, it's just hectic to read (they cut back on everything they can to save memory and compiling time, which is a good thing performance wise, but horrible for anyone trying to read it).

If you don't, or for some reason can't, I can try to do it myself, but I'm not familiar with how GS works, so I thought I would ask you first.

Also, I've had those page jumps also happen to me once, I think. Probably a bad github page load, that led to some come misbehaving (perhaps).

[UMLAUTaxl]

Quicksaver, yes the site shortcuts work. I was just irritated since I don't want to use these. Guess I just have to keep disabling JavaScript altogether. :smile:

[Quicksaver]

Sometimes the fact that they work doesn't mean they're being handled correctly. As in: 1) Hit 'c' 2) Github: user hit 'c'? a) No: continue, send to the browser. b) Yes. b1) Load "Create new issue" page b2) Stop key event from going to the browser (which I'm guessing doesn't exist in GS shortcuts)

If a github page doesn't load some part correctly for some reason, it could fail at any point in there. If it fails before or during b1 then the failure is obvious (and you might get those jumps you mentioned for example). If it fails between b1 and b2 then the shortcut will still work, but it will trigger the quick find bar as well, because the event followed through.

But of course, this should always work, all the time, in theory. Plus, this is pure speculation on my part, as I'm not familiar with the code in either github pages or GS pages. So it could still be a problem with FBT or firefox's handler. I'll continue to investigate this, maybe I can fix it easily somehow. But don't hold your breadth for this for any time soon.

And none of this invalidates the possibility of an exclusion list either. That can still happen.

[UMLAUTaxl]

:+1:

[IMeanReallyNow]

"So it could still be a problem with FBT or firefox's handler."

Would I sound paranoid if I wonder if the problem isn't firefox's handler as such, but that google only tests, checks, uses, and cares about how things work in Chrome? The more subtly incompatible non-Chrome browsers are with Google's web properties -- which are a significant and growing part of routine web activity -- the more incentive users have to use Chrome. And it's not as though Google has any obligation to (as it would describe it) limit the functionality of its properties just so they can work correctly in Firefox and IE and all the other riff-raff browsers out there. The objective is to break things (cool advanced features like shortcut keys), but not so much that core functions fail to work -- which is exactly what I'm experiencing on GS. .

OK rant over.

I appreciate your looking into this. :)

[Quicksaver]

That could be true, although I'm not educated enough on the subject to agree or disagree. That could definitely be true yeah, but they also know that chrome isn't the only major browser. So a service as widely used as GS aims to be should still work in all (recent) major browsers anyway, to reach as many users as possible. So... no idea. :)