On 06/02/2011 03:33 PM, Tomas Sedovic wrote:
On 06/01/2011 08:02 PM, Matt Wagner wrote:
> On Wed, Jun 01, 2011 at 06:12:44PM +0200, Tomas Sedovic wrote:
>> Another couple of bugs unearthed by Matt.
>>
>> Thomas
>
> Ugh, sorry, but I'm apparently really good at finding bugs.
>
> The login page stops working with this patch applied. I added "dataType:
> 'script'" to user_sessions/new.haml and that worked, but then selecting
> filter view on pools loaded an entire page with full layout inside a
> partial.
>
> I need to spin off and work on something else now, otherwise I'd try to
> fix this and submit a patch.
>
> -- Matt
> _______________________________________________
> aeolus-devel mailing list
> aeolus-devel(a)lists.fedorahosted.org
>
https://fedorahosted.org/mailman/listinfo/aeolus-devel
Congratulations, you're now officially my nemesis :-)
I didn't see the filter view problem in Chrome and I didn't check it
with Firefox, where I am able to reproduce it now.
It looks like a deeper issue with how Firefox handles HTTP redirects
with ajax versus how Chrome does it. Looking into it now.
The login issue as you noticed has a trivial fix (adding the 'script'
dataType).
Once I fix the filter view, I'll send another version.
Thomas
Okay. Fixed.
On the Pools#index page we have a Viewstate defined. When the view
changed to 'filter', the Viewstate handler caused an HTTP redirect.
And it so happens that Firefox (along with at least some Opera and IE
versions) resets any HTTP headers that one might have set on the XHR
request when it encounters a redirect.
So the situation was as follows:
1) Conductor's JS sends an ajax request with the ACCEPT header set to
receive application/javascript (and variants thereof)
2) Rails sends 302 redirect
3) Firefox sends another request to the new location, resetting the
ACCEPT headers to Firefox' defaults (text/html)
4) Rails' content_for function interprets this as format.html, not format.js
5) Conductor's JavaScript code that originated the request gets wrong
content
The fun thing is, that the redirect and the header reset is completely
transparent to the JavaScript code that started the whole thing. You
can't hook to a beforeSend handler or anything else.
There are bugs filed in the Mozilla bug tracker[1][2], and it seems that
there is work happening on them. Unfortunately, that doesn't help us now
because it's not just Firefox and we need to support the older
(currently existing) versions as well.
The solution:
* I turned off the redirect in viewstate for ajax requests -- it doesn't
make sense for ajax calls in that case anyway.
* In the short to mid-term period we must make sure that no ajax request
get HTTP redirect response from conductor. In this case, long-term
situation is when all the browsers that we support have this bug fixed.
I think we can live with that -- we control the routes that the ajax
calls so we can take care of this. This seems to be more of a
philosophical issue rather than a practical one (at least in our case).
If this is not acceptable, we'd have to revisit the way we serve content
from Rails.
Currently, we distinguish between full page / partial page / json data
response using the HTTP ACCEPT header that the request specifies (the
rails way). If this is not enough, we could use extensions, URL params
or something else.
[1]:
https://bugzilla.mozilla.org/show_bug.cgi?id=401564
[2]:
https://bugzilla.mozilla.org/show_bug.cgi?id=553888
Thomas
--
No trees were killed to send this message, but a large number of
electrons were terribly inconvenienced.