Reading the clipboard with every keystroke
-
@Tsaukpaetra said in Reading the clipboard with every keystroke:
For those who want to skip a pointless bicker, click here
This is TDWTF. Pointless bickering is our purpose. Or our .
-
@abarker Except you cannot alter what's pasted. Look, I went through this all five years ago. I might look at this later but I'd really rather invest the time in projects in a non-crippled environment like the Windows desktop.
-
@Zenith said in Reading the clipboard with every keystroke:
in a non-crippled environment like the Windows desktop.
...
-
@Zenith said in Reading the clipboard with every keystroke:
@abarker Except you cannot alter what's pasted.
In a simple way, that's what the example does. It takes the incoming data, modifies and inserts it into the target field, then aborts the default handler. Tada!
-
@loopback0 said in Reading the clipboard with every keystroke:
@Zenith said in Reading the clipboard with every keystroke:
in a non-crippled environment like the Windows desktop.
...
Compared to the browser, the desktop is a God-damned superman.
@abarker said in Reading the clipboard with every keystroke:
@Zenith said in Reading the clipboard with every keystroke:
@abarker Except you cannot alter what's pasted.
In a simple way, that's what the example does. It takes the incoming data, modifies and inserts it into the target field, then aborts the default handler. Tada!
...
- JSfiddle doesn't work in IE. Off to a great start.
- Pasting into the provided DIV ()...for some reason highlights the pasted text.
- I added a textbox. Because we're talking about pasting to a textbox. And...it doesn't work.
This is why I said I this:
@Zenith said in Reading the clipboard with every keystroke:
But to prevent pasting characters, I had to read the clipboard, set a modified copy, let the paste event happen, and restore the original contents.
Paste on a textbox pastes what's in the clipboard. At a glance, that's the same way WM_PASTE works. Except nobody pitches a fit if a desktop app touches the clipboard.
Edit: Because this is what both of them should do if they'd been thought out:
function OnPaste (Arguments) { Arguments.TextFromClipboard = Arguments.TextFromClipboard.ToUpper(); base.OnPaste(Arguments); }
-
@hungrier said in Reading the clipboard with every keystroke:
@Zenith That's just it, I only want the website to get a single piece of data that I choose to input, at the moment I paste it. Nothing else before or after.
@Zenith said in Reading the clipboard with every keystroke:
@hungrier Then we may be on the same page here? I just wanted to intercept what's been pasted after the click/keypress but before it lands in the textbox.
You may be on the same page with what you want, but I don’t see any real way in which allowing the second doesn’t also allow the site to get around the first. I mean, if you can intercept the data about to be pasted by the user, you will also be able to get it at any other time. Unless there is something like an onBeforePaste event and that’s the only time reading the clipboard is allowed.
-
@Zenith said in Reading the clipboard with every keystroke:
I really don't see what you're guarding against by making it difficult to see what's being pasted until after it's been pasted
The browser should only be able to see what's in the clipboard when you ask to paste into the browser. I think you agree with this actually since you said "I get that you don't want a site just randomly calling GetClipboard() and, arguably, might not want it calling SetClipboard()".
That means it shouldn't be able to read from it with every keystroke as per the OP.
-
@Gurth said in Reading the clipboard with every keystroke:
I mean, if you can intercept the data about to be pasted by the user, you will also be able to get it at any other time.
Not at all, no. The obvious way how this should work (as illustrated in @Zenith's example) is:
User pressing CTRL-V triggers a "OnPaste" event, with the current clipboard content included in the event data. Default event handler for a text input inserts the data into the text input. Custom code can override the event handler to do something else instead, or call the default handler with a modified version of that data. At no time is the page allowed to look at the clipboard itself, only ever at the data included in the OnPaste events it gets.
-
@Zenith said in Reading the clipboard with every keystroke:
@Tsaukpaetra It's just amazing how much is so trivial in WinForms and so stupidly difficult/half-baked in a browser. How the hell did the browser end up being the only platform anybody develops anything for?
Java's UI components looked clunky, and the installed copy of Java was always out of date. Meanwhile, you could use pretty pictures to compose an HTML document. And just sprinkle a little bit of kinda-working JS on top, thus making it look like it worked when management was looking.
That's why.
-
@Zenith said in Reading the clipboard with every keystroke:
I added a textbox. Because we're talking about pasting to a textbox. And...it doesn't work.
I added one (a textarea, to be specific) and it worked just fine.
input
doesn't work directly with the exact same event handler, but it shouldn't be too hard to modify the insertion code so it does
-
@ixvedeusi said in Reading the clipboard with every keystroke:
with the current clipboard content included in the event data
Which form? Text, Unicode Text, RTF, HTML, image (I forget how many standard images there are), files, metafile? Or how about all the custom types an app may put up?
-
@hungrier said in Reading the clipboard with every keystroke:
and it worked just fine
Were you using the blessed browser, IE6?
-
@Zenith said in Reading the clipboard with every keystroke:
@abarker said in Reading the clipboard with every keystroke:
@Zenith said in Reading the clipboard with every keystroke:
@abarker Except you cannot alter what's pasted.
In a simple way, that's what the example does. It takes the incoming data, modifies and inserts it into the target field, then aborts the default handler. Tada!
...
- JSfiddle doesn't work in IE. Off to a great start.
Not surprised. IE is a dinosaur, as far as browsers go. Honestly, everyone should stop worrying about IE11 support on web projects. Unfortunately, that probably won't happen until well after it has reached the end of its extended support life cycle.
- Pasting into the provided DIV ()...for some reason highlights the pasted text.
The div is a bit more flexible than a textarea as it allows you to also paste HTML if you need some formatting. As for the highlighting bit, that's easy; just add this after the
insertNode
:selection.setPosition(selection.getRangeAt(0).endContainer, selection.getRangeAt(0).endOffset)
- I added a textbox. Because we're talking about pasting to a textbox. And...it doesn't work.
Strange, I got it to work in about 5 minutes, though I did have to tweak the fix for the cursor position. Try this fiddle for to see it working:
https://jsfiddle.net/szm1e59L/3/
This is why I said I this:
@Zenith said in Reading the clipboard with every keystroke:
But to prevent pasting characters, I had to read the clipboard, set a modified copy, let the paste event happen, and restore the original contents.
It's not necessary to modify the clipboard, but you do you.
-
@dcon said in Reading the clipboard with every keystroke:
@ixvedeusi said in Reading the clipboard with every keystroke:
with the current clipboard content included in the event data
Which form? Text, Unicode Text, RTF, HTML, image (I forget how many standard images there are), files, metafile? Or how about all the custom types an app may put up?
Based on my testing, the clipboard events include everything that's currently on the clipboard. You just need to know the correct type to retrieve it.
-
@abarker said in Reading the clipboard with every keystroke:
Not surprised. IE is a dinosaur, as far as browsers go. Honestly, everyone should stop worrying about IE11 support on web projects. Unfortunately, that probably won't happen until well after it has reached the end of its extended support life cycle.
And, again, I said my use case was over five years ago. In a Microsoft shop. Where do people work that any dev saying "lol i cant do anything but google and javascript so we r a chrome shop now" can part the sea?
- Pasting into the provided DIV ()...for some reason highlights the pasted text.
The div is a bit more flexible than a textarea as it allows you to also paste HTML if you need some formatting. As for the highlighting bit, that's easy; just add this after the
insertNode
:Why not toss every single control in the toolbox and make everything a DIV? It's so simple!
selection.setPosition(selection.getRangeAt(0).endContainer, selection.getRangeAt(0).endOffset)
- I added a textbox. Because we're talking about pasting to a textbox. And...it doesn't work.
Strange, I got it to work in about 5 minutes, though I did have to tweak the fix for the cursor position. Try this fiddle for to see it working:
With a textarea. Not sure why everybody sees "textbox" and thinks "textarea." The only way the confusion makes sense is if you only do web dev and don't know that every desktop form builder defaults to MultiLine=false for textboxes.
This is why I said I this:
@Zenith said in Reading the clipboard with every keystroke:
But to prevent pasting characters, I had to read the clipboard, set a modified copy, let the paste event happen, and restore the original contents.
It's not necessary to modify the clipboard, but you do you.
Yes, if I'm willing to completely replace every part of the paste event with script, right down to fucking with the cursor position. Why don't I just make my own context menu too? Oh but then it'll be the evil of Flash and ActiveX and Silverlight all over again because the designed-by-committee DOM's crippledickery is good enough.
-
@ixvedeusi That’s pretty much what I envisioned, except I called it onBeforePaste :) But is it implemented like that in browsers? Let alone in every browser?
And let’s not forget that this thread began about regular phone apps, not web pages or similar, where an app can normally get the contents of the clipboard any time it likes anyway. Which is why iOS 14 betas keep popping up that warning, apparently.
-
@abarker said in Reading the clipboard with every keystroke:
@dcon said in Reading the clipboard with every keystroke:
@ixvedeusi said in Reading the clipboard with every keystroke:
with the current clipboard content included in the event data
Which form? Text, Unicode Text, RTF, HTML, image (I forget how many standard images there are), files, metafile? Or how about all the custom types an app may put up?
Based on my testing, the clipboard events include everything that's currently on the clipboard. You just need to know the correct type to retrieve it.
Yes, but in the @ixvedeusi's post, I forgot to include another part:
At no time is the page allowed to look at the clipboard itself
As long as you're allowed to look at the clipboard, than things are good. If you can't, then all forms of data have to be passed and that's not so good.
-
@Tsaukpaetra said in Reading the clipboard with every keystroke:
@hungrier said in Reading the clipboard with every keystroke:
and it worked just fine
Were you using the blessed browser, IE6?
No, because supposedly jsfiddle doesn't work in it
-
@Zenith said in Reading the clipboard with every keystroke:
With a textarea. Not sure why everybody sees "textbox" and thinks "textarea." The only way the confusion makes sense is if you only do web dev and don't know that every desktop form builder defaults to MultiLine=false for textboxes.
After my previous post I had modified the handler to also work with an
<input type="text">
. Using .selectionStart, .selectionEnd and .value works just fine for those
-
@Zenith said in Reading the clipboard with every keystroke:
@abarker said in Reading the clipboard with every keystroke:
Not surprised. IE is a dinosaur, as far as browsers go. Honestly, everyone should stop worrying about IE11 support on web projects. Unfortunately, that probably won't happen until well after it has reached the end of its extended support life cycle.
And, again, I said my use case was over five years ago. In a Microsoft shop. Where do people work that any dev saying "lol i cant do anything but google and javascript so we r a chrome shop now" can part the sea?
- Pasting into the provided DIV ()...for some reason highlights the pasted text.
The div is a bit more flexible than a textarea as it allows you to also paste HTML if you need some formatting. As for the highlighting bit, that's easy; just add this after the
insertNode
:Why not toss every single control in the toolbox and make everything a DIV? It's so simple!
That does seem to be the way web development is going.
selection.setPosition(selection.getRangeAt(0).endContainer, selection.getRangeAt(0).endOffset)
- I added a textbox. Because we're talking about pasting to a textbox. And...it doesn't work.
Strange, I got it to work in about 5 minutes, though I did have to tweak the fix for the cursor position. Try this fiddle for to see it working:
With a textarea. Not sure why everybody sees "textbox" and thinks "textarea." The only way the confusion makes sense is if you only do web dev and don't know that every desktop form builder defaults to MultiLine=false for textboxes.
Well, a textbox element doesn't exist, and the closest match when doing a mental search is
textarea
. After further consideration, I suppose you mean aninput
withtype=text
. Still, switching to fromtextarea
toinput
is trivial, so here you go: https://jsfiddle.net/4f6oe3kw/This is why I said I this:
@Zenith said in Reading the clipboard with every keystroke:
But to prevent pasting characters, I had to read the clipboard, set a modified copy, let the paste event happen, and restore the original contents.
It's not necessary to modify the clipboard, but you do you.
Yes, if I'm willing to completely replace every part of the paste event with script, right down to fucking with the cursor position.
If your goal is to be able to modify what's being pasted, then yes, you will have to do a little extra legwork. But constantly watching the content of the text field is .
Why don't I just make my own context menu too?
If you need to, go for it. There are times when a context menu is appropriate from a UX standpoint - just like in a desktop app. When you need it in a desktop app, you have to do most of the work for making a context menu, too. Why should it be any different for a web app?
Oh but then it'll be the evil of Flash and ActiveX and Silverlight all over again because the designed-by-committee DOM's crippledickery is good enough.
-
@abarker said in Reading the clipboard with every keystroke:
@Zenith said in Reading the clipboard with every keystroke:
Oh but then it'll be the evil of Flash and ActiveX and Silverlight all over again because the designed-by-committee DOM's crippledickery is good enough.
There were two sides of that fight. One side said "damn, I'm tired of this primitive platform not being able to do this and this and this and this...fuck this, I'll write a plugin to do that stuff" and the other side said "b-b-but security!1one." The wrong side won in my opinion. The last decade has been Sisyphus pushing a boulder up a hill because the people that fuck up layout every year without a care in the world about backward compatibility refuse to fix basic shortcomings with backward compatibility as their excuse.
Alright, I've had enough. I don't give two shits about hand wringing over the scawy qwipboawd.
-
@Zenith said in Reading the clipboard with every keystroke:
One side said "damn, I'm tired of this primitive platform not being able to do this and this and this and this...fuck this, I'll write a plugin to do that stuff" and the other side said "b-b-but security!1one." The wrong side won in my opinion.
To clarify that I'm not misreading you:
The "security side" has won and you think that's the wrong one?
-
@Zenith said in Reading the clipboard with every keystroke:
With a textarea. Not sure why everybody sees "textbox" and thinks "textarea." The only way the confusion makes sense is if you only do web dev and don't know that every desktop form builder defaults to MultiLine=false for textboxes.
I'm a WPF def. I have single-line textboxes, and I have multi-line textboxes. It's a matter of flipping one bit in control's properties. They're both textboxes to me. If I moved to web, I'd still call them textboxes. And I'd still consider the difference to be in flipping one bit in its properties. If that bit in textbox properties is flipped by changing tag name, so be it.
-
@Gąska said in Reading the clipboard with every keystroke:
They're both textboxes to me. If I moved to web, I'd still call them textboxes. And I'd still consider the difference to be in flipping one bit in its properties.
Oh boy are you in for a surprise...
-
@Gąska said in Reading the clipboard with every keystroke:
If that bit in textbox properties is flipped by changing tag name, so be it.
-
@topspin said in Reading the clipboard with every keystroke:
@Zenith said in Reading the clipboard with every keystroke:
One side said "damn, I'm tired of this primitive platform not being able to do this and this and this and this...fuck this, I'll write a plugin to do that stuff" and the other side said "b-b-but security!1one." The wrong side won in my opinion.
To clarify that I'm not misreading you:
The "security side" has won and you think that's the wrong one?No, "b-b-but security!1one" is different from actual security.
Think of it like this. Have you ever seen the press ask what a government entity is doing and a politician or spokesperson says "national security!" to shut them down? It's code for "stop asking questions that I don't want to answer." Everything can be a "security" problem if you don't want to do it. It just so happens that despite efforts to cripple or remove every useful feature, the browser/web is still full of security holes.
-
@Gąska said in Reading the clipboard with every keystroke:
@Gąska said in Reading the clipboard with every keystroke:
If that bit in textbox properties is flipped by changing tag name, so be it.
I understood what you meant, it's just that in my experience <input> and <textarea> behave very differently in most practical aspects, so thinking of them as "essentially the same thing" can lead to a lot of hurt.
-
@ixvedeusi said in Reading the clipboard with every keystroke:
@Gąska said in Reading the clipboard with every keystroke:
@Gąska said in Reading the clipboard with every keystroke:
If that bit in textbox properties is flipped by changing tag name, so be it.
I understood what you meant, it's just that in my experience <input> and <textarea> behave very differently in most practical aspects, so thinking of them as "essentially the same thing" can lead to a lot of hurt.
In my experience, a WPF textbox with multiline=false behaves significantly different from a WPF textbox with multiline=true, in ways that matter a lot and makes many things much harder than they ought to be - so it's not like it's a new thing.
-
@ixvedeusi The HTML committee makes some baffling decisions.
Let's make up dozens of tags that nobody uses like samp, dd, menu, nav, etc. But cram textboxes, checkmarks, radiomarks, files, images (), and buttons together under one. Except multi-line textboxes, they get their own.
-
@Zenith said in Reading the clipboard with every keystroke:
committee makes some baffling decisions
-
@Gąska said in Reading the clipboard with every keystroke:
committee makes
some bafflingdecisionsFixedthatforchu
-
@Gąska said in Reading the clipboard with every keystroke:
I'm a WPF def. I have single-line textboxes, and I have multi-line textboxes. It's a matter of flipping one bit in control's properties. They're both textboxes to me. If I moved to web, I'd still call them textboxes. And I'd still consider the difference to be in flipping one bit in its properties. If that bit in textbox properties is flipped by changing tag name, so be it.
They're apparently quire different in implementation, but that's HTML's fault, not yours
-
@Gąska said in Reading the clipboard with every keystroke:
In my experience, a WPF textbox with multiline=false behaves significantly different from a WPF textbox with multiline=true, in ways that matter a lot and makes many things much harder than they ought to be - so it's not like it's a new thing.
-
@Gąska What am I, some time traveler that can read ahead beyond the post I'm answering?
-
@hungrier I'm just lazy and take advantage of being able to post replies with mouse only whenever I can.
-
@Zenith said in Reading the clipboard with every keystroke:
@ixvedeusi The HTML committee makes some baffling decisions.
Let's make up dozens of tags that nobody uses like samp, dd, menu, nav, etc.
To be fair, some of those were inherited from the original HTML.
DT
andDD
are already in the 3 November 1992 version, for example.But cram textboxes, checkmarks, radiomarks, files, images (), and buttons together under one. Except multi-line textboxes, they get their own.
I never understood that part, no. However, a little dumpster-diving at w3.org turned up the HTML+ specs from just over a year later than the previous (this is not HTML 2, that would take a few more years to come out). This includes an
INPUT
tag with aTYPE
attribute that has a bunch of possible values to determine what goes into the field — some that weren’t actually adopted (SCRIBBLE
orAUDIO
, anyone?), others we still have today. It’s still puzzling why they didn’t just go for<CHECKBOX VALUE=CHECKED>
or something similar, though.
-
@Zenith said in Reading the clipboard with every keystroke:
@ixvedeusi The HTML committee makes some baffling decisions.
Let's make up dozens of tags that nobody uses like samp, dd, menu, nav, etc. But cram textboxes, checkmarks, radiomarks, files, images (), and buttons together under one. Except multi-line textboxes, they get their own.
Dropdowns get their own tag as well. And buttons can be created both with the input tag or with a separate button tag - I'm not sure whether there's a difference.
-
@PleegWat You forgot your :) Oh, and technically selectbox and listbox share a tag so let me just take that back.
The difference between buttons? I want to say it's that the INPUT gets submitted with the form but verifying that would be . Reminds me of stupid stuff that ASP.NET webforms did...
-
@PleegWat said in Reading the clipboard with every keystroke:
And buttons can be created both with the input tag or with a separate button tag - I'm not sure whether there's a difference.
IIRC one of them is deprecated, but can't remember which.
-
@Zenith said in Reading the clipboard with every keystroke:
I want to say it's that the INPUT gets submitted with the form but verifying that would be
I'm pretty sure only the button you clicked is 'valid' (HTML speak for getting submitted), regardless of the tag used to define it. The value getting submitted might be different - I'm pretty sure
<input type="button">
always submits the button label as the value.I also remember that being annoying with checkboxes - only the checked ones are submitted.
-
-
@Gąska Drop-down list box. A combo box is a combination of a text box and a possibly-drop-down list box. (Source) Alternatively, it's the combination of a text field and pull-down button. (Source)
-
Which one do I use to create "drop-down list box"?
-
@Gąska A
ComboBox
with aDropDownStyle
ofComboBoxStyle.DropDownList
. For Visual Basic 2 compatibility. *siiiiigh*
-
@TwelveBaud except it's not WinForms toolbox, it's WPF toolbox. There's no ComboBoxStyle and it always behaves like a drop down list. I guess everyone only ever used combo boxes with drop down lists and MS finally figured they'd stop pretending. And editable textbox has never been a required feature of a combo box in any GUI library. Hell, most combo boxes allow replacing the textbox - as well as the drop-down listbox - with another control.
And whether it's pedantically correct or not to call it a combo box - you're certainly going to have more luck communicating with other devs by calling it a combo box rather than a select box. Like it or not, it went the way of the tray icon.
-
@Gąska notification area icon. (Source, History)
I never was one to stop digging my own grave, even as other people point out the lovely headstone...
@Gąska said in Reading the clipboard with every keystroke:
And editable textbox has never been a required feature of a combo box in any GUI library.
-
@TwelveBaud said in Reading the clipboard with every keystroke:
@Gąska notification area icon.
That war has been lost before I was born. #sorrynotsorry
@Gąska said in Reading the clipboard with every keystroke:
And editable textbox has never been a required feature of a combo box in any GUI library.
I love when people don't even read their own links.
In the “readonly” state, the value may not be edited directly, and the user can only selection of the values from the dropdown list.
-
@Gąska ... you're right. I apologize.
-
@Gąska said in Reading the clipboard with every keystroke:
@Zenith said in Reading the clipboard with every keystroke:
selectbox
Combo box.
I don't care what the argument between these posts said. It's not a combobox without the editable textbox. HTML doesn't have it and, what's more, uses a SELECT tag. Thus it's a selectbox.
-
@Zenith said in Reading the clipboard with every keystroke:
It's not a combobox without the editable textbox.
Well, it's been called that since I started working on windows with v3.1... You create a
COMBOBOX
with theCBS_DROPDOWNLIST
style. So I'd say it predates html a bit...