Bug 561312 - inconsistent behavior when clicking on a element which has multiple hyperlinks
Summary: inconsistent behavior when clicking on a element which has multiple hyperlinks
Status: NEW
Alias: None
Product: Platform
Classification: Eclipse Project
Component: Text (show other bugs)
Version: 4.15   Edit
Hardware: All All
: P3 major (vote)
Target Milestone: ---   Edit
Assignee: Platform-Text-Inbox CLA
QA Contact:
URL:
Whiteboard:
Keywords:
Depends on:
Blocks:
 
Reported: 2020-03-21 04:52 EDT by Gayan Perera CLA
Modified: 2020-04-01 21:42 EDT (History)
3 users (show)

See Also:


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description Gayan Perera CLA 2020-03-21 04:52:20 EDT
When there are multiple hyperlinks for a element, clicking on that element just opens the first hyperlink. This hyperlink is arbitrary and based on how the extensions were loaded. This can cause inconsistency with the user experience.

For example on a java method, we get
- Open Declaration
- Open Implementation

Today when clicking on a java element it is always runs the open declaration. This is fine until it is only jdt.ui contributes hyperlinks.

Now if a another plugin contributes a hyperlink to java elements, this plugin's hyperlink might be loaded before the jdt.ui ones, 
- New Hyperlink
- Open Declaration
- Open Implementation

this will break the usability of open declaration when clicking on the java element.

<<Suggestion>>:
Introduce a priority into hyperlink detector extensions, so that we can always make sure a certain detector's hyperlinks are always on top or on bottom compared to another.
Comment 1 Gayan Perera CLA 2020-03-21 04:53:05 EDT
If someone can look at this and let me know if the suggested solution is good enough i would more than happy to provide a patch.
Comment 2 Gayan Perera CLA 2020-03-21 04:55:58 EDT
I think this is a major issue since it can break the user-ability or the user flow that a user is used to.
Comment 3 Mickael Istria CLA 2020-03-22 09:53:32 EDT
Prioritizing multple contributions is always a tricky issue.
With the same set of contributions, some Eclipse users, plugin providers or RCP product providers would perceive a different one as being the priority. So there is no obvious truth about what's the real highest priority.
Ie if the IDE is primarly used for multiple editors where the "New hyperlink" is the only Ctrl+click available, and user installs JDT and starts using Java, uses Ctrl+Click and goes to something that's not what's expected by "new hyperlink" (ie Open Definition as you're suggesting), then user would also feel an inconsistency.

I'm really uncertain there is a real definition of "priority" we can use here... However, we can try to improve the user story a bit so the previously used HyperlinkProvider on the editor takes priority over the "default" one, ie we dynamically decide of a priority based on actual usage.
Comment 4 Gayan Perera CLA 2020-03-22 14:28:15 EDT
@Mickael nice i like your idea, but do we have a usage tracker engine inside eclipse already ? I have scene the relevance attribute in completions, but i'm not sure how the history relevance is tracked. And also since the hyperlink is on platform level we probably need to make this feature a platform level feature which can be beneficial for all the file types. any tips ?
Comment 5 Mickael Istria CLA 2020-03-22 16:24:29 EDT
(In reply to Gayan Perera from comment #4)
> @Mickael nice i like your idea, but do we have a usage tracker engine inside
> eclipse already ?

We don't need a usage tracker engine IMO. My idea is that when user selects an hyperlink, we store in some preference, or a memento, whatever that this link (or link provider) was selected, or even better, we store the list of all selected hyperlinks and just "bubble up" as 1st item the one that was just selected. Then, later, when looking for hyperlinks, the preference/memento is read to order the hyperlinks.
It's basically implement a Last Recently Use (LRU) sort of the hyperlinks.

> And also since the
> hyperlink is on platform level we probably need to make this feature a
> platform level feature which can be beneficial for all the file types. any
> tips ?

Sure, ideally, this could be implemented in the AbstractTextEditor or even deeper in its hierarchy so all text editors could leverage that strategy.
I don't recall immediately how hyperlink/detectors are hooked to the editor, but just placing a breakpoint in your custom hyperlink should give you a stack containing good hints about the piece of code to change.