To prevent the default scrolling of a page I'm adding an event listener for "touchstart" events on the body and calling event.preventDefault() This works fine but I now can't access the debug console as it requires a page drag? Has anyone else had this problem and come up with a work around?
Hmm, interesting. Perhaps you can limit the scope of the bind to a less-encompassing region of the page, let's say an 'inner div' on the page, but not an 'outer div'? Then, perhaps you can leave yourself a small amount of margin between them for you to invoke the console?
i would suggest adding a parameter to the url by which you can reactivate scrolling
Related
I have an issue where a form is embedded in an iframe and after the form is submitted, the iframe is deleted from the DOM. Immediately after the form is deleted (the form was the last thing to have focus) I am unable to detect events that are bound to the root window element.
The frame is being loaded from a separate domain, although it does not matter for this example, it only matters that I have no control over the scripts on that page.
I understand that I cannot detect DOM events in the iframe, but all events are lost until the user clicks back on the DOM after iframe removal. This happens in both Firefox and Chrome. IE appears to return focus back to the original DOM as expected. I have not tested in other browsers.
$(window).keydown(function(e){
console.log (e.keyCode);
});
var $iframe = $("<iframe src='www.example.com'>");
$("body").append($iframe);
window.setTimeout(function(){
$iframe.remove();
}, 1000);
(The code above is just an example, i have included a working codepen to illustrate further- http://codepen.io/anon/pen/WQroqe)
To use the codepen -
Click the "click to load iframe button".
Make sure you click in the iframe so it has focus
After the iframe deletes, type anything and notice the DOM does not log your key strokes.
Click on the DOM and notice that your keystrokes are being logged properly.
Use Case: Form opens an iframe and submits, then removes itself from the DOM. I want to be able to detect keyboard events after the form is submitted without the user needing to use their mouse.
Question: I thought the top most DOM element was "window" and if this is not capturing the keyboard events, what is? There are no other DOMs currently present (i.e. iframes) as far as I know. I tested this is both firefox and chrome. Any explanation as to what is happening and why what I am trying to do is not possible or a way to capture the events would be greatly appreciated.
(My current solution is to use a MutationObserver to watch for the iframe to disappear and force focus back on the window. I also know I could use a setInterval to continually check for the iframe. Both solution feel like I am doing extra work).
after closing the iframe, focus the window using $(window).focus(); if you must
in the sample you'd do it like
$iframe.load(function(){
window.setTimeout(function(){
console.log("deleting");
$("#deleteMe iframe").remove();
$(window).focus(); // <======
}, 5000);
});
I need to learn how to right click on an element in a webpage using IE8 document mode.
The webpage I am working with is PTC's windchill 10, which I believe is created usings sencha's extjs. I am not sure if extjs registers the .click() method as a click always. Some elements I need to use onmousedown and onmouseup to get a click to work.
This function I have tested on the iframe object psbIFrame to do a regular .click() and it works using autohotkey.
Autohotkey Syntax
click_event:=window_handle.document.all.psbIFrame.contentWindow.document.createEventObject()
click_event.button:=1 ;left button down
links[a_index-1].fireEvent("onclick", click_event)
Javascript Type Syntax
document.all.psbIFrame.contentWindow.document.createEventObject();
click_event.button=1;
links[a_index-1].fireEvent("onclick", click_event)
I also have this working for other elements not in an iframe.
event:=document.createEventObject()
event.button:=1 ;left button down
element.fireEvent("onmousedown", event)
element.fireEvent("onmouseup", event)
Those are all left clicks since the document mode is ie8. When I set the button to 2 and do either of those I don't get anything happening.
Does anyone else have access to a windchill page that can help me test?
element.fireEvent("oncontextmenu")
This does what I expect a right click to do. With fireEvent you don't even need to initialize the event most times it seems. FireEvent will do that in the background assuming some defaults. I don't know if what I was doing in my question with changing the button to 2 even makes sense.
http://help.dottoro.com/ljvtddtm.php for fireEvent
http://help.dottoro.com/lagstsiq.php/#MouseEvent_Members for a list of mouse events
I am building a cordova/phonegap app using Jquery Mobile. My app feels very sluggish right now and I see that the main reason is that the page only shows up after about a second after I see the pageshow event being fired. Ideally, I expected it to be shown when the pageshow event is fired.
Also, during this meantime(after the pageshow before the page is actually shown) if I touch on the page at a certain point it fires the ontouch event on the item that is supposed to be present at that point. So the page is already there but maybe it's taking this time to render.
Do you know how to make this page render faster using JQuery Mobile? Is there something I can do with the custom Jquery Mobile builder that helps Jquery Mobile not do stuff that's not required?
Please note that I have turned off transitions globally on my app using
$.mobile.defaultPageTransition = 'none';
The mobile browsers has a delay of 300ms delay for touch events. To disable this you can use fastclick. It can remove that 300ms delay in your app.
https://github.com/ftlabs/fastclick
This can help you too to make it work faster.
The browsers wait for 300ms to check if the user has done a single click or is going to do a double tab. If the user has not touched again before 300ms, its considered as a single touch click.. else it's considered as double tab.
Just posting another answer as I think this would be the solution for your updated question.
If my understanding of your problem is correct, disabling the DOM cache will solve it.
$(document).bind("mobileinit", function(){
$.mobile.page.prototype.options.domCache = false;
});
When debugging HTML is there a way to listen for div width change using JavaScript or jQuery?
I have a div changing size due to some CSS and can't figure out where, even stepping through.
I was wondering if there was a way to hook an event up to a div to see what is causing it to change?
Even if possible, I'm not sure how how would pass stack information for what caused the size change in the first place, so this may not even be possible.
I use Chrome, it seems to give the most details.
Download Chrome
Press f12
goto first tab [Elements]
click on the magnifying glass and go to your div
right click on the highlighted html and select "Break on Subtree modifications"
This is bad way, but I'm not sure such event exists.
$(function(){
var last = $("#your_div").width();
setInterval(function(){
if (last != $("#your_div").width()){
alert('div width changed');
}
}, 100);
});
This guy explains how attach to the DOMAttrModified event to detect CSS changes.
Event detect when css property changed using Jquery
It's only supported in FF and Opera, but if its just for debugging it will do the trick.
http://www.quirksmode.org/dom/events/
Firebug for FireFox allows you to attach and break on CSS and attribute changes is this what you're looking for?
I came across an interesting bug feature tonight when writing a handler for window.onresize in Chrome (the latest version 6.0.472.55). First open two tabs, then in the first tab open this jsFiddle.
Resize the window at will and the dialog box works as expected. Now, try switching to the 2nd tab -_-. Why is resize firing when the tab is changed? Could someone provide insight/more details if I need to file a bug?
The bug has been filed with Google. For the time being, I've just ignored it since my actual onresize handler doesn't display alert boxes.
Well how about that? Sounds like a bug. I would guess that onresize is listened-for by a combination of behaviors, probably new data about the page size that, for whatever reason, is coming in when a tab is focused.
In the version I use on Windows, 5.0.375.127, it doesn't happen, but if I actually resize the window, the resize event fires twice.
Knowing it's there, you can take a step to defeat it (that Google ought to do for you eventually). Wrap an if statement around your handler that checks for an actual change in the clientHeight or clientWidth if you need something to happen only if the event (as we understand it) actually occurs.
From the bug report:
When using Dev Tools in splitview and switching to a Tab without Dev
Tools opened in split, the resize-Event will be fired.
So, if the next Tab doesn't have the same window size, resize() will
be fired.
Without a working knowledge of how Chrome handles tab switching and page rendering, my guess is as good (or bad, depending how you look at it) as the next guy's. I would guess that rerendering the page, or reloading the already rendered page if it caches it, triggers the onresize event. This is what happens when the tab is switched. Following my theory, I would guess that Chrome doesn't trigger the resize event on initial page view because it has been designed not to. But again, as I don't know how Chrome handles tab switching internally, this is just speculation (food for thought).