Entire content pane now draggable in 1P5: not compatible with some types of pointing device

semblance

Hi, just upgraded to Yosemite and 1Password 5 over the weekend.

Everything looks good so far, except for one small issue: the entire content pane now seems to have become a drag target in 1Password 5! By that I mean, if you drag anywhere in the RH content pane, the entire window moves. This is horrible.

I use a pen and tablet as my primary pointing device, and one of the behaviours of these kinds of pointing devices is that it's very difficult to click on something without also dragging ever so slightly at the same time (even if only a few pixels). It's almost impossible to make a "true" drag-free click.

Normally, this is not an issue at all, because clickable targets are rarely draggable and vice versa. Even for targets that are both clickable and draggable, a small accidental drag of a few pixels normally has absolutely no effect (e.g. when selecting an object in Finder).

But in 1Password 5, I'm suddenly finding that when I click anywhere in the RH content pane, the entire 1Password window moves a few pixels in a random direction. This is most disconcerting.

I do understand the part of Yosemite's new UI is that the title bar can blend into the content area in an app.

However, I don't believe the intention was that the entire content area becomes draggable. Surely the draggable area is still meant to be a strip across the top where the title bar used to be? This is certainly the case with all the Apple apps I've tried so far, whether they have traditional-looking title bars or not.

I really hope this behaviour can be changed.

sjk

Hi @semblance,

Thanks for reporting this issue. It probably isn't intended for the main window to be draggable after a click-and-hold on any empty area within the item list and details panes. I've filed it as a bug in our tracker.

ref: OPM-2463

MrC

See also my OS X Beta thread: "Dragging list widener moves main window".

sjk

Thanks for making a correlation between the issue here and the one you reported, @MrC. Increases the bug-worthiness of this one. :)

semblance

Thanks @sjk for the rapid response, and @MrC for pointing out your other thread.

As @MrC pointed out, it's not only that a click-and-hold on any empty area within the item list and details panes makes the whole window draggable — it's also when you click on many of the controls. For example:

• The "copy" and "open and fill" buttons that appear dynamically next to a field will also drag the whole window if you click and hold them. I think this is a problem for any user, because normally in any pointer-driven UI it's possible to "cancel" your intention to click a button after you've clicked on it, by dragging your pointer off the button before releasing. But here you can't do that because the entire window moves with your pointer when you drag, which means whenever you release, your pointer is still on the button so it always fires. Try it on an "open and fill" button. It's also particularly disconcerting for pen and tablet users like myself, because every time I click on a "copy" button, the window moves slightly.
• In the Search field, if you already have text there and you want to replace it, it seems reasonable to drag over the existing text in order to select it, and then start typing to overwrite the existing text. But if you start dragging too far outside the existing text (but still within the search field), then the entire window moves instead which is not the expected behaviour at all.

Anyway, I'm glad I'm not the only one affected by this issue!

sjk

Thanks for pointing out those other ways the main window can be unintentionally dragged, @semblance.

We may already have a bug filed for the first and the second looks like a regression of a version 4 fix. The first In version 4 doesn't drag the main window but the action isn't cancelled when moving the pointer off the control.

I'll make sure all this gets filed. Thanks again, to you both. :)

schwaggy

Well look at that!
I had commented here that this was only when dragging the separator bar, but can now confirm it's the entire window. So glad to see it's a known issue and will be fixed.

sjk

Thanks for connecting those dots, @schwaggy. :)

We'll fix issues with click-and-hold dragging on wrong spots in the main window, wherever they are, moving the window.

Lamplighter

FWIW: Maybe it's is a deliberate design, but there seems to be a similar issue in the 1P5 version of the Login items of the "list display"...

It can be triggered by (deliberately / inadvertantly ?) clicking on an item in the list and dragging it out of it's current list position. The entire pane then becomes "drag-able". This drag-ability of the pane can be manually reversed ( and even toggled) by Option-click on the pane.

Hope this helps sort out the issue.

aal

Additional info: If I hold the CTRL key while clicking on the separator bar (in View > List Layout > Top)....1P allows the separator to be moved down. Without the CTRL key, it only allows dragging the separator up; dragging down moves the whole app window.

Thanks

sjk

Thanks for those other examples, guys.

@Lamplighter‌: I've included that with the open bug report.

@aal: Should be fixed in 5.0.2.BETA-1:

• Fixed problem where split view could not be resized in top layout mode. {OPM-2393}

semblance

Hi, while this bug was mostly fixed in 5.0.2, there is one small issue that still remains:

• In the Search field, if you already have text there and you want to replace it, it seems reasonable to drag over the existing text in order to select it first. But if you start dragging too far outside the existing text (but still within the search field), then the entire window moves instead which is not the expected behaviour.

sjk

You're correct, @semblance. That specific bug with dragging in the search field moving the main window hasn't been squished yet. Thanks for the reminder. :)

ref: OPM-2218