Since I'm creating a HTA code I'm stuck with IE :(
We needed to trap the change event in a <select> element, but guess what, IE does not support that event.
So I created a way to mimic it. With a <input type="text"> that when it is being click show the <select> just below. That part works fine. The problem is, I want to hide the select when the user click outside the select.
I tried to catch a click on the body, it works fine the first time but the second time the select gets hidden try away.
Here a simplify version of the code:
$('.product').live('click',function(){
// Show the <select id="select"> code goes here
// this is the event to close the select
$('body').die().live('click', function(){ $('#select').fadeOut(250); return;});
// get the click on the select element
$('#select').die().live('click',function(){
// kill the close the select
// THIS IS THE .die() THAT DOES NOT WORK
$('body').die();
});
Question
Is there something wrong with this code? OR is there a better way to do this? Remember I'm stuck with IE.
Internet Explorer 7 and up (and probably 6, since IE7 is mostly IE6 with lipstick, but I can't test that easily) do support the change event. Here is a jsfiddle with a really simple demo.
It's definitely true that IE does weird things with events. For example, "change" won't bubble (from <select> at least, and probably other things), but jQuery patches over that for you. Also there's the classic issue with checkboxes and radio buttons, which don't fire "change" until they lose focus (which makes it basically useless). For those, I find that "click" works fine.
In order for .die() to function correctly, the selector used with it must match exactly the selector initially used with .live().
Related
I have a site which has three radio inputs and based on which input is selected parts of the html page around it will change. Everything works perfect except in IE8(of course). My issue for this page is that when I click on the input which has an event listener of 'change' on it, nothing will happen, it is only until it is clicked the second time that the event will fire. I know that IE8 doesnt handle addEventListeners but I am using a pollyfill for all this and am using addEventListeners for tons of other things on the site and they work fine.
The second thing to note is that everything works fine in IE8 if I switch the event listener to a 'click' event. The only issue and reason why im not just switching it to 'click' is because of tabbing. I still what the user to still be able to tab through the form for a proper UX.
Lastly when I bring the site up in my VB for IE8, this functionality(even with the 'click' event) will not work until I put it in debugging mode and it finds all the polyfill.min.js errors. Then I can stop debugging and everything will then work as intended. I will provide a picture of my errors. I have no idea why and what is causing them. My guess would be some external script I am pull for third party functionality maybe. Cant figure that out yet.
here is how the function is being called,
Here is where the function is called:
function attachToggleReportType (elem) {
console.log('Trigger attachToggleReportType');
elem.addEventListener('change', toggleReportType, false);
}
And here is the main function for the actions to happen based on the event
function toggleReportType () {
console.log('Trigger toggleReportType');
var reportOptions = document.querySelectorAll('.report'),
reportIncToggle = document.querySelectorAll('.toggle');
console.log(this.getAttribute('data-sample-report-link'));
reportSample({
href: this.getAttribute('data-sample-report-link'),
src: this.getAttribute('data-sample-report-image'),
title: this.getAttribute('data-sample-report-title')
});
reportIncToggle.forEach(toggleInclude);
}
So I found a solution for my problem. It is not perfect but it worked fine for me, for now. It was a pretty odd issue because in IE8 my event listener with a type of 'change' would always have a click delay on it. So no matter which radio I would click, the only time the event would fire is when I clicked again anywhere on the screen the second time. I know IE8 doesnt handle addEventListeners but I was using a polyfill for accommodate this. I also would get a polyfill error when in debug mode, so I wonder if this is an issue related to that. Anyways, i resolved this issue for now by including a 'change' event listen for modern browsers, then in IE8 i switched it to an on 'focus' event and everything works perfectly still. I hate the idea of having two event types but it was the only way to resolve this bug. Also to note, the change event still worked in IE8 on the second click, so trying to detect if the browser could handle this event type wasn't an option for me.
So I have created a Firefox extension and it works great, however when I submitted it (although it was accepted) it came up with one security warning. It said setTimeout() was removed in an else clause.
So, is there a way to listen for any DOM change? (or even a specific element changing, I have an ID for both). However, divs do not have an onChange event so any ideas?
I don't mind if it's ANY change, doesn't have to be div-specific.
DOMSubtreeModified event sound like something you want to use. Keep in mind, that it is deprecated and after some time its support will probably be removed from browsers.
http://help.dottoro.com/ljrmcldi.php
It turns out adding an "onChange" event to a div works fine, although it might not be W3C valid it doesn't really matter as it's only a Firefox extension (plus it works!).
Scenario: I'm trying to intercept paste events inside a textarea/input text, and filter the content being pasted.
Webkit/IE are handled rather well, as I can attach code to the onpaste event, and then read from the clipboard what is being pasted. Plenty of examples around.
Gecko is trickier, because as far as I know it isn't possible to read the clipboard content on Firefox (unless somebody knows a workaround for that?)
I just use the input swap trick for that.
Opera is being annoying tho. I can trap CTRL+V and SHIFT+INS, but there's no onpaste event.
Not to mention any sort of clipboard interaction, apparently.
So, my question is:
Can I detect if the user clicked on paste in the context menu on Opera? Is there any other way to detect the event?
EDIT:
Thanks everybody for the answers - they all add a good input, even if there's no definitive solution.
Having to choose, I'll pick the only one that tried to address the original question, and that would probably work if it wasn't too much of an hack to even try.
Notes for those that have my same problem (input filtering):
it is possible to capture content being dragged: mouseup + setTimeout does the trick everywhere almost perfectly.
without flash, there is probably no solution bar polling. Even with flash, it's not a completely solid solution either. Too much effort to support 100% of the cases.
I ran into this last year. In short, no.
I ended up using an onchange handler and filtering the content after it's already been pasted into the text box.
You can intercept the paste with jQuery using the bind('paste', function() {});, compare string before and after pasting and apply your formatting.
The following was tested in IE7/FF3.6/Chrome/Safari 5
$("#textarea").bind('paste', function(e){
// Do whatever you needed to do with the code here.
});
Live Example http://jsfiddle.net/VSrTg/2/
Edit An approach would be something like this:
$("#textarea").bind('paste', function(e){
var oldText = this.value;
setTimeout(function() {
// Compare oldText to $("#textarea").val() and format accordingly.
}, 1000);
});
Edit 2 Given your revisions to your original post, if you're worried about the giant market share that is Opera, you're going to have to monitor the value of your textbox with a setInterval() and compare it against itself for changes.
Ultimately there will always be a way around your script, even the above example is susceptible to simply dragging text from another text box (or the address bar) into it without triggering the paste event defined above.
I would like to point out DOJO menu widget that is creating context menus perfectly in different browsers. http://www.dojotoolkit.org/reference-guide/dijit/Menu.html#dijit-menu
What you can do is that detect paste event in browsers that are supporting it and override context menu in browsers that are not supporting this event like opera.
Once you create your own context menu then you can add copy paste menu item or create context menu similar to the default using css.
Edited
Some browsers might not allow us to fetch clipboard content, in this case we can always revert back to flash for borrowing some of its features that are cross browser. See couple of links I posted in comments.
Its complete implementation might have more issues than anticipated but it is possible and we can always give it a try (I will for sure).
The answer to the question is a simple no. The main browsers that have no paste event are recent versions of Opera and Firefox 2. Given that there is no paste event, you need to find an alternative event or set of events to detect a paste from the context menu as it actually happens. You can add handlers for every event there is (I've done this) and you simply get nothing in the relevant browsers when a paste is triggered from the context menu by the user.
This only leaves polling the text input's value regularly, which is not the same thing. You could keep track of keypresses and observe in your polling code that the text input's value has changed by some means other than keyboard input and do a diff, but that's hacky and unreliable.
I use the setTimeout for paste events. But for context menu select nothing seems to work(as stated above). I bind a mousemove to the input's form which fires the update function. Then unbind/bind so they don't stack up.
This handles the context menu select and dragging value to input field.
If your form is small, say with only one input field and the mouse will not land on it after selecting from context menu, bind to the form's parent or document. Sure, it has to wait until the mouse moves but that is the general user action after selecting from context menu.
Works fine.
I have a select list where a change event has been bound to the element using jQuery. Something like this:
$("#someId").change(function() {..});
When someone chooses a new option in the select list, another part of the UI will change accordingly. Now this works fine when I use the mouse and click things, however, when using Watij to write my tests I need the jQuery change event to fire which it isn't doing.
The Watij test will correctly choose the select option required but the actual event does not get triggered. I have tried calling fireevent("change"); and fireevent("onchange"); to no avail. I have also tried ie.sendKeys("{ENTER}"); and ie.sendKeys("{TAB}"); which also does not seem to do the trick.
Any ideas?
The only solution I've found so far is to roll back the version of jQuery in use. I'm currently using version 1.4.1 (the offending version in regards to the testability of the change event on select boxes) and after going back to version 1.2.6 the problem goes away.
Use $('#someId').trigger('change'); to fire the event manually.
See the documentation for trigger().
When the combo/list value is changed with script the onchange is not supposed to fire. I don't know how Watij is doing that, but this is one case.
Second thing is that Watij is working with IE (as long as wikipedia is rght) and IE is putting a system control in place of Your list or combo and it might break something too. Try upgrading to IE8 which has a tiny bit better realisation of form components (eg. select finally supports "disabled" attribute in options after 10 years)
You might also be interested in a normal application GUI testing apps and use them on a browser with the webapp. Record a macro and check screenshots.
I am binding an event to a checkbox's change or click event which works fine in Firefox but in IE I have to click anywhere else (causing the blur) event before the event is fired.
I have read and believe this is down to the way IE fires the events, but is there anyway I can get round it?
The whole point is that it is a smooth search feature which doesn't need a search button to be clicked
$('#sidebar .itemSearchModule-Form input[type=checkbox]').click(function() {
$('#sidebar .itemSearchModule-Form .saveButton').click();
});
The change event requires a blur to happen first. The Click event should not. You could always force a blur event if you wanted by $(elem).blur()
Paolo Bergantino was right so this answer credit should go to him.
It seems my code was all screwed up and another selector was getting tied up with the sample I used above.
The CLICK event does work in IE I can confirm, if you are suffering the same problem ALL I can suggest is you check your code
try giving that checkbox a class like chkbx and try:
$('.chkbx').click(function() { etc...
its just for debuggin your selector.. being sure problem is in the action. i think for IE you need to use GetElementByID.