This general centering issue was filed here: https://bugs.chromium.org/p/chromium/issues/detail?id=598805
For dragging 1px width change: https://bugs.chromium.org/p/chromium/issues/detail?id=598818 See the section below, "Resizing, one pixel at a time".
For the missing resize bars: https://bugs.chromium.org/p/chromium/issues/detail?id=598822 See the section below, "Resize bar is not always available".
For the missing rotate button: https://bugs.chromium.org/p/chromium/issues/detail?id=598829 See the section below, "Rotate not always available"
For the missing "hover" behavior: https://bugs.chromium.org/p/chromium/issues/detail?id=600180 See the added comment below.
In Chrome 49, the dev tools "device mode" has had some UI changes, some of which are better, and others that have made our jobs a little harder than they used to be.
The TLDR suggestion is, don't center the subject page in device mode. Let it be anchored to the left like it used to be.
New Device Mode UI
So below is what the new dev tools device mode looks like. When you change the width of your subject page, the whole thing stays centered. There are three ways you might affect the subject page's centering:
The subject page is a moving target
This is the primary underlying issue. Whenever you resize something horizontally, the whole thing moves with you.
No fixed point of reference
When doing layout work, I continually adjust the width, watching how various elements on the page reflow. When the whole page is moving, there is no fixed point of reference for our eyes. So checking that a DOM element performed a subtle change in size (width) is nearly impossible to see visually. E.g., because all points of reference are changing simultaneously with page width, I can't tell if my div grew or not.
Workflow
Centering the subject page has another unintended consequence on our workflow, regarding something as trivial as how we place our windows on our monitor. Inevitably, you will have both your browser window (with your subject page), and the dev tools window opened. Something like this:
Notice how the width of the browser window has been made very narrow. Since version 49, that's the only way to get Chuck to stay visible on the left while I'm pixel-pushing in dev tools. But when pixel-pushing, we must actively change the width of our subject page, so the browser window can't really be this narrow. The whole window has to be wider to accommodate our device resizing efforts. Our browser window ends up getting parked at a more normal size, like this:
Where's Chuck!? This is a "normal" window size, with iPhone4 device dimensions selected. Annoyingly, Chuck is hiding behind my dev tools window. I know, big deal. But yes, big deal. But in order to work on Chuck iteratively, all that extra clicking around, or alt-tabbing, or dragging both window size and subject page resize bar is extremely disruptive. It is disruptive enough to compel me to file this issue. ;-)
Of Desktops, Stacks, and Heaps
This problem actually ripples out to the whole desktop. By centering the subject page, "dead space" is created on both sides of the subject page.
This is valuable real estate on my monitor. In order to give us humans the best opportunity to maximize our desktop space, we need just one pool of dead space. Then we can decide how to cover up that dead space in order to maximize desktop utility.
Remember in computers how a stack and heap grow toward each other? I.e., this:
Remember how the primary chunk of unallocated memory lies in the middle, between the stack and the heap? What if the stack was arbitrarily located right in the middle? Then we'd have two large unallocated spaces to contend with. Maximizing utility becomes much harder.
If you abstractly think of your monitor's space from left to right, think of the heap at one end, and the stack at the other, and the middle space is up for grabs. By presenting "dead space" on both sides of the subject page, you are splitting/fragmenting "unallocated screen space". In short, it makes it more difficult to maximize the utility of space on our desktops.
Of course monitors are not one-diminsional, left-to-right; maximizing utility applies in all dimensions. In fact, Chuck is always aligned to the top, even when I make my resize my vertical height. Chuck stays put, correctly.
Resizing, one pixel at a time
Centering the subject page also affects your dragging resolution. You can only change the width by two pixels at a time, never by one pixel. The width is always odd (or even) when you drag to resize. In the example below, you can change the width from 485 to 483 or 487, but nothing between.
One can see why if both the left and right bounds are both being incremented or decremented by one. The net change is always +/- 2px.
A person should be able to drag a one pixel change. It is not a superhuman thing. Yes, I know you can edit the width field at the top, and even use arrow keys in that field. But that's too much mouse-to-keyboard context switching. I'm already doing a drag operation to test DOM element reflow reactions. Don't make me stop my dragging-in-progress so that I have to edit a number in a text field just so I can hit a number that dragging should have hit.
Resize bar is not always available
Prior to version 49, a draggable resize bar was always available. Now it is only available only if you change your device to "Responsive". This is unnecessary mouse time. Just give us the resize bar at all times. And when I drag it, the device will no longer be an iPhone4. Just like old times.
Yeah I know there's no such thing as an iPhone4 that's 330px wide, and that if I drag the width wider, then I'm not really testing an iPhone4 any more, and that User-Agent string is kind bogus. Yep. That's what I'd expect. But give me the resize bar and let me do it.
I created a custom device "TestDevice", the same size as an iPhone4. So I'm no longer testing an iPhone in terms of user-agent. It's just a really small screen 320x480. So now there's no reason to not have resize bars presented. Alas, there are none, as shown below. :-(
In the versions prior to 49, when you dragged the resize bar and matched the dimensions of some device, it would automatically select that device. This would not be necessary now. Because I can create my own devices, I can create dimensions identical to any device. Trying to pick one device when there are multiple matches just doesn't work. So my suggestion is that once you drag the resize bar, change me to the "Responsive" device and leave me on that device. It was my choice to leave my iPhone4 device when I dragged the width.
Rotate not always available
You have to select a device in order to get the button that swaps width and height. You cannot do it when responsive device is selected.
It is useful to swap width and height at any time. I wouldn't have noticed the button was gone, except that I did notice, because I wanted to click it and it wasn't there! Again, just like the draggable resize bars, always give us the button and let us decide to use it or not. The button won't be clutter; it is already present for all other cases, and missing only in the responsive device case. Don't assume there is no utility in it just because it doesn't reflect a real-world thing (i.e. a desktop, rotated). Just leave the button there. Dev Tools users are smart people, they'll understand.
update: I just re-discovered how I "felt" the rotate button was missing. If you are in device mode, the gray bar at the top is broken into chunks that represent some generic device widths, i.e. "Mobile Small 320px", "Mobile Medium 375px", "Mobile Large 425px", "Tablet 768px", etc. If you click any of these it will put you in "Responsive" device mode and change the width appropriately. In the center, a text label indicates what kind of generic device you selected. So I selected "Tablet 768px". At this moment it would be very reasonable to want to rotate this generic tablet I just selected. But there is no rotate button present. Here's how it plays out: