Develop Reference

How to get text boxes to except text added through JavaScript (Twitch TV chat)

So, I am trying to write a simple command chat bot for Twitch.tv chat, but I cannot seem to be able to get it to actually submit the text I add. Although I can add text and "click" the send button with JavaScript, it will not actually submit it.
For example, I can use http://www.twitch.tv/example to test it. Apparently it is not good practice on Stack Overflow to link to sites, but I do not know what else to do. I cannot recreate the problem in JS Fiddle because I do not know exactly what the problem is.
I can get these elements to seemingly work by using the Chrome console:
//finding the textbox
var textbox = document.getElementsByClassName("chat_text_input mousetrap ember-view ember-text-area")[0];
//then assign some text to it.
textbox.value = "Hello, World.";
This works fine and the text appears.
//to send it I should merely find a way to click the "send" button
var send = document.getElementsByClassName("button primary float-right send-chat-button")[0];
send.click();
Well, this does not really work. It only actually submits the text if I physically either type or use a character (like shift) inside the textbox, or physically click the button myself. So, from what I understand there is some sort of event that is triggered when I physically type and click. Unfortunately, I do not understand how to find/trigger this event through the console. This is what I want to do.
Preferably I would like to do this in pure JavaScript, but I believe it may be simpler in jQuery. If it absolutely has to be jQuery that's OK and I will just have to suck it up and learn.
As a side note, I was able to successfully use this (with the elements changed of course), for YouTube live streaming chat. However, several other websites' chat react similarly to Twitch. These include web skype.

I've spent the last few hours poking around Ember and Javascript to figure this out. I too was running into an issue where I had to either click into the chat area or the send button itself.
I thought I had a lead with a script made for Twitch Plays Pokemon which would send preset messages into the chat. It used Jquery to input the value into the textarea and click on the send button, but that no longer works as Twitch now uses Emberjs 2
I am not too familiar with the Ember framework, but it seems Twitch utilizes a Textarea component(in Ember terms), which associates some framework specific API to the Textarea HTML element.
Since the Twitch webapp is written with Ember, it would seem that using vanilla javascript to set the value of the textbox would not notify the property change to whatever observers are registered internally to Ember
The workaround would then be to change the value property via Ember internal methods. Luckily poking around the views associated on the Textarea DOM element gives access to the set method.
http://www.ember-doc.com/classes/Ember.TextArea.html#method_set
Ember.view.views worked pre-Ember 2 but was deprecated and now requires lookup
App.__container__.lookup('-view-registry:main')[document.querySelector(".chat_text_input").id].set("value","test");
document.querySelector(".chat-interface__submit").click();

Change element value on external website

I have such a problem - I want to change value of an element on some external website.
Namely: I have webcam http interface which is password protected and there is a page with motion detection checkbox and "Apply" button (form submit). I want to create simple program with some sort of delayed toggling of motion detection (so I can launch this program and have some time to leave the building before motion detection starts). So I want to change checkbox state and write this change to system. I tried something like this, but that doesn't work:
jQuery.get("http://admin:password#192.168.0.1:12345/motion-page.asp",
function(data){
$('input[name="checkbox1"]').prop('checked', false);
// and there "simulate" clicking on Apply button - submit the form -- don't know how ...
}
);
Can anybody help me with this, please?

I would backtrack from the page that shows when you submit the camera form. See if the form itself is submitting the "turn camera on" variable as GET or POST. If you already know this, then all you would have to do is access the same URL as the form from the camera (assuming it's HTTP accessible on a network like this) and submit that same set of variables.
If you don't want to open a browser to do this, you could write yourself a custom application that submits it for you, but either way you have to open something to make the submission, as a script has to wait [X] amount of time before making the request. The fastest way will be through a browser.
I am not sure you need jquery for this (I never use jquery hardly at all). What I would do on the scripting side, since merely accessing this script means you want to activate the timer most likely, would be to create a timer object in javascript, and then make a single function that either accesses the URL of the camera form submission with the GET string parameters (that's easiest if it's doable via GET, because you wont have to build a form), or, if it's POST, have the function build a form and submit the form via POST to the same URL.
Google how to create a timer in javascript, and google how to automatically submit a form. Doing the code for you would be a waste of my time if you can figure it out on your own. If not, come back and we'll see what we can do :)
Good luck.

Why not after hitting the submit button, or after checking the box, have javascript actually run a timer? Look into the timer functions in js or jquery if that's more your thing. Not sure if you need it written to disk or whatever... since you're not giving much info, but whatever data you're wanting recorded could be captured when the box is checked and can be submitted along with the form whenever the timer runs out.
Submitting a form in jquery is simple:
http://api.jquery.com/submit/
:)

Canonical Java EE way of checking for unsaved session data?

