That would be better.
I discovered your great addon and I’m succesfully using it. I have a request.
I need to copy a web link between other text not as text but as link.
Let me explain the scenario.
This a web page where I need to copy sections of displayed text.
In first selection there a link and I prefer to copy it as text when I click Shift+Ctrl+F8
but in another section, there is a link that I wish to copy as link.
Right now, when I click Shift+Ctrl+F8, copied text is “VH Series Datasheet” but I wish “http://www.jst-mfg.com/product/pdf/eng/eVH.pdf”. Since this not last selection that I do, I cannot use “Text MultiCopy” and then “Foxilink” because that link must be inside other copied text. I hope that is it clear. So my request:
Is it possible to have an option that when enabled, using another shortcut ( Shift+Ctrl+F9 ??), “Text MultyCopy” could copy link as link and not as text?
Thanks and best regards.
I have to see if that can be done (it is not straight forward).
I will work on it for the next update.
Thanks so much, Erosman!
Just tried this add-on and it doesn’t work. In the latest Waterfox version (56.1.0 x64) on Win10x64, testing it on a Google search page, it would always result in the previous items that were saved to the clipboard actually being in the clipboard. For example:
Copy text A to clipboard
Select text B
Select text C
Copy Saved to Clipboard
Pasting results in text A being output from clipboard
Select text D
Select text E
Copy Saved to Clipboard
Pasting results in text B +C being output from clipboard
And so on.
I have just tested it the same way that you listed on Google search result page with Firefox 61.0a1 & Text MultiCopy 2.5 and it worked fine.
Does it only happen on Google search page?
Have you tried the same with another browser?
I dont use Waterfox so I am not aware if there are any issues specific to Waterfox.
Finally, Text MultiCopy is due for an update, as soon as I get to it. There were a couple of feature requests. Let me know more about this issue and I try to fix it.
The problem occurs on multiple sites, and in Firefox as well. The issue lies with the dom.event.clipboardevents.enabled setting which, if set to false (for privacy reasons), partially breaks the functionality of the add-on. If this setting is disabled, only the last saved selection is copied to the clipboard. Also, it is only saved if the text is still highlighted when copying saved data to the clipboard, otherwise the clipboard contents remain unchanged. So for it to work with the setting disabled, the text you want copied to the clipboard has to be highlighted, you have to save the selection, then, while the text is still selected, you have to copy the selection to the clipboard. This also means you can’t do multiple selections, so it defeats the whole purpose of the add-on. Ideally, the add-on should work with this setting disabled (assuming you can make it), otherwise, it should provide a warning, either through the addons.mozilla.org page, the add-on info page, and/or a warning the add-on provides if it sees the setting is disabled.
The cause of the delay I mentioned before appears to be that when the setting is enabled, the add-on tried to play catch-up, sequentially (AFAICT) going through the items saved and copied to clipboard while the setting was disabled. It goes essentially like this:
dom.event.clipboardevents.enabled = false
Save A & Copy saved to clipboard
Save B then C & Copy saved to clipboard (keeping C highlighted)
Save D then highlight E & Copy saved to clipboard (without saving E)
Paste E [whatever is highlighted is what gets copied to clipboard…]
Copy F (without saving it) then unhighlight it
Paste E […but only if something is saved, otherwise clipboard contents are untouched]
dom.event.clipboardevents.enabled = true
Save & Copy H
Save & Copy I
Paste B+C (note only C was copied to clipboard originally)
Save & Copy J
Paste D (note D was never copied to clipboard originally)
What’s interesting here (besides the obvious fact that the add-on is going back through all the stuff saved/copied while the setting was disabled) is that, despite the multi-copying (and copying without having text highlighted) being broken, all that stuff was in fact saved properly in the add-on’s “memory,” since it’s being copied to and pasted from the clipboard as it was originally intended. So the setting doesn’t seem to be totally breaking the add-on, more just messing with its behavior. I haven’t done extensive enough testing to see how many items it retains, but basically it seems that if you copy x times to the clipboard with it while the setting is disabled, once you enable it the add-on will also be x items behind in what it copies to the clipboard from that point on. So if you copy 10 times (whether some or all of them are single selections or multiple selections), then enable the Firefox setting, the first time you perform another copy with it, it will copy the first thing you copied with the setting disabled to the clipboard, so by the 11th time you copy something, you’ll finally get to the first item you copied since enabling the setting. The only way I’ve found to reset it to remove this lag is by disabling then re-enabling the add-on (though I’ve had this not work, which I suspect is because it wasn’t disabled for long enough; it seems to need to be disabled for several seconds). After that, as long as the Firefox setting remains enabled, the add-on works as expected.
So in summary:
- To fix the issue, which seems like it might be possible due to the fact all the saved/copied text is retained while the setting is disabled, the add-on needs to be changed so it copies all selected text to the clipboard, not whatever happens to be highlighted at the time the command is given, and it needs to not go back through those items if the setting happens to be enabled at any point.
- If it can’t be fixed, or you choose not to fix it, there needs to be a warning, since this is one of the more commonly adjusted privacy settings, so it’s not unreasonable to assume there will be others that will experience an issue due to it and waste time trying to figure it out.
Hopefully that’s all clear enough to make sense of and provides you with the necessary info to troubleshoot and, hopefully, fix it. It was a pain figuring it out and figuring out all the nuances of it, and I got interrupted halfway through, so hopefully I didn’t forget something.
Thank you for the detailed investigation.
Let’s start by clarifying how the extension works.
Save Selection: Add-on saves the selection (and appends to previously saved) to its own storage and repeats the process every time a new text is saved.
This function does not save to memory and it has nothing to do with Clipboard at all or
There is no limit on how many times you can save text to Text MultiCopy (except the built-in JSON limit of 5m which a a lot of text).
Copy Saved to clipboard: Add-on gets the previously saved data from its storage, pastes it to the clipboard and clears the storage.
Web Extension API does not have a dedicated Clipboard API. Add-ons have to use Web API by injecting a script to the current page and process the paste to clipboard from within that page. There is no other way.
Firefox limits injecting script into some pages like internal pages or AMO and some other 14 domains.
I have written a work-around for this limitation in my other add-ons and will add it to Text MultiCopy in the next upgrade.
As you have mentioned (I have not tested it), above setting may interfere with clipboard events from the page but that is not something that is expected to be set to false. If it does interfere then doing so will break any WE with clipboard functionality.
I will do some test to see how
dom.event.clipboardevents.enabled actually affects the add-on.
The lag should not relate to the function of the add-on as add-on will save data normally regardless on the
dom.event.clipboardevents.enabled which only comes into effect on pasting to clipboard.
Pasting in Texarea also should not be affected either way.
I’m fully aware of how it works regarding save selection vs copy saved to clipboard. The point is, while it may not be expected for the setting to be set to false, it should be accounted for. And while I can certainly understand your not recognizing this as an issue (you probably never thought of it, and I don’t blame you), it’s clear it is an issue that will affect anybody trying to protect their privacy by setting it to false. As I said, it would obviously be ideal if the add-on could be modified to still work properly even if this setting is disabled, but at the very least it should warn, and/or you should warn users in the add-on’s description, of the issue.
You say the lag shouldn’t relate to the function of the add-on, but it’s precisely the function of the add-on that’s presenting with said lag, so I’m not clear on what you’re actually trying to say there. Normal copy/paste works perfectly fine regardless of whether the setting is enabled or disabled, and the lag is only an issue with TMC. Lag may not be the best word to describe it, as that seems to suggest a slowness, when it’s actually an issue of the clipboard contents being offset, but I think I made it clear what I meant.
Also, to your comment that dom.event.clipboardevents.enabled only comes into effect on pasting to the clipboard, that’s not my understanding of it. From what I’ve read, it applies to even selecting text, as well as copying/cutting it, which is the point of disabling it for privacy. With it enabled, websites can see everything you select, copy, cut, and paste. If it only had an effect on pasting, that wouldn’t be the case.
It may be that the issue can’t be fixed, and that’s fine. If it’s a limitation of disabling that setting, and nothing can be done about it, or it would take more time and effort than you can (or are willing to) spend, then so be it. But at least now you know about the issue and what’s causing it.
Just let me know if you need me to test out any beta versions while you work on it.
Also, unless I’m missing something, you can use F8 to save text, but there’s no shortcut for copying saved text to the clipboard, which means the context menu has to be opened and the user has to navigate to the TMC entry, at which point I’m having a hard time seeing how using this is much more efficient, than any, vs just copy/pasting one thing at a time. I think the functionality of the add-on would be greatly improved by adding the ability to customize the shortcuts (F8 and especially Ctrl+Shift+F8 are not convenient or easy to use at all) and to enable a shortcut for copying the saved data to the clipboard. Then I could, for example, set Ctrl+Shift+1 to save the selected text and Ctrl+Shift+2 to copy saved text to the clipboard.
The Firefox Keyboard shortcut map is very congested. There are not many available ones left and they often clash with each other. In case of clash in WE, there is no order to see which add-on or browser function gets assigned the shortcut. There is a custom keyboard setting API planned and once that is done, I will add the features so users can assigned their won preferred keyboard shortcut.
The point of the add-on is to collect texts/references for the user. For example, a person collecting references for a thesis can copy 100s of sections over a period of time and over multiple sessions; and then collate and paste with one action.
Paste is always a once-in-many-operations action.
Hey there. Great extension. Here’s the use case–I have a Gift Card Number and a Gift Card PIN. I’d like to copy both of them, then paste them with a Tab in between, i.e. I’m pasting them into a spreadsheet. I’m not clear how/if its possible currently to set the Divider to . Any encodings would be fine. \008 or \t or whatever you like.
You can use Tab if you want but that would mean all entries will be end up in one row on a spreadsheet.
There is no option currently for creating a 2 column layout in a spreadsheet.
You should use semicolons then special paste with delimiters, and tell it to use semicolons as the delimiters. Let me know if you need help figuring it out.
I have been checking and WE at the moment doesn’t have any API to check the value of
dom.event.clipboardevents.enabled to see if it is enabled. Therefore, there is nothing that can be done about it at the moment.
Custom Keyboard Shortcuts are coming soon in v2.6 (FF60+).
I apologize for posting my suggestions and bug reports in the review section. I will edit my post and because of your responsiveness and receptivity, adjust my rating accordingly. Here are the suggestions and problems described in my original post.
- To be able to configure a keyboard combination to copy into the cache.
- To be able to optionally add the date and time when clipping.
- To be able to expand the number of allowed characters before and after the URL. This way, I can have a prefix of "Location: " or "Pasted from: "
A problem surfaced when I realized that large clips are being truncated. Is there a limit on the size of individual clips? Can this limit be removed?
Steps to reproduce:
Clip a few articles from the NYTimes.com website. Note that I capture both the page title and url when I clip.
Now try a long article from the magazine section. For this, I used this article.
Clip all of the text in the article.
Save the clips to the clipboard.
Paste them and compare the clips to the sources. I will bet that the magazine clip is truncated.
Note that I have tested this on a Windows 7 Professional machine with 8GB RAM and an i7 processor. Also Tested on a Windows 10 machine with 16GB RAM and a i5 processor. Both give me the same result.
I have also tested the magazine article using ctrl+c and copy plain text. Both methods paste the full article correctly. So I thought maybe the other clips were doing something that caused the magazine article to truncate. That assumption proved wrong. I copied the magazine article alone and saved it to the clipboard. The result was the same. It was truncated as before. Identically.
Does this information help?
New features coming to the next upgrade: (already done)
- Custom Keyboard Shortcut (FF60+)
- Option to add Date & Time
- Removed length limit on URL wrapper
Thank you. You are right, there is a truncation somewhere. Thank you for pointing it out.
Let me find out where the problem is and it will fix it.
Firefox is causing the limit/truncation, not the add-on. It seems there is a limit on the text length (16384) passed to the contextmenu API.
The order of saving doesn’t matter. It truncates even if there is only one article.
Let me see how I can overcome it.
I have updated the code to not use the contextMenu selectionText if text length is longer than 16,384.
It seems Firefox truncates the selectionText at 16,384 (16k).
I got a reply from the WE dev team and the limit is hard-coded into the WE API.
Thank you erosman. Do you have an ETA on when the next release will be?
All of them are done. I have to do some testing and will release it soon.
If anyone has any feature requests, let me know.