Removed the single space character for Safari

[chancancode]

I'm still cleaning up the tests, but I want to get this out so people can help me test it

Once upon a time, a single space character was added to render nothing: true (cb0f8fd, 807df4f) to fix a bug in Safari. (Thank you @matthewd for hunting this down.)

Since this bug has been fixed in Safari itself a long time ago (based on the timestamps it should be fixed in Safari 2.x or perhaps 1.x in ~2005), it's probably a good time to remove this.

I wrote a simplified version of the webkit test case which you can access here:

• xhr async version: http://lit-anchorage-8910.herokuapp.com/async (source)
• xhr sync version: http://lit-anchorage-8910.herokuapp.com/sync (source)

(The controller doesn't actually use render nothing, but it should have the same effect)

I tested this on a variety of browsers on [browser stack(http://www.browserstack.com/)], including Safari 4.0 and Firefox 3.0 and it seems to work fine.

Ideally, I'd like to see this test case fail on an older version of safari (you might need safari 2.0 or even 1.0). If you have access to one of those super old browser, please help run the test case and let me know what happens 😄

Otherwise, I am fairly confident that this should be okay.

cc @dhh @jeremy @sikachu @matthewd

Fixes #14336

[dhh]

Thanks for tackling this. Great to rid ourselves of cruft no longer needed.

On Apr 27, 2014, at 8:43 PM, Godfrey Chan notifications@github.com wrote:

I'm still cleaning up the tests, but I want to get this out so people can help me test it

Once upon a time, a single space character was added to render nothing: true (cb0f8fd, 807df4f) to fix a bug in Safari. (Thank you @matthewd for hunting this down.)

Since this bug has been fixed in Safari itself a long time ago (based on the timestamps it should be fixed in Safari 2.x or perhaps 1.x in ~2005), it's probably a good time to remove this.

I wrote a simplified version of the webkit test case which you can access here:

• xhr async version: http://lit-anchorage-8910.herokuapp.com/async (source)
• xhr sync version: http://lit-anchorage-8910.herokuapp.com/sync (source)
(The controller doesn't actually use render nothing, but it should have the same effect)

I tested this on a variety of browsers on [browser stack(http://www.browserstack.com/)], including Safari 4.0 and Firefox 3.0 and it seems to work fine.

Ideally, I'd like to see this test case fail on an older version of safari (you might need safari 2.0 or even 1.0). If you have access to one of those super old browser, please help run the test case and let me know what happens

Otherwise, I am fairly confident that this should be okay.

cc @dhh @jeremy @sikachu @matthewd

Fixes #14336

You can merge this Pull Request by running

git pull https://github.com/chancancode/rails rm-single-space
Or view, comment on, or merge it at:

#14883

Commit Summary

• Removed the single space character for Safari
File Changes

• M actionpack/lib/action_controller/metal/rendering.rb (2)
• M actionpack/test/controller/new_base/render_body_test.rb (14)
• M actionpack/test/controller/new_base/render_html_test.rb (14)
• M actionpack/test/controller/new_base/render_plain_test.rb (14)
• M actionpack/test/controller/new_base/render_text_test.rb (14)
Patch Links:

• https://github.com/rails/rails/pull/14883.patch
• https://github.com/rails/rails/pull/14883.diff
—
Reply to this email directly or view it on GitHub.

[jeremy]

👍

Should update these tests rather than removing them. We expect these to return an empty (unpadded) body.

[arthurnn]

should I close #14350 then? or should we go ahead with both?

[chancancode]

I haven't dug too deep into the fix itself, I'll take a look at #14350 and pull it whatever we need 👍

Just want to get the test case up and have other people check it!
—
Sent from Mailbox for iPhone

On Sun, Apr 27, 2014 at 2:53 PM, Arthur Nogueira Neves
notifications@github.com wrote:

should I close #14350 then? or should we go ahead with both?

Reply to this email directly or view it on GitHub:
#14883 (comment)

[kaspth]

I've been trying to judge how likely a Mac user is to still be using Safari 3.0 and 2.0.

The data:
OS X usage numbers from March 2014
Safari versions matched with their supporting OS'es

So...
Safari 2.0 was only on Tiger which has a market share of 1%.
Safari 3.0 was on Leopard which has a market share of 3%.
Safari 4.1.3 was the last version to support at least Tiger and was released in late 2010.

Also...
How many of those 1% and 3% even use Safari?
How likely is it these old browsers hit a Rails app, which uses renders nothing: true?

🎉 I think we can declare that bug fixed. 🎉

[chancancode]

I agree that we don't really have to worry about safari < 5.

My motivation for testing this on a broken version of safari is to verify the correctness of the test cases and make sure it's testing against the right bug.

Now that I have a test case that passes everywhere it could either be that the bug is fixed everywhere, or the test case is completely wrong :)

I am betting on the former, but it would be nice to know for sure