New Variable: Access to right-clicked link text #94

Closed
neocotic opened this Issue Apr 17, 2012 · 4 comments

Comments

Projects
None yet
1 participant
@neocotic
Member

neocotic commented Apr 17, 2012

Ticket 5 from uservoice:

Hi, Alasdair!

I just discovered your extension and I really want to congratulate you, not only because of that but also for all the effort (visual design, simplicity, info design) you've been putting in the supporting site.

Awesome, really!

Also congratulations on passing the 1,000 users mark!
Hang in there, it will grow, I'm sure!

Now, my question: I want to create a simple variation to get the text on the link, plus the url on the link, but I don't seem to find a URLtext or anything similar in the 'Standard variables' help table.

I tried to use {selection} but for that to work I have to select all the text of the link which is rather cumbersome...

Is this possible?

Thanks again for your work on the "Template" extension!

  • Ricardo Nuno Silva

My reply:

Hi Ricardo,

Thanks for your great comments! They mean a lot to me as I take great pride in Template, as it was originally just created as a way to copy a page's URL without any formatting, it's clearly come a long way.

Before 1.0.0 was release I was a handful off hitting 2k users, but the addition of a new permission caused it to drop to %30 of what it was. This usually happens in these cases as Chrome automatically disables any extensions requesting additional permissions and asks the user to re-enable them in quite a scary fashion.

To your question: I would love to be able to make this variable available but, unfortunately, the Context Menu API provided by Chrome doesn't allow it. Sadly, there's no way to uniquely identify the HTML element when a link is right-clicked. The only option would be to search the page's HTML for any links that match the URL (provided by the Context Menu API). However, this would be extremely unpredictable as the page may contain multiple links (with various contents) for the same URL.

It might seem worthwhile adding this anyway and just using the first match, but this would make the value completely unreliable.

I'll keep a close eye on the Context Menu API (see http://code.google.com/chrome/extensions/contextMenus.html) for any changes in future releases that may make this possible.

Please keep up the feedback as it's the only way Template can continue to grow. I'm almost out of ideas ;)

As mentioned in my reply, I will not be able to do anything for this for now as the information is just not easily available. I'm considering raising a feature request with Chromium to add this as it would clearly be extremely useful to extension developers.

@ghost ghost assigned neocotic Apr 17, 2012

@neocotic

This comment has been minimized.

Show comment
Hide comment
@neocotic

neocotic Apr 17, 2012

Member

I think I may have found a possible workaround for this limitation. If I add something like the following to the context listener;

rightClicked = null
window.oncontextmenu = (e) ->
  rightClicked = e.target unless e.target instanceof HTMLDocument

Now, whenever a Template is activated through the context menu that originated from a link, the contents of rightClicked will be included in the results for the additional data from the context menu (as text as well as HTML and/or markdown?). However, this won't be possible on protected pages and may point to a different element if the user then right-clicks again elsewhere.

This process may also make #95 possible as a reference to the last right-clicked input field should be available, which would allow a follow up request to change the value of this field to the rendered output.

It might be better if rightClicked was a list (of max. 10?) so that the code could search for the last link etc. Also, it might also be useful to store a copy of the list for each Template activated immediately. This would require Templates to have unique IDs that existed throughout the whole process and should help mitigate the chances of fetching the wrong element.

Member

neocotic commented Apr 17, 2012

I think I may have found a possible workaround for this limitation. If I add something like the following to the context listener;

rightClicked = null
window.oncontextmenu = (e) ->
  rightClicked = e.target unless e.target instanceof HTMLDocument

Now, whenever a Template is activated through the context menu that originated from a link, the contents of rightClicked will be included in the results for the additional data from the context menu (as text as well as HTML and/or markdown?). However, this won't be possible on protected pages and may point to a different element if the user then right-clicks again elsewhere.

This process may also make #95 possible as a reference to the last right-clicked input field should be available, which would allow a follow up request to change the value of this field to the rendered output.

It might be better if rightClicked was a list (of max. 10?) so that the code could search for the last link etc. Also, it might also be useful to store a copy of the list for each Template activated immediately. This would require Templates to have unique IDs that existed throughout the whole process and should help mitigate the chances of fetching the wrong element.

@neocotic

This comment has been minimized.

Show comment
Hide comment
@neocotic

neocotic Apr 18, 2012

Member

I think this is the best way of recording right-clicks.

rightClicked = {}
window.addEventListener 'contextmenu', (e) ->
  switch e.target.nodeName
    # Record link (for link text access)
    when 'A' then rightClicked.link = e.target
    # Record field (for auto-paste functionality)
    when 'INPUT', 'TEXTAREA' then rightClicked.field = e.target

I'll still need to work out how/when's best to send this data to the background page. I'm confident this is now possible though.

Member

neocotic commented Apr 18, 2012

I think this is the best way of recording right-clicks.

rightClicked = {}
window.addEventListener 'contextmenu', (e) ->
  switch e.target.nodeName
    # Record link (for link text access)
    when 'A' then rightClicked.link = e.target
    # Record field (for auto-paste functionality)
    when 'INPUT', 'TEXTAREA' then rightClicked.field = e.target

I'll still need to work out how/when's best to send this data to the background page. I'm confident this is now possible though.

neocotic added a commit that referenced this issue Apr 19, 2012

@neocotic

This comment has been minimized.

Show comment
Hide comment
@neocotic

neocotic Apr 20, 2012

Member

This is working great in development. I'll hopefully be including this in a release aimed at this weekend. I've added the following standard variables;

  • link
  • linkHTML
  • linkMarkdown

However, on reflection, these may appear confusing as they are not actually links so I'm considering changing these to something like linkContents* or just changing link to linkText.

Member

neocotic commented Apr 20, 2012

This is working great in development. I'll hopefully be including this in a release aimed at this weekend. I've added the following standard variables;

  • link
  • linkHTML
  • linkMarkdown

However, on reflection, these may appear confusing as they are not actually links so I'm considering changing these to something like linkContents* or just changing link to linkText.

neocotic added a commit that referenced this issue Apr 20, 2012

@neocotic

This comment has been minimized.

Show comment
Hide comment
@neocotic

neocotic Apr 20, 2012

Member

I've renamed link to linkText and I'm now happy enough to include this change in this weekend's update.

Member

neocotic commented Apr 20, 2012

I've renamed link to linkText and I'm now happy enough to include this change in this weekend's update.

@neocotic neocotic closed this Apr 20, 2012

@neocotic neocotic reopened this Apr 20, 2012

@neocotic neocotic closed this Apr 20, 2012

@neocotic neocotic added the accepted label Nov 15, 2017

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment