Moving the cursor inside the Text Filter box by clicking

[GoogleCodeExporter]

What steps will reproduce the problem?
1. On any column, click "Text Filter"
2. Type in any word to filter on, and press enter
3. Now go back, and click in the middle of the word you just typed

What is the expected output? What do you see instead?
I expect the cursor to move to the position I clicked, and me being able to
continue editing the text from there. Instead, the cursor stays at the end
of the line.

Original issue reported on code.google.com by EmilStenstrom on 21 May 2010 at 6:23

[GoogleCodeExporter]

This is not a problem in Chrome or Safari. It's only in Firefox. I'd strongly 
recommend using Chrome, which is 
way faster than Firefox.

Original comment by dfhu...@gmail.com on 22 May 2010 at 2:34

• Changed state: WontFix

[GoogleCodeExporter]

So Gridworks only works in WebKit based browsers? Since you already don't 
support
Internet Explorer, you're down to ~50% of the browser market. When removing 
Firefox
from the supported list you're down to ~20%. 

1) Since Gridworks opens in the default browser people uses, there's gonna be a 
lot
of confused people out there, that don't know why their favourite feature is 
broken.
They would have to start gridworks, copy the url from <favourite browser> to 
another
browser, each time they start it up.

2) Another reason to support Firefox is that lots of web developers use 
Firefox. Web
development tools are still better in Fx than most other browsers.

I strongly recommend supporting Firefox fully.

Original comment by EmilStenstrom on 22 May 2010 at 8:40

[GoogleCodeExporter]

It's also at odds with the Freebase.com folks who support Firefox, but not 
Chrome.

Original comment by tfmorris on 22 May 2010 at 4:12

[GoogleCodeExporter]

Yeah, I don't think it's reasonable to ignore a problem that is only on 
Firefox. Now, the question is: is it 
because the browser is too slow to react? or because there is some 
inconsistency in behavior?

If the browser is too slow, there is not much we can do but wait for Firefox to 
get better (gw is pushing the 
limits on the browser, substantially) so a WontFix is understandable.

But if the problem is just behavioral, I agree we should fix it.

Do we know which one it is?

Original comment by stefano.mazzocchi@gmail.com on 22 May 2010 at 5:51

[GoogleCodeExporter]

@tmorris, FYI most developers on freebase.com use Chrome, not sure where you 
got the idea that its not 
supported but I can guarantee you that it is: Chrome is pretty much becoming 
the browser of choice for 
development at Metaweb, especially the dev branch, given its speed and its 
improved developer tools.

But that doesn't mean that firefox should not remain at the center of our 
radar: it is and it remains so no matter 
what we use to develop and test day by day.

Original comment by stefano.mazzocchi@gmail.com on 22 May 2010 at 5:56

[GoogleCodeExporter]

I've been told Chrome is unsupported in multiple contexts including bug report 
responses and email conversations.  The following might also lead one to 
believe that 
to be the case.

http://wiki.freebase.com/wiki/Browser_support

"Browser support
Supported Web Browsers:
The freebase.com web site supports the following web browsers:
Microsoft Internet Explorer Version 7 or greater (PC)
Mozilla Firefox Version 2.0 or greater (Mac or PC)
Apple Safari Version 3.0 or greater (Mac or PC)
These browsers are tested whenever new software is released at freebase.com.
Firefox Variants (e.g. Camino, Flock):
Though we don't officially test and support web browsers that are based on the 
"Gecko" layout engine ( other than Firefox), these browsers should work fine 
with 
freebase.com."

Original comment by tfmorris on 22 May 2010 at 6:15

[GoogleCodeExporter]

@EmilStenstrom: This bug does not occur in IE8 and Opera 10.53, either. And our 
client-side testing framework 
uses Firefox as the test browser. So, we are supporting Firefox, but we're not 
supporting Firefox's quirks.

I'm against special-casing for browsers' quirks lest they won't fix their 
quirks, unless the quirk really breaks a 
major functionality. And this bug doesn't break a major functionality. In the 
text search facet, I don't think it's 
often that we find ourselves using the mouse to position the text cursor. As 
far as I know, for text search fields 
in general (not just in Gridworks), the common operation is to backspace and 
type, or to use the keyboard arrow 
keys to get the cursor to the right place.

I'll keep this bug open in case anyone else wants to take a stab at it. The 
solution should not have an "if it's 
Firefox" test but should be generic code that works on all standard-compliant 
browsers.

Original comment by dfhu...@gmail.com on 22 May 2010 at 9:03

• Changed state: Accepted
• Added labels: Priority-Low
• Removed labels: Priority-Medium

[GoogleCodeExporter]

@dfhuynh: I understand your stance here. You should not have to deal with 10
different browser quirks, and instead work with code that works cross browser. 
If
some browser is bad enough not to be used with Gridworks, you should put up a 
big
sign saying "Sorry, your browser lacks vital features needed for Gridworks to 
work".

Anyways. This is not one of these issues. I'm an interface developer myself, so 
I
dived into the frontend code so see why Firefox behaved the way it does. This 
is why:

<ul class="facets-container ui-sortable" unselectable="on" 
style="-moz-user-select:
none; height: 245px;">... The input element is inside this ...</ul>

-moz-user-select is a mozilla specific css property, that will make that 
element, and
all subelements, unselctable. More info here:
https://developer.mozilla.org/en/CSS/-moz-user-select

I don't know what UI-framework you use, but probably you've set 
unselectable=true on
some parent element, not expecting it to inherit. If that guess is correct, 
resetting
the selectable status on the text box should do the trick.

The reason I filed a bug for this is because it annoyed me a lot, since I 
encountered
it quite a lot. When using regexps to filter records I frequently go back an 
forth
between the facet and filter boxes, and using the mouse for that is much easer 
than
tabbing. So this is not a "I think things should work differently"-bug, it's a 
"I'm
frequently experiencing this behaviour, and think others are too"-bug.

That said, the fix should be simple. Thanks for your patience.

Original comment by EmilStenstrom on 23 May 2010 at 2:14

[GoogleCodeExporter]

@EmilStenstrom: Thanks for tracking the problem down to -moz-user-select. This 
CSS attribute was set by a 
jQuery call that I copied and pasted from a jQuery UI sortable example. 
Removing that call fixes the bug and 
doesn't seem to introduce any problem.

And you are right: I can see that in regex mode people would want to position 
the text cursor using the mouse.

Fixed by r843. Please verify.

Original comment by dfhu...@gmail.com on 23 May 2010 at 5:36

• Changed state: Fixed

[GoogleCodeExporter]

@dfhuynh: Sorry, I don't have the required build tools needed to run the svn 
version
(ant), and don't quite have the time to go through and install them. So I'm 
eagerly
await the next stable release!

Original comment by EmilStenstrom on 29 May 2010 at 2:14

[GoogleCodeExporter]

@EmilStenstrom - version 1.1 is already available, please download from 
http://code.google.com/p/freebase-gridworks/wiki/Downloads

Could you verify that this issue is fixed in version 1.1?  Thanks

Original comment by iainsproat on 29 May 2010 at 2:52

[GoogleCodeExporter]

Damn you're fast :) I can verify that it works perfectly, thanks!

Original comment by EmilStenstrom on 29 May 2010 at 3:21

[GoogleCodeExporter]

Original comment by iainsproat on 29 May 2010 at 3:36

• Changed state: Verified

[GoogleCodeExporter]

Original comment by tfmorris on 18 Sep 2012 at 2:56

• Added labels: Milestone-1.1