Develop Reference

Enable copy and paste for a site that doesn't allow it

First off, I want to say that I very little knowledge of coding so please bear with me. I'm trying to paste in a site that doesn't allow it. This is the link to the javascript that they used to block it, https://mychatdashboard.com/js/messages.js?v=1.3
A friend of mine is helping me with it and he suggested that I put this in the javascript console in the DevTools of Google Chrome,
handler = function(e){ e.stopImmediatePropagation(); return true; }
document.querySelector('#conversation-content .conversation-message-text').addEventListener('keyup', handler, true)
document.querySelector('#conversation-content .conversation-message-text').addEventListener('input', handler, true)
This does solve the problem but it creates another issue. It seems that it interferes with this section of the javascript that I have linked to,
* Function to update the messagebox. (Enable/disable send button,
* change the color class, update the counter)
* #return void
So what would happen is that when a message is typed in the textbook, there's a character counter at the top which shows how many characters are written. When 80 characters(I think it's 80) are typed, the send button will be enabled so that I can send the message. However, with the javascript code that my friend suggested that I used, it stops the counter from working altogether so the send button never gets highlighted.
Is there any way around this? Please let me know if further clarifications are needed since it's the first time I'm asking a question of this nature.

The JavaScript you're entering into the DevTools console is defining a function named handler and then adding it as an event handler for keyup and input events for a field on the page you're viewing (presumable the chat window textbox).
The way that the handler is defined and attached prevents other events from firing (such as those that enable the send button when you've typed enough characters).
For this sites (and I haven't been able to test it) instead of the code you've used you could try running this in the DevTools console (once the page is loaded):
restrictCopyPasteByKeyboard = function () { return true; };
This should redefine the function that's preventing you from using paste (I can't test it out because I can't access that site).

There are numerous way through one can copy contents from Right Click protected sites
By disabling browser JavaScript in browser
Using Proxy Sites
By Using the source code of the site
Disabling JavaScript in Browsers [Google Chrome]
In Chrome browser, you can quickly disable JavaScript by going to settings. See the screenshot for better explanation:
screenshot
Through Viewing Source Code
f you have to copy the specific text content and you can take care of HTML tags, you can use browser view source options. All the major browser give an option to source of the page, which you can access directly using the format below or by right click. Since, right click is out of question here, we will simply open chrome browser and type: view-source: before the post URl Like
view-source:Enable copy and paste for a site that doesn't allow it
Press ctrl+u
And find the paragraph or text you want to copy and then paste it into any text editor.

I'm sure there are many ways of restricting user's ability to copy/paste. In my experience, it's always been a JS function that you can overwrite.
Slight variations of the below have always worked for me:
document.getElementById("#ElementWithDisabledPaste").onpaste = null

jQuery $.post() inside w2ui .reload() makes TEXTAREA silently lose focus in Chrome

Note: this question is probably too specialized. The solution (if I ever find one) is unlikely to help anyone but myself. Nonetheless, I believe the workaround described below to apply to several borderline Chrome/jQuery focus loss scenarios.
Scenario:
I have an input TEXTAREA to enter some text.
Meanwhile, a timer makes periodical AJAX calls to the server (one per minute).
What happens:
In Firefox, everything is hunky dory and the user can type away to his heart's content.
On Chrome, when the AJAX request fires, the input focus is lost. It goes... nowhere, apparently. window.activeElement returns nothing, and the cursor indeed disappears from the textarea, until the user clicks it again with the mouse.
What I expected:
Well, for the focus to stay there.
Attempts:
One - I have tried setting an event handler on the textarea's [.focusout()][1], only to discover that the event does not fire. It does fire when the user clicks somewhere else, but that doesn't help.
Two - I have then tried a less elegant - say rather, brutal - approach:
var hasFocus = document.activeElement;
if (hasFocus) {
var focusKeeper = window.setInterval(function(){
hasFocus.focus(); // JUST. STAY. THERE.
$(hasFocus).css("background-color", "red");
}, 10);
}
The field goes red, so the handler is firing at least. Except that the focus does not come back. It's just as if Chrome isn't even trying.
Again, everything works as expected in Firefox. I'll try next on Safari to confirm whether this is a Webkit-related thing.
Research and more attempts:
I've found several posts on how to overcome focus loss, or how to set the focus in the first place, even on newly created fields (which mine isn't), but my case seems different enough that they either offered no clue, or just plain didn't work. The documentation states that
element.focus();
is necessary and sufficient, yet sufficient quite clearly it is not. Someone has suggested setting focus using a zero-delay timeout; I tried, but this did not seem to help.
Could this be related to the fact that Chrome maybe runs XHR requests in a different process, so that the "focus" is going to the hidden XHR window? (Haven't tried with the --process-per-site commandline switch, it just occurred to me - I will now give it a try).
Could this be a bug? There was something like it, but bug 27868 was related to Flash objects, not TEXTAREAs - that's a completely different animal AFAIK.
The strange thing is that this behaviour (or one amazingly similar) was noted on Firefox and the bug reporter says explicitly, focus should remain on the same input control like in other browsers, so he did not observe it on Chrome.
JSFiddle - not exhibiting the behaviour, thus supplying a clue
I made a fiddle, and... it works. So the issue seems to be more with the function called in the timer, which is a w2ui grid.reload(). I still do not understand why the focus doesn't come back using focus(), as it should.
Acceptable workaround
Inspired by amphetamachine's comment, I've tried combining several of the tricks in the posts above. I've come up with a combination that works... sort of.
The elements needed (whichever I remove, the trick stops working) are:
re-set the focus manually where it was
do this inside a setInterval timer
blur the focus before re-setting it
unset and reset the focus inside a short, but not zero, setTimeout delay.
// Save focus.
hasFocus = document.activeElement;
w2ui.myGrid.reload(function() { // Callback, called after reloading.
// If there was no focus, we just return.
if (hasFocus) {
// We DON'T do anything directly, but use setTimeout.
window.setTimeout(
function() {
// And before setting the focus, we truly remove it.
hasFocus.blur();
hasFocus.focus();
}, 5); // A timeout of 0 does not work.
}
});
The "con" of this solution is that the cursor visually "shivers", and any key that was pressed during the second part of the grid.reload(), after the unknown event that loses the Chrome focus, will of course get lost.

Obsolete: just update the libraries.
The strange behaviour disappeared by upgrading w2ui to 1.4.2 on the latest Chrome (actually, I did not try on previous Chromes because I didn't think to keep copies of the previous versions).

dojo onkeyup disabled after pressing tab on IE8

I have a problem with events on IE8 (dread!), using dojo toolkit 1.4.3 (can't use any other version) on a Spring application running on Websphere Portal Server.
Now, I don't believe the backend has anything to do with this, since the problem with IE8 tabbing is known:
press on any field of a webpage and press tab all the way, the focus goes back up to the url input and buttons and doesn't return to the document after repeating it, if you click on an element in a website it re-adds the focus to that element, but when you press tab again it goes back to the top of the browser.
Now, my problem happens AFTER tabbing all the way and getting the focus out of the document.
It would seem the browser is removing events from the DOM, I have debugged the code on IE8 and it seems to not trigger the callback function, while it behaves normally when not doing the whole tab thing.
I've tried using dojo.disconnect() and re-adding the events by subsequently calling dojo.connect() to no avail, here's a small snippet:
var connectedObjects = {};
dojo.query(".someClass").forEach(function(inputField){
connectedObjects[inputField.id] = {};
connectedObjects[inputField.id].onfocus = dojo.connect(inputField, "onfocus", function(event){
if(connectedObjects[inputField.id]){
dojo.disconnect(connectedObjects[inputField.id].onkeyup);
connectedObjects[inputField.id].onkeyup = dojo.connect(inputField, "onkeyup", someCallbackFunction);
}
})
});
Does anyone have any ideas on how to solve this?

so, this is a weird one, but there is a simple way to fix the problem, this also seems to fix other browsers from cycling through hidden input fields that have the css property display:none, so on to the code:
dojo.query("*").forEach(function(fieldID){
dojo.attr(fieldID, "tabIndex", "-1");
});

Form event incompatibilities between browsers, how to address?

I have a textarea on a html page, on google chrome, well I don't know what version because the user interface is deviously hidden, but on chrome the onChange="code" event isn't firing but on Firefox 11.0 1.0 (according to help->about) it is firing. Then instead I start playing around with the events onkeydown="same_function()", onpaste="same_function()" and oninput="same_function()", in order to be absolutely sure to capture at least one event. But now the problem is that I'm getting too many events, and when I check the textarea_dom_object.value of the textarea after getting a keydown event the key that was pressed isn't included in the value that I'm reading; if I have "abc" in the textfield and I press 'd', that generates a keypressed, but I'm still getting only "abc", not "abcd".
Is there a compatible way, or at least a way that works on most browsers, to get an event every time a textarea changes, but preferably only one event? I don't like the kind of ugly code I would have to write if I had to first test if I've already listened to an event and so forth. All I want is one event each time the text in the textarea changes.

Here's the thing about why jQuery is so amazing. It understands the need to gracefully degrade the code between browsers that don't support newer functionality. JavaScript in and of itself does not offer this support stand alone. By enhancing JavaScript's core capabilities in using jQuery, you are generally going to be more successful with cross browser support.
That being said...
There are still plenty of scenarios where you need to identify what device/browser you're working with so that you can perform the expected operations.
The most important thing to remember is that there is no 100% cross-support library in existence.

you can do this. just make sure you give the textarea an id tag
$(document).ready(function(){
$('.addtitle').keyup(function(event) {
if(event.keyCode==13) {
}
});
});
in my case here, im firing the function on the enter key (like facebooks functions).
EDIT: also if you have more then one textarea on a page, you should do this:
$(document).ready(function(){
$('textarea[name=mynamevalue]').keyup(function(event) {
if(event.keyCode==13) {
}
});
});

Javascript Events: Getting notified of changes in an <input> control value

I have the following problem:
I have an HTML textbox (<input type="text">) whose contents are modified by a script I cannot touch (it is my page, but i'm using external components).
I want to be notified in my script every time the value of that textbox changes, so I can react to it.
I've tried this:
txtStartDate.observe('change', function() { alert('change' + txtStartDate.value) });
which (predictably) doesn't work. It only gets executed if I myself change the textbox value with the keyboard and then move the focus elsewhere, but it doesn't get executed if the script changes the value.
Is there another event I can listen to, that i'm not aware of?
I'm using the Prototype library, and in case it's relevant, the external component modifying the textbox value is Basic Date Picker (www.basicdatepicker.com)

As you've implied, change (and other events) only fire when the user takes some action. A script modifying things won't fire any events. Your only solution is to find some hook into the control that you can hook up to your listener.
Here is how I would do it:
basicDatePicker.selectDate = basicDatePicker.selectDate.wrap(function(orig,year,month,day,hide) {
myListener(year,month,day);
return orig(year,month,day,hide);
});
That's based on a cursory look with Firebug (I'm not familiar with the component). If there are other ways of selecting a date, then you'll need to wrap those methods as well.

addEventListener("DOMControlValueChanged" will fire when a control's value changes, even if it's by a script.
addEventListener("input" is a direct-user-initiated filtered version of DOMControlValueChanged.
Unfortunately, DOMControlValueChanged is only supported by Opera currently and input event support is broken in webkit. The input event also has various bugs in Firefox and Opera.
This stuff will probably be cleared up in HTML5 pretty soon, fwiw.
Update:
As of 9/8/2012, DOMControlValueChanged support has been dropped from Opera (because it was removed from HTML5) and 'input' event support is much better in browsers (including less bugs) now.

IE has an onpropertychange event which could be used for this purpose.
For real web browsers (;)), there's a DOMAttrModified mutation event, but in a couple of minutes worth of experimentation in Firefox, I haven't been able to get it to fire on a text input when the value is changed programatically (or by regular keyboard input), yet it will fire if I change the input's name programatically. Curiouser and curiouser...
If you can't get that working reliably, you could always just poll the input's value regularly:
var value = someInput.value;
setInterval(function()
{
if (someInput.value != value)
{
alert("Changed from " + value + " to " + someInput.value);
value = someInput.value;
}
}, 250);

Depending on how the external javascript was written, you could always re-write the relevant parts of the external script in your script and have it overwrite the external definition so that the change event is triggered.
I've had to do that before with scripts that were out of my control.
You just need to find the external function, copy it in its entirety as a new function with the same name, and re-write the script to do what you want it to.
Of course if the script was written correctly using closures, you won't be able to change it too easily...

Aside from getting around the problem like how noah explained, you could also just create a timer that checks the value every few hundred milliseconds.

I had to modify the YUI datable paginator control once in the manner advised by Dan. It's brute force, but it worked in solving my problem. That is, locate the method writing to the field, copy its code and add a statement firing the change event and in your code just handle that change event. You just have to override the original function with that new version of it. Polling, while working fine seems to me a much more resource consuming solution.