My app has a use case where there is a page where the user can edit data and press save or interrupt editing and make a search or click links. The framework is kind of odd and uses javascript to submit a form for every link that is clicked so we ended up with a mishmash of javascript and java hacks the facilitate the dialogs and checks for unsaved data which became messy and I had to ask about it:
How to exclude components from javascript onkeydown
https://stackoverflow.com/questions/12525020/why-does-this-code-create-a-loop
I either got dialogs that never ended, pressing "yes" to "You have unsaved data. Do you want to comtinue?" made a loop to another same dialog and when I tried to fix it nothing works.
Now the program works on the screen but the solution is messy and if there is another bug or we notice that my solution affect other component there will be trouble.
So I'm asking if you know a plain Java way to check for unsaved session data? What happens is a form is presented to the user and clicking a link when data has been edited should present a dialog thatwarns that data is unsaved. I think doing it without javascript is a better solution, can you comment and/or help me here?

No.
The user enters data in their browser; there is no way for the server to know this unless you submit it.

Confirm dialog box on unload/exit UNLESS the back button is pressed?

I have some simple code to display a confirm dialog box when the user tries to leave my form:
window.onbeforeunload = askConfirm;
function askConfirm(){
return "Your answers will be lost.";
}
But this is a multi-page form and they frequently press back to change some values on a previous page.
But when they do this dialog box still comes up.
Is there a way around this?

The answer I would suggest unfortunately doesn't actually answer your question but is a solution of a kind. The only possible solution here, imv, is to make sure that a user clicking the back button doesn't actually create an issue by storing the form answers from all pages. In the case of PHP I would store them in a session ($_SESSION). You have to recognise that users use the back button more than any other UI element within a browser. If your form truly has to be across a number of pages then you need to make sure the data they have entered is persistent across all these pages. I would actually provide a navigation for this within your own interface. Provide a clear sequential process visually and allow instant navigation through this process where possible.

I don't see a way to specifically detect whether the user pressed "back" or any other browser button. This is outside the site's scope.
Only one solution comes to mind: Show the confirmation dialog only when a global flag has been set to "true".
if (ask_when_exiting == true)
return "Your answers will be lost.";
You would have to set the variable to true? in the onclick event of every link that you want the confirmation to pop up for. You should be able to mass apply this event to every link on your page using JQuery or another JS framework (Seomthing like $$('a').each()....).
However, this will disable the confirmation for reloading the page, or any other event that is not triggered using a control on the page like typing in another URL or closing the browser, as well.

Is automatically assigning focus bad for accessibility?

If I have a form that is the main part of a page's content, will assigning focus to the first form field via JavaScript on page load have any negative effects on accessibility?

The short answer is no it doesn't make things inaccessible but it can make it confusing. The longer answer follows. Will your users know that there going to a page with a form, and does there need to be any descriptive text you should read before filling out the form? I'm a screen reader user and it can be annoying having focused put in random fields. It's clear why your focus winds up in the Google search box so that doesn't bother me. If my focus were automatically placed in the answer edit field every time I viewed a question on Stackoverflow I would be annoyed since I'd have to force my screen reader to navigate away from the form field and to the top of the page.

It might a bit, if we've got a keyboard user (either using a screen-reader, or just a habitual keyboard user) who's expecting to be navigating the links at the top of the page on first Tab press. For screen readers, you could also consider adding WAI-ARIA to add directions if users who don't expect to be dumped into the middle of a form.
If it's much more likely that the user's going to be wanting to type in the field straight away, then I think the autofocus is worth it. But for the reason above I wouldn't use it on every page with an input field.
If you do autofocus, make sure to do it right away, in a script as soon as possible following the input element, or in future using the HTML5 autofocus attribute. Don't do it as late as window.onload. It's annoying to have clicked the focus elsewhere only to have the document belatedly finish loading and steal the focus onto another element as you type.

A lot of sites will do this, google is a good example, the only issue is when you are typing something into the address bar, or into the search input in your browser, the action of focusing the form field tends to steal focus from where you are typing. It's a small nuisance.

will assigning focus to the first form field via JavaScript on page load have any negative effects on accessibility?
I can't think of any. In between fields might irritate whatever assistive software a user might be running, but the first field - hardly. I have no experience with braille and similar clients.
Seeing as even Google do it on their front page, I don't think it can be that big a deal either way.

Quoting MDN autofocus -> accessibility considerations (retrieved 9/28/2022):
Automatically focusing a form control can confuse visually-impaired people using screen-reading technology and people with cognitive impairments. When autofocus is assigned, screen-readers "teleport" their user to the form control without warning them beforehand.
Use careful consideration for accessibility when applying the autofocus attribute. Automatically focusing on a control can cause the page to scroll on load. The focus can also cause dynamic keyboards to display on some touch devices. While a screen reader will announce the label of the form control receiving focus, the screen reader will not announce anything before the label, and the sighted user on a small device will equally miss the context created by the preceding content.
To add some practical examples, at the time of writing, https://www.google.com autofocuses on the search box, while Wikipedia and Amazon don't. If typing into a search box is the sole purpose of the page and the risk of confusion is low, then it's worth considering autofocusing on it. Otherwise, probably skip autofocusing.

I wouldn't say so, fragments are an ingredient of HTTP and they set the focus of an *html page..

I wouldn't say so. A screenreader will probably not even notice this since it doesn't interpret the JavaScript on the page.
Another user which has a "normal" browser will get the advantage of having the cursor already at the right place which facilitates the navigation by using just the keyboard.