661677 - Command-click on a tbpl revision highlight it instead of opening in a new tab

Status: RESOLVED FIXED

(Tree Management Graveyard :: TBPL, defect)

Description

[Jeff Muizelaar [:jrmuizel]]

This is a pain.

Comment 1

[Steve Fink [:sfink] [:s:]]

This is from bug 654528.

I didn't consider that conflict because I middle-click to open in a tab. And I never look at a build log without clicking to see the autostar suggestions first, so I have an alternate link anyway.

Ugh. The selection capability is useful. But I can see how annoying this would be if you ctrl-click. Any ideas for an alternate? Perhaps it's time to bring back shift-click. Everything's going to bother somebody, so we just need to settle on something. Preferably whatever's preferred by whoever has the biggest stick.

Comment 2

[Markus Stange [:mstange]]

What if we make multiselecting only work while the star panel is open, and let the links be links while it's not? How often do people open changesets / logs while writing stars?

Comment 3

[Phil Ringnalda (:philor)]

That might work for the log openers (dunno, I fairly often open logs in midstream, but then I virtually never open them from the letter, preferring the log link in the summary), but it would break me, since I've started selecting up a big swath of failure before opening the comment panel, since that way I don't have to keep moving it out of the way to get everything selected.

Comment 4

[Phil Ringnalda (:philor)]

Oh, wait, "a tbpl revision" - is this about cmd+clicking changeset links? I see that they do get multiply-selected with cmd+click, but... why? What can you do with them once you've selected several?

Comment 5

[Markus Stange [:mstange]]

The revisions appear in the comment box, but I'm not sure when you'd need more than one of them.

How about making the change I suggested in comment 2 only for changeset links? Or just dropping their multiselection capability completely?

Comment 6

[Steve Fink [:sfink] [:s:]]

(In reply to comment #4)
> Oh, wait, "a tbpl revision" - is this about cmd+clicking changeset links? I
> see that they do get multiply-selected with cmd+click, but... why? What can
> you do with them once you've selected several?

Oh! Thanks. I hadn't realized that either; I was assuming this was about ctrl-clicking builds, not changesets. Ok, that changes the equation significantly.

It is currently only barely useful to ever select multiple changesets. The only scenarios I can think of are (1) "fixed by backout A or backout B, don't know or care which"; and (2) "fixed by backout A of bustage from B". The latter I plan on making more useful (by autodetecting which is A and which is B from a multiselection). But none of this is worth breaking ctrl-clicking; I never would've done that had I realized. (I middle-click, so didn't notice.)

I'm not fond of comment 2 because the comment box (that's what you mean by "star panel", right?) currently gets in the way of both changesets and builds when it's open, and I'd really like to move it to the left so that it only blocks changesets. (I have a patch that moves it, but it's part of a much larger patch involving creating a new overlay window for fancy self-service stuff. I probably ought to split out the one-line CSS change.) So I don't really like the multiselection to only work in the situation where you can't use it because the comment box is in the way.

So we should remove the ctrl-click behavior for changesets asap. As for what to switch it to...

How bad do people think it is to be breaking ctrl-click for build links? Like philor, I always use the log link in the summary. But I don't like changing basic web interactions, now that I'm aware that I am. I ask because I want to know if we need a different multiselect method for both changesets and builds, or just for changesets.

Options:
1. Use shift-click.
2. Ctrl-click only multiselects when comment box is open (comment 2).
3. 's' to go to "selection mode", then ctrl-click works. (I know, this seems insane right now, but it would make somewhat more sense when I finish my self-service integration where you want to eg "select all pending builds".)
4. Plain click both activates and selects, so you accumulate selection as you move around. Click on non-link space to deselect all. Deselect one with another click or a double-click; both have issues.
5. Double-click

I don't like any of them very much. IMHO, the least evil would be: keep ctrl-click to multiselect builds, double-click to multiselect changesets.

Or maybe add a checkbox to changesets. It could even be a hover-only checkbox.

Comment 7

[Steve Fink [:sfink] [:s:]]

Attachment: Remove multiselect for changesets

For now, just remove multiselect from changesets.

Comment 8

[Markus Stange [:mstange]]

Comment on attachment 537392 [details] [diff] [review]
Remove multiselect for changesets

Thanks! Can you please also file the RelEng deployment bug after landing?

Comment 9

[Arpad Borsos [:Swatinem]]

(In reply to comment #6)
> 4. Plain click both activates and selects, so you accumulate selection as
> you move around. Click on non-link space to deselect all. Deselect one with
> another click or a double-click; both have issues.
> 5. Double-click

As we don’t use targets for links, the normal click or double click would redirect the whole tbpl page to hg.
So please make sure to pick something that does not break this way.

Comment 10

[Steve Fink [:sfink] [:s:]]

http://hg.mozilla.org/users/mstange_themasta.com/tinderboxpushlog/rev/c91d15fa432d

Comment 11

[Jesse Ruderman]

How about alt+click? Alt+click is normally "download link target", and it doesn't make much sense to download the hg page.

Comment 12

[Mounir Lamouri (:mounir)]

How about drag & drop of the changeset to the comment box like we do with failing jobs? I guess we could prevent the default action (copying the entire URL) to only copy the changeset id?

Comment 13

[Markus Stange [:mstange]]

(In reply to comment #12)
> How about drag & drop of the changeset to the comment box like we do with
> failing jobs? I guess we could prevent the default action (copying the
> entire URL) to only copy the changeset id?

This already works :)

Comment 14

[Steve Fink [:sfink] [:s:]]

(In reply to comment #9)
> (In reply to comment #6)
> > 4. Plain click both activates and selects, so you accumulate selection as
> > you move around. Click on non-link space to deselect all. Deselect one with
> > another click or a double-click; both have issues.
> > 5. Double-click
> 
> As we don’t use targets for links, the normal click or double click would
> redirect the whole tbpl page to hg.
> So please make sure to pick something that does not break this way.

For #4, I was confused and still thinking of the build links. You are right, of course, for the changeset links. So forget #4.

For #5, I was thinking of a nasty "add a timer to single-click so double-click can override it" hack. But I hate delays in UIs, especially artificial delays.

Comment 15

[Steve Fink [:sfink] [:s:]]

(In reply to comment #13)
> (In reply to comment #12)
> > How about drag & drop of the changeset to the comment box like we do with
> > failing jobs? I guess we could prevent the default action (copying the
> > entire URL) to only copy the changeset id?
> 
> This already works :)

Though I really think we should move the comment box to the left to get it away from the build links. But that would make drag & drop *really* annoying for the changesets.

Comment 16

[Markus Stange [:mstange]]

This has been deployed.