Closed GoogleCodeExporter closed 8 years ago
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
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
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
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
@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
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
@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
@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
@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
@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
@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
Damn you're fast :) I can verify that it works perfectly, thanks!
Original comment by EmilStenstrom
on 29 May 2010 at 3:21
Original comment by iainsproat
on 29 May 2010 at 3:36
Original comment by tfmorris
on 18 Sep 2012 at 2:56
Original issue reported on code.google.com by
EmilStenstrom
on 21 May 2010 at 6:23