Google Chrome 38 Bug with Multiple Select / Multi-select and off-page or wizard style Web UI

Hey All,

This may cover a very specific set of people and the solution is not elegant but it works.

Setup

The issue arose only in Chrome 38 (so very recently) and although it came up in my specific situation, it may apply to others as well.

The application I was dealing with had a wizard style UI that was all controlled in javascript and CSS. That is, I loaded all the wizard pages at once, and the "next page" and "previous page" functionality was just sliding the pages along - no reloads.

More specifically, it looked something like this:

<div class='wizard-pages-wrapper'>
  <div class='wizard-pages'>
    <div class='wizard-page'>...</div>
    <div class='wizard-page'>...</div>
    <div class='wizard-page'>...</div>
  </div>
</div>

The idea is that the .wizard-pages-wrapper had a overflow hidden and that the "next page" and "previous page" would slide along by just adjusting the "margin-left" of the .wizard-pages div. This isn't anything new - just google wizard style web UI and you'll understand.

Issue

So the issue was this. On page 2 of my wizard, I had a multi-select box:

<select multiple='multiple'>
  <option>...</option>
  <option>...</option>
  <option>...</option>
</select>

On page 1, I had 3 choices for the user to make. Once the user makes a selection, the first thing my javascript code does is clear the multi-select box so that the user starts with a clean form. It does this BEFORE actually sliding to the left to give the "next page" functionality.

$("select[multiple='multiple'] option:selected").each(function(){
  $(this).removeAttr("selected");
});

Now remember, at this point - the multi-select box that is being cleared is currently "off-screen" - well it's more in the overflow section of .wizard-pages-wrapper - which is hidden.

The issue is that in Chrome 38 - if you have a multi-select box that is in a overflow hidden area and you affect it's selected items - Chrome brings that multi-select box into view. When it brings it into view, it screwed up all my margins for the wizard pages - so it kind of looked like the wizard was in between switching pages.


Solution

Albeit not elegant, I did find a solution that worked. Apparently - this behaviour of affecting selected items of a multi-select box and Chrome bringing it into view if it's in a overflow hidden area doesn't happen if the multi-select box itself is not visible (display:none).

