1077554 - Internal navigation links should open in the same tab

Status: RESOLVED FIXED

(Tree Management :: Treeherder, defect, P2)

Description

[Mike Hommey [:glandium]]

I think treeherder shouldn't open links in new tabs. As a matter of fact I find this behavior extremely annoying. The main reason is that while it's possible to make the browser open a given link in a new tab when the site doesn't do it itself, the opposite is not possible!

Comment 1

[Phil Ringnalda (:philor)]

Dependencies: every bug both in treeherder and in Fx/Chrome/whatever other browser we use that it would take to make accidentally loading something over the top of treeherder and then going back not lose any state.

Comment 2

[Ed Morley [:emorley]]

I quite like the current behaviour, and it matches TBPL in many cases.
As philor said, accidentally clicking on a link (plus also intentionally clicking on a link, but forgetting to ctrl-click) is pretty destructive, from a lost state + lost time + perf hit point of view at the moment. Until that changes I think the current behaviour is the better of two evils.

Are there specific links/use cases where you think people are more likely to not want a new tab than others? (I suspect the split here is "sheriff pinned tabs" vs "dev taking a quick glance at one failure log" use case differences)

Comment 3

[Mike Hommey [:glandium]]

At the very least, the links that stay in treeherder. Like the ones opening the view for a single push, or for a single author. Most other "internal" treeherder links stay in the same tab (like, switching branches), I don't see why those should be different.

Comment 4

[Ed Morley [:emorley]]

(In reply to Mike Hommey [:glandium] from comment #3)
> At the very least, the links that stay in treeherder. Like the ones opening
> the view for a single push, or for a single author. Most other "internal"
> treeherder links stay in the same tab (like, switching branches), I don't
> see why those should be different.

Ah I agree, those should be same tab.

Comment 5

[Ed Morley [:emorley]]

Attachment: Use target="_blank" in fewer places

This removes use of target=_blank for:
a) internal navigation links
b) any separate standalone pages, where using the browser forward/backward functionality won't lose state (eg help page and logviewer)

Comment 6

[Cameron Dawson [:camd]]

Comment on attachment 8547914 [details] [review]
Use target="_blank" in fewer places

Looks almost perfect.  Just a couple changes to the title text and it's good to merge.  Please don't take this rejection personally.  I still like you, Ed.  :)  Does an r- here sound jerk-y?

Comment 7

[Ed Morley [:emorley]]

Comment on attachment 8547914 [details] [review]
Use target="_blank" in fewer places

(In reply to Cameron Dawson [:camd] from comment #6)
> Looks almost perfect.  Just a couple changes to the title text and it's good
> to merge.  Please don't take this rejection personally.  I still like you,
> Ed.  :)  Does an r- here sound jerk-y?

Not a problem - good spot :-)

Comment 8

[Cameron Dawson [:camd]]

Comment on attachment 8547914 [details] [review]
Use target="_blank" in fewer places

truly magnificent!

Comment 9

[Treeherder GitHub Bugbot]

Commit pushed to master at https://github.com/mozilla/treeherder-ui

https://github.com/mozilla/treeherder-ui/commit/3c8ef0d408cf5e71572935a959a83d2233b1058a
Bug 1077554 - Use target="_blank" in fewer places

It's currently (a) incorrectly being used for internal navigation links,
and (b) being used in cases where the user would likely not expect it.
eg: the standalone help page, where having to use the back button would
not lose any state (unlike the main Treeherder UI).

Comment 10

[Ed Morley [:emorley]]

In production :-)

Comment 11

[Treeherder GitHub Bugbot]

Commit pushed to master at https://github.com/mozilla/treeherder

https://github.com/mozilla/treeherder/commit/ca0ed7248fa412b88eb66873ab4083f02bb419c7
Bug 1077554 - Use target="_blank" in fewer places

It's currently (a) incorrectly being used for internal navigation links,
and (b) being used in cases where the user would likely not expect it.
eg: the standalone help page, where having to use the back button would
not lose any state (unlike the main Treeherder UI).