843064 - Make clickable items with single action available trigger that action on click

Status: RESOLVED WONTFIX

(Webtools Graveyard :: DXR, defect)

Description

[Josh Matthews [:jdm]]

There are lots of places where you can click and choose "Search for ..." from a menu. This is an unnecessary level of indirection; it would be much nicer to make the click trigger the search immediately, and make them proper top-level links (ie. hover shows the pointer and link target) so they can be opened in new tabs easily.

Comment 1

[Erik Rose [:erik][:erikrose]]

Sounds good to me. There aren't any situations where the user would be surprised by this, are there? Any "Oh gee, I thought I'd be able to [find definitions or whatever], but instead it just jumped me to a search" possibilities?

Comment 2

[(no longer active)]

(In reply to comment #1)
> Sounds good to me. There aren't any situations where the user would be
> surprised by this, are there? Any "Oh gee, I thought I'd be able to [find
> definitions or whatever], but instead it just jumped me to a search"
> possibilities?

They may be surprised the first time but this is easy to learn and ultimately the desired behavior for a code indexing tool, so we should implement it.

Comment 3

[Erik Rose [:erik][:erikrose]]

Thanks. I welcome any future +1s you care to leave on behavior-change bugs since you're an actual DXR user. :-)

Comment 4

[Nick Cameron [:nrc]]

The only downside I see to this is workflow with opening in a new tab. I often open new searches in a new tab. So click the link then ctrl+click or middle click the search link. Middle clicking the first link does nothing. With the proposed behaviour, you would have to try middle clicking, then left click each link to be sure you weren't going to get the new search in the old tab. I'm not sure if there is a good answer for this.

Comment 5

[Nick Cameron [:nrc]]

Attachment: patch

Not sure if you prefer bugzilla reviews or Github pull requests, but here is a patch.

As far as I can see we only get one item menus when the only option is search, so in this case we now go straight to the search page. Am I missing any other cases?

The downside of this is that words which are not underlined (i.e., don't look like links) behave like links and words which are underlined (look like links) don't behave like links, well they produce a popup menu. So that is not ideal. Also this patch does not make the words behave link links in the sense that there is no url 'popup' in the browser. I guess it would be better to just use |a| elements for the links rather than the click event, but that is more changing. It is probably easier to hack the link 'preview' thing in JS, I can do that as a follow up patch, if we like the current approach.

Comment 6

[Nick Cameron [:nrc]]

(In reply to Nick Cameron [:nrc] from comment #5)
> Created attachment 775268 [details] [diff] [review]
> patch
> 
> Not sure if you prefer bugzilla reviews or Github pull requests, but here is
> a patch.
> 
> As far as I can see we only get one item menus when the only option is
> search, so in this case we now go straight to the search page. Am I missing
> any other cases?
> 
> The downside of this is that words which are not underlined (i.e., don't
> look like links) behave like links and words which are underlined (look like
> links) don't behave like links, well they produce a popup menu. So that is
> not ideal. Also this patch does not make the words behave link links in the
> sense that there is no url 'popup' in the browser. I guess it would be
> better to just use |a| elements for the links rather than the click event,
> but that is more changing. It is probably easier to hack the link 'preview'
> thing in JS, I can do that as a follow up patch, if we like the current
> approach.

And a little bit of research shows that it is not possible to fake the status bar URL hint thing. So maybe we need to use proper |a| links after all.

Comment 7

[Nick Cameron [:nrc]]

Attachment: patch

Removed some commented out lines. Sorry for the email churn.

Comment 8

[Erik Rose [:erik][:erikrose]]

Having a look now. For future reference, I do prefer Github pull reqs and will notice them more promptly as well.

Comment 9

[Erik Rose [:erik][:erikrose]]

What do you think of giving the menu-giving tokens dotted underlines (when moused over) and the non-menu-giving tokens (normal |a| tags) solid ones? That would be straightforward with CSS, and we wouldn't have to do any JS hackery.

Comment 10

[Nick Cameron [:nrc]]

(In reply to Erik Rose [:erik][:erikrose] from comment #9)
> What do you think of giving the menu-giving tokens dotted underlines (when
> moused over) and the non-menu-giving tokens (normal |a| tags) solid ones?
> That would be straightforward with CSS, and we wouldn't have to do any JS
> hackery.

That's actually pretty tricky. The only time we don't have a menu and therefore click straight through to the search, is when there is no real element that gets clicked on. In this circumstance, we have a large element and we find the word clicked on within it using JS. So, since we don't have an element per word, there is nothing to simply set a class on. We can't easily use JS to detect mouse over either for the same reason. So I'm not sure how to add the underline to a word as we hover it.

I'm not much of a web-programmer though. Any suggestions?

Comment 11

[Sylvestre Ledru [:Sylvestre]]

We are not going to work on that!