When creating a question in Firefox, can't get past the select a recipient stage about askthem HOT 13 CLOSED

Good catch. Is this something up your alley to debug?

from askthem.

sure, @evz and will take a look

from askthem.

I think I found the offending line of coffee script.

Firebug reports that length as 0 even when there is something selected:

Webkit (in this case Safari) gets a value there:

That's about as far as I can take this tonight (brain is running out of juice).

from askthem.

So, I'm pretty sure I came up with a solution for the bad jquery selector:

$('input[name="question[person_id]"][checked="checked"]').length is 0

Subtle difference but it seems to make at least Firefox happy. However, now that I'm past that step, and I complete the process of filling out the question, I end up back at the beginning, only with the old layout:

If I go through the process again, I get all the older layouts (only the forms are already filled out with the stuff I put in earlier) and then when I hit the "Publish" button again, I end up back at the beginning again. This is only true for me in Firefox. Safari, Chrome, etc perform as expected.

Anyways, I'll probably have a bit of time in a few hours to take a deeper look here. If someone @derekeder or @walter happens to get to it before me, I won't be offended.

from askthem.

So a few things are happening here. Let's step through them.

• see #59 about the old layout popping up (and the lack of informative flash message)
• even though your solution allows Firefox to pass client side validation (recipient shouldn't be blank) it actually preventing client side validation from doing its job... we should not allow recipient to be blank!

$('input[name="question[person_id]"][checked="checked"]').length is 0

Shouldn't this be length is 1? Basically the user should not be able to proceed unless they do have a checked input.

I'm a tad confused about this actually as it looks to contradict "things are working in Safari and Chrome".

What it boils down to is that question[person_id] has to have a person's id passed to questions#create or server side validation will fail. If your solution has the side effect of unsetting a value for question[person_id], it's not complete.

We may need to backburner this. I don't want to eat too much more or your limited time on a browser compatibility issue.

from askthem.

Actually, if that line evaluates as true, the personError function is triggered and the valid flag is made false so the form won't submit (that's why it wasn't working in Firefox because that line was always evaluating as true in Firefox).

I'll back off on this stuff for now and we can focus on other stuff. I'll just go ahead and make sure I'm doing my dev work in Chrome/Safari so it actually works for me.

from askthem.

One thing we could have tried is running questions_spec with selenium under Firefox as Capybara's driver. That would, in theory, recreate the issue in probably a number of tests.

from askthem.

@evz, worth double checking this is still an issue.

from askthem.

Yup, still appears to be an issue (assuming oglocal is up to date)

from askthem.

Yep, still a bug in FF. As we know, haha.

from askthem.

23.0.1 still has issue, as does newest 25.0.1. @acacheung is this something that dockyard could help sort out?

from askthem.

@davidmooreppf

Experiencing same problem when looking up twitter account on Firefox:

from askthem.

I've already started looking into all of the issues related to recipients. I'll keep you posted.

from askthem.