So to fix this, this is what I changed my code to (note I'm selecting the multi-select box itself now, and not the options at the top level of my foreach loop):

$("select[multiple='multiple']").each(function(){
  $(this).hide();
  $(this).find("option:selected").(.removeAttr("selected");
  $(this).show();
});

Again, not necessarily elegant, but it worked.

Hope this helps out some peeps.

How Backbone plays nicely with Rails 4 (by skipping the authenticity token and by formatting params properly)

Alright, the blog post title is a little misleading because Backbone doesn't really do either of what I mentioned. Backbone does NOT skip the authenticity token nor does it format params properly for Rails. But it's what I google'd when me and my co-worker were looking for the answers. So I titled it this way to help some peeps.

Alright, so again, credit does not go fully to me on this - my co-worker and I had to figure this out.

How does Backbone 'Skip the authenticity token'

Alright, so I was just starting to learn backbone with a very simple setup: Rails Server with a Backbone app. I was following the tutorial on backbonetutorials.com. So I got to the part where the code calls a 'save' on the model:

user.save(userDetails)

and it all worked - much to my surprise. I thought for sure there was an issue in that there's no way Backbone knew about Rails' authenticity_token. Sure enough, when I went to the Rails log, there was no authenticity token being passed in the params (as there is when you submit a rails built form). Furthermore, looking at the request in Chrome's network tab - nope, no authenticity token in the request parameters.

Yet - somehow, the request was succeeding? Did Rails somehow know this is a Backbone request and ignore the authenticity token?

Turns out - this has nothing to do with Backbone - and everything to do with jquery-rails (the version of JQuery that ships as a gem as part of Rails standard releases these days).

So upon further inspection of the request in Chrome's network tab - indeed there was no authenticity token in the request parameters - BUT there was a X-CSRF-Token in the request headers!!!

Ahhhh - so Rails must check both places (request params AND/OR request headers) for a authenticity token.

The question is - who is appending this token to the request headers?

Turns out, it's JQuery-Rails. JQuery-Rails appends this header to all AJAX requests where the CSRF meta tags are present.

https://groups.google.com/forum/#!topic/rubyonrails-core/eyTb_WZXLcs

Very cool stuff. So Backbone doesn't skip the authenticity token - it just makes an AJAX request, which JQuery-Rails is smart enough to append a authenticity token to the header of that AJAX request.

How does Backbone format its params properly

As long as I've been using Rails, I've always understood the POST CREATE request to accept its parameters in a specific way. If you had a user that had a name and age, you would need to pass the parameters like this:

{ user : {name : "Casey", age : 31 } }

In other words, you would need to nest the values within a object that's named after the resource. However, looking at Backbone, backbone has its parameters like this:

{ name : "Casey", age : 31 }

Notice that it's not nested inside "user". What's really weird, is if I look at the Rails log for the request of a Backbone.model.save, here's what comes in as the parameters:

{ name : "Casey", age : 31, user : { name : "Casey", age : 31 } }

It turns out that Rails (in its infinite magic) uses a module called ParamsWrapper that I can only theorize analyzes what comes in, and if it's only one-level deep, massages the params so that there is an extra param that's formatted properly for Rails (two-levels deep). This way, you have access to the params the way you passed them in:

params[:name]
params[:age]

and you have access to them the way Rails needs it:

params[:user][:name]
params[:user][:age]

Pretty crazy stuff.

Hope this helps some peeps.

Ruby on Rails, Rest in Place with Authorization taken into Account

Hey all,

Just a quick one. Just started using Rest in Place in my Rails applications. If you don't know what it is - it seems to be the most popular In-place editing gem (according to Ruby Toolbox).

Anyway, the one thing that kind of got annoying, is that my view templates were getting pretty ugly with a lot of IF statements because I didn't want in-place editing to be active for people who weren't allowed to edit. I realize that Rest in Place still goes through the controller, so any authorization code you have on the controller side prevents true editing - but still, I wanted to prevent the UI in-place editing for people who weren't authorized to do so either.

So I created a simple helper to remedy this.

You can check out the Gist here.

After Effects Editing Mask Path (moving individual points)

Alright, this was frustrating the hell out of me - especially considering most posts and forum responses had the right idea but were missing one key element.

The issue is in Adobe After Effects and Masks.

Here's the setup

• You have some layer (shape, picture, footage, whatever)
• You add a layer Mask
• You edit the Mask over time by setting keyframes on the Mask Path property

The issue

• Anytime you try to move a single point on the Mask Path - the entire mask path moves - regardless of if you have the Pen Tool or Selection Tool selected

So yes - most posts ands forum responses I've seen talk about - "Make sure you have the Pen Tool" selected - so that way you're in path editing mode and then you should be able to move the individual points. I tried ad nausea and I couldn't get this to work.

Solution

• It all had to do with what was selected in the timeline. I had the Mask selected (that is, the Mask property that shows up when you twirl down the layer itself) - which is wrong. This was the issue.
• Once I selected the layer itself and NOT the mask, I could then select the Pen Tool and edit the points individually.

Kind of strange - but yeah - select the Layer and not its mask if you want to edit the Mask points individually. And yes - use the Pen Tool.

(note this is in Adobe After Effects CS6 - not sure about other versions).

Hope this helps out some peeps.

Ruby on Rails, Stripe Checkout Payments, and Internet Explorer 9, IE 9 Not Working

Alright, this was a long battle, but I finally figured out what was happening. I'm not sure why this fails, but at least I know what's causing the error and how to fix it.

Problem

So the setup is the following:

• Ruby on Rails Application
• Using Stripe Checkout (JS) for Payments (version 3 I believe)
• Payments working in almost every browser except for Internet Explorer 9

The way the error manifested itself is that a IE 9 user would try to make a payment - the Stripe form would pop up properly, the user is able to enter their information, and the Green Check even happens and the Stripe form disappears but

• The following post action of the form doesn't happen
• And when I checked the Stripe dashboard - it looks like the payment didn't actually go through

So what's the culprit? It has to do with the form_tag and what it interjects into the form. I basically had the following code:

<%= form_tag "/some_action", class: "stripe-form" do %>
  <script
    src="https://checkout.stripe.com/checkout.js" class="stripe-button"
    data-key="<%= Rails.configuration.stripe[:publishable_key] %>"
    data-amount="<%= amount %>"
    data-name="app"
    data-description="<%= description %>"
    data-email="<%= current_user.email %>">
  </script>
<% end %>

So you know how the form_tag helper throws in the authenticity_token for security (if you don't, visit your webpage and look at the HTML source and you'll see that rails injects 2 hidden input fields for security checks). Now what's the issue? IE 9 does not like the DIV tags that surround the authenticity_token inputs fields. That's what causes the issue.

Solution

So how to solve this? Well, I couldn't find an easy way to get rails to do this itself through the form_tag (and I would welcome if anybody knows how to do this using the form_tag), but basically you have to manually reconstruct the HTML that form_tag produces, and just don't include the DIV tags that surround the authenticity_token inputs. I also added some "display:none" styles to make sure formatting look good. So the code looks like this (the important thing is to remember to still include the authenticity_token inputs, just NOT inside DIV tags):

<form accept-charset="UTF-8" action="<%= "/some_action" %>" method="POST" class="stripe-form">
  <input name="utf8" type="hidden" value="✓" style="display:none">
  <input name="authenticity_token" type="hidden" value="<%= form_authenticity_token %>" style="display:none">

  <script>
    src="https://checkout.stripe.com/checkout.js" class="stripe-button"
    data-key="<%= Rails.configuration.stripe[:publishable_key] %>"
    data-amount="<%= amount %>"
    data-name="app"
    data-description="<%= description %>"
    data-email="<%= current_user.email %>">
  </script>
</form>

Hope this helps out some peeps.