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!).
Related
EDIT: This is a bug in Firefox, and cannot be resolved without editing Firefox directly, which I have no desire to do. I consider this question resolved for the purpose of asking other people for he.
I am trying to create a pixel-based drawing program using SVG. I initialize the event handlers on a couple of <polygon>s inside a <defs>, and then copy that a bunch of times with <use>s to make the the canvas, and it works fine, in Chrome.
But regardless of whether I assign the .onclick attribute or use .addEventListener, my <use>s don't register anything in Firefox. As I was researching solutions for this, I found another thematically, and possibly technically, related phenomenon: <use>s copied using .cloneNode also do not retain event listeners. I could assign each <use> element the event listeners as I generate them, but it seems to me that that is the least desirable solution.
The only solution I came up with is to register the same event listener on the use element. After that it works in Firefox, but not anymore in IE, Safari and Chrome, because the event gets fired twice. Therefore you have to de-register the event of the copied SVG element. It is a workaround, but no good solution. I hope someone else can give a better answer for that.
Is there a way to capture JavaScript events for when a contenteditable element begins and ends editing?
I'm not sure exactly here, but aren't you after focus and blur? I'm not sure what else "begins and ends editing" could be translated to that has a different timing than those, unless you mean an event for every keystroke, etc.
As Nick said, focus and blur will work, and in all major browsers. IE also has a number of related events (although none of these are implemented in other browsers as far as I know): activate, deactivate, beforeactivate, beforedeactivate and beforeeditfocus
I'm developing a web application which requires long-running Ajax requests. Unfortunately, under Firefox, pressing Escape during a request has the drawback of killing the request and any information it was holding. This is rather annoying, as this can lead to all sorts of nasty complications if this happens at the wrong time. Therefore, I would like to deactivate this feature.
My first reflex was to intercept keypresses at the boundaries of <body>, to ensure that they would not reach the window. For this purpose, I installed a [keypress] event handler, just for events whose [keyChar] is 27, and had it invoke [stopPropagation] and [preventDefault]. And for a time, it looked like this was working.
Then, I realized that it wouldn't work when the user hadn't clicked anywhere on the window, as <body> event handlers never received the event. I tried to attach my handler to <document> or <window> to no avail, so I eventually ended up adding a [load] event handler and had it force focus to <body>. And for a time, it looked like this was working.
Then, I realized that when the user was editing an <input>, for some reason, once again, the <body>, <document> or <window> event handler never seem to receive the event. So, I added yet another [keypress] handler, intercepting with [preventDefault] on the <input> when the [keyChar] is 27.
For the moment, it looks like it's working. However, with the history of this bug in my application, I'm a tad pessimistic.
So, I'm wondering if there's a better -- and reproducible -- method. Recall that the bug seems to appear only in Firefox, so I'm quite willing to take a Firefox-only approach here.
I'd be worried about other nasty complications that will happen when the users choose a bookmark or otherwise navigate away in the middle of the request. You might want to look at why you're using long running requests and see if that's something you can change...
If it isn't something you can change (or even if you can) you should look at why your requests aren't fault tolerant. Is there a way to put the communication into transactions, and roll the latest one back if the connection is interrupted?
I know this is kind of an old thread but there's an active bug logged against Mozilla regarding this issue (which I'm also facing). See https://bugzilla.mozilla.org/show_bug.cgi?id=614304 for more info.
One suggestion from this bug is to intercept and prevent the ESC key press at the window level (as also mentioned by OP):
window.addEventListener('keydown', function(e) {(e.keyCode == 27 && e.preventDefault())});
This might have unwanted side-effects though.
Is there a cross-browser way to detect live changes to an input field?
By live, I mean not when the field loses focus, and not on the next keypress, and so on. Immediately or something like it.
Using combinations of jQuery and .change(), .keyup(), .bind('paste') and so on I can get working live change detection in some browsers, but not all. Using different combinations will make it work somewhat in other browsers.
The trickiest thing to get working is mouse manipulation of the input field - selecting text and moving it (which is essentially cut and paste), right-clicking and pasting or cutting, etc. For some reason even .mousedown() and .mouseup() don't seem to cut it.
The only cross-browser solution I can think of right now is to check the input field value every 100-or-so milliseconds and compare the value against a stored value. But this seems like overkill when the event-based solution comes so close.
Is there a jQuery plug-in that does this already? Or is there some other way to achieve this?
To complete your change and key handlers, you can add handlers for cut/copy/paste. They work in Firefox >=3, IE, Safari and Chrome (but not in Opera/Konqueror).
Would that cover everything for your use case?
Depending on the Browsers you need to support you might use HTML5's oninput.
It fires immediately when the monitored input changes. In jQuery you would just do:
$('#my-input').bind('input', function(e) {
console.log("#my-input's value changed");
});
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.