Editing an objects rotation with the rotation rings often causes the object to jump to position <0,0,0> on the region and rotation changes to <0,0,0>

Steps To Reproduce

REPRO 1

• Rez a prim (default cube or sphere will do - video shows sphere but cube reproduces just as easily)
• Sit on the prim
• Right click -> Edit the prim
• Under object tab set Z rotation to 270 by typing 270 into the text box and hitting Enter key.
• Change edit mode to rotation so you see the rotation rings
• Make small rotation edits using the rotation rings but keep the Z rotation fairly close to 270, for example 268-270.
• If the bug does not reproduce, close the edit floater and edit on the prim again, change to rotation mode and repeat.

NOTE: Bug also reproduces when the X or Y rotation is close to 270

REPRO 2

This is the same repro as above but without sitting on the prim.
The bug is much easier to reproduce when sitting on the prim, but sitting on the prim is not necessary to reproduce.

• Rez a default cube.
• Edit cube.
• Under object tab set Z rotation to 270 by typing 270 into the text box and hitting Enter key.
• Change edit mode to rotation so you see the rotation rings
• Make small rotation edits using the rotation rings but keep the Z rotation fairly close to 270, for example 268-270.
• If the bug does not reproduce, close the edit floater and edit on the prim again, change to rotation mode and repeat.

NOTE: Bug also reproduces when the X or Y rotation is close to 270

Observed Behaviour

REPRO 1

• Please see attached demo video.
• When the X, Y or Z rotation values are at or close to 270, attempting to rotate the prim with the edit rings will easily cause the prim to shoot off to position <0,0,0> on the region and the prims rotation also changes to <0,0,0>
• Your avatar will remain seated on the prim and will also be at position <0,0,0>
• Often, just touching (left clicking) one of the rotation rings without actually moving it will cause this to happen.

• When this bug reproduces, you will have the prim still held in edit - observe the prims position in edit is <0,0,0> and it's rotation has also changed to <0,0,0>.
  See Fig 1 attached.
• This is not a client side glitch - observers will also see you seated on the prim at <0,0,0>

• If your camera does not follow the prim when it moves to <0,0,0>, hit ESC a couple of times to reset your camera view onto your avatar.
• Observe that your avatar is sitting on the prim at position <0,0,0>
  See Fig 2 attached.

• Hitting ESC may have exited edit mode.
• If so, edit on the prim again and use CTRL+Z to undo the position and rotation change to take the prim back to its previous (correct) position and rotation.
• Observe the prim and your avatar move back to the correct position on the region and the correct values display in the edit floater for position and rotation.
  See Fig 3 attached.

• When this bug reproduces, I always get the following lines immediately in my log as soon as the object position changes to <0,0,0>:

  WARNING: LLXform::warn: Non Finite in LLXform::setRotation

  WARNING: LLXform::warn: Non Finite in LLXform::setPosition(LLVector3)

• Log file attached from the session I made the demo video.
  You can see the above log warnings at:
  Line 949 - 2014-08-20T01:47:01Z
  Line 1535 - 2014-08-20T02:00:06Z
  Line 1680 - 2014-08-20T02:01:05Z

REPRO 2

• When the X, Y or Z rotation values are at or close to 270, attempting to rotate the prim with the edit rings will easily cause the prim to shoot off to position <0,0,0> on the region.

• There are 2 different behaviours seen when this happens

1. The prim will very briefly disappear from your view and then reappear back in its original position.
When this happens, observe that you have lost edit focus on the prim so the edit fields will be greyed out.
See Fig 4 attached.

Again, observe in logs that you see the following lines:

WARNING: LLXform::warn: Non Finite in LLXform::setRotation

WARNING: LLXform::warn: Non Finite in LLXform::setPosition(LLVector3)

WARNING: LLFloaterTools::refresh: Failed to get selected object

2. The prim will disappear from your view, you lose edit focus on the prim and the edit floater fields are greyed out.
The prim will not return to its correct position and it is apparantly "lost"
Go to location <0,0,0> and you will find your prim here.

Expected Behaviour

To be able to build and edit on the official viewer without my objects suddenly ending up at <0,0,0> on the region.
To be able to sit on pose balls and edit them into position without suddenly ending up sitting at location <0,0,0> on the region.

Other Information

I am fairly sure that this bug was introduced with the STORM-1915 fixes (DRTVWR-351)

I really want to mark this Severe because it has been driving me crazy until I realised what was happening.
Over the last week or so I have been losing random objects when editing them with the official viewer and today I discovered them all in a pile at <0,0,0> on the region. Mystery solved

To Do: Test a pre DRTVWR-351 build and make sure this does not reproduce.

• Confirmed this bug does reproduce on Second Life 3.7.3 (287558) Mar 4 2014 20:36:12 (Second Life Test)
  This is the test build for STORM-1915
  Build link: http://automated-builds-secondlife-com.s3.amazonaws.com/hg/repo/contrib-storm-1915/rev/287558/index.html

• Confirmed this bug does reproduce on Second Life 3.7.11 (291465) Jun 25 2014 14:40:06 (Second Life Release)
  http://wiki.secondlife.com/wiki/Release_Notes/Second_Life_Release/3.7.11.291465
  This is the Snowstorm-RC viewer containing the STORM-1915 fixes that was promoted to release on July 8th

• I am unable to reproduce this bug on Second Life 3.7.10 (291134) Jun 17 2014 19:46:37 (Second Life Release)
  http://wiki.secondlife.com/wiki/Release_Notes/Second_Life_Release/3.7.10.291134
  This is the Share-RC, which was promoted to release on June 23rd.
  This was the default release before Second Life 3.7.11 (291465) (above) was promoted