I want to silently scroll the window when the page is completely loaded, so I call silentScroll inside the initPage listener. However, it doesn't work, no scrolling.
$('#mainPage').live( 'pageinit', initPage);
function initPage() {
$.mobile.fixedToolbars.setTouchToggleEnabled(false);
$.mobile.silentScroll(800);
....
The only way I can get it to work is to call it via setTimeout, but why? The page should be ready when pageinit is executed, referring to the jqm docs on http://jquerymobile.com/demos/1.0/docs/api/events.html.
With this, automatic scroll works, but it's ugly:
setTimeout(function(){$.mobile.silentScroll(8000);}, 1000); // scroll after 1 sec
Executing $.mobile.silentScroll(8000); in Firebug / Chrome dev tools also works ok, just not in initPage. When I display an js alert in initPage, it's being shown. But the scrolling is just not being executed properly. Maybe a jqm bug?
Detailed answer to this question here:
https://github.com/jquery/jquery-mobile/issues/3461
Related
We are trying to scroll an element on our iOS web app while preventing the window itself from scrolling. We are capturing the touchmove event on the window, scrolling the element programmatically and (trying to) prevent the window itself from scroll by calling preventDefault on the event.
Unfortunately this doesn't work in Mobile Safari. The window continues to scroll underneath our element. The issue sounds exactly like the Webkit bug described in https://bugs.webkit.org/show_bug.cgi?id=163207, but that issue was supposedly fixed in iOS 10.3 whereas I am running 11.3.
Catching touchforcestart and calling preventDefault does seem to prevent scrolling of the window, but we are calling it in touchstart, which seems to be "too late" since the window still scrolls. Scrolling is only prevented next time touchstart is called.
Any ideas about what is going on? We are baffled since this is clearly a bug but it seems to have been fixed some time ago.
I recently ran into this same problem. You'll need to pass { passive: false } when registering the touchmove event listener. e.g.
document.addEventListener('touchmove', function(e) {
e.preventDefault();
}, { passive: false });
This is because document touch event listeners are now passive by default in Safari 11.1, which is bundled with iOS 11.3. This change is documented in the Safari 11.1 release notes:
Web APIs
[...]
Updated root document touch event listeners to use passive mode improving scrolling performance and reducing crashes.
You need to bind preventDefault to two events: touchmove and touchforcechange to make it work in ios 11, e.g.
document.addEventListener('touchmove', this.preventDefault, {passive: false});
document.addEventListener('touchforcechange', this.preventDefault, {passive: false});
And you should bind them before touchstart
If you bind them inside your touchstart or dragStart handler, they can only prevent scroll in the next dragging.
What worked for me was to pass the {passive:false} option to addEventListener (explanation), and you also need to make sure you execute e.preventDefault() on touchmove and touchstart:
window.addEventListener("touchstart", e=>e.preventDefault(), {passive:false});
window.addEventListener("touchmove", e=>e.preventDefault(), {passive:false});
On Safari 10, by defining a simple listener that prevents default a touchmove event within a scrollable element, the event is not default prevented as it does with Safari 9 and less (it also does in all major browsers).
This is reproducible here: http://codepen.io/anon/pen/PGRxOv
Steps to Reproduce:
Take an element with scrollable content (overflow: scroll).
Add an event listener on it for touchmouve event, and call event.preventDefault() in that event listener.
Expected Results:
The element should not be scrollable.
Actual Results:
The element is still scrollable on Safari 10.
Version:
iOS 10.0.2
Probably a webkit issue...I opened an issue on webkit bug tracker.
In the mean time, if anyone has a workaround (except prevent the touchstart), it would be great :)
I also tried to return false in the listener but it does not work either.
You need to pass the {passive:false} option to addEventListener (explanation), and you also need to make sure you execute e.preventDefault() on touchmove and touchstart:
window.addEventListener("touchstart", e=>e.preventDefault(), {passive:false});
window.addEventListener("touchmove", e=>e.preventDefault(), {passive:false});
Thanks for writing about this and raising an issue — it had me completely baffled!
Your codepen solution didn't seem to work for me, but I have since found another solution here: https://github.com/metafizzy/flickity/issues/457
This is their solution:
window.addEventListener( 'touchmove', function() {})
Feels very hacky but has worked for my situation.
I hope this helps anyone else frustrated by this.
I have an HTA which opens a showmodaldialog and this JavaScript code in the dialog page:
function helpButton(){
document.body.style.curosor = "help";
my_div.onclick = function(){alert("Help for the div is displayed here")}
}
I want a help button in the title bar of the showmodaldialog, like on the picture below:
(don't mind about the fact that the picture's in French, it's my computer's language)
When I push on that help button, I want it to execute the helpButton() function.
There was showModalDialog('path', 'arg', 'help:yes'); and you could attach an onhelp handler within the opened dialog's window. However, this dialog property is obsoleted - since IE9, if I'd recall correctly - and can't be returned by downgrading the app using X-UA when running a HTA with a newer IE.
You still can set onhelp, and call it by hitting F1:
window.onhelp = function () {
alert('Help is asked.');
};
I'm using a GRAILS UI (1.2-SNAPSHOT) an it's implementation of the YUI menubar (YUI 2.7.0.1). I am seeing flakey mouseover behavior in IE (Firefox is ok). When I mouse over the menu item with a submenu, it will show. As I try to mouse over the sub-menu, the submenu disappears before I can click. This happends in a pattern I haven't fully figured out. Usually the first time I select a menu it's fine but if I move around the menu back to a menu item, the submenu begins to display this behavior. By clicking and holding the mouse button I can usually get the sub-menu to stick around.
I've palyed with various configurations like keepopen and automenudisplay but they don't seem to change the behavior. I have not seen much posted about this. But I also don't see menu's documented in the UI plugin either. I could really use some feedback if UI menu is not ready for primetime yet or I'm missing something else. I've not worked with much AJAX before.
Below is the code with the added options I played with that did not have a positive impact.
<gui:menubar id='menubar' renderTo='mainmenu' autosubmenudisplay="false" shadow="true" keepopen="true">
<gui:menuitem url="/esmzone">Home</gui:menuitem>
<gui:submenu label='Profile'>
<gui:menuitem url="${createLink(controller:'memberProfile', action:'view')}">View</gui:menuitem>
<gui:menuitem url="${createLink(controller:'memberProfile', action:'profile')}">Edit</gui:menuitem>
<gui:menuitem url="${createLink(controller:'user', action:'account')}">Settings</gui:menuitem>
<gui:menuitem url="#">Subscription</gui:menuitem>
</gui:submenu>
Here is the code generated by the plugin:
<script>
YAHOO.util.Event.onDOMReady(function() {
GRAILSUI.menubar = new YAHOO.widget.MenuBar("menubar_div", {'autosubmenudisplay': false,
'shadow': true,
'keepopen': true});
GRAILSUI.menubar.render('mainmenu');
});
</script>
I made some progress on this by researching the YUI library. There is a documented bug with IE7. Apparently the grails-ui plugin does not address the fix. I'm testing with IE8 but I assume it's still there.
http://developer.yahoo.com/yui/menu/#knownissues
It appears that you should set the zoom property to 1 (zoom:1) for the bd class.
I added the following code to my style sheet
div.yuimenubar .bd {
zoom: 1;
}
and it seems to help. I see no side effect in Firefox but I didn't dynamically check for the version of browser as I would need to hack the code that generates the YUI javascript and put in
if (YAHOO.env.ua.ie === 7) {
YAHOO.util.Dom.addClass(document.body, "ie7");
}
after the render() call. Then instead of the style I added you could do an IE7 (probably >=7) style.
This is what the Yahoo site had to say about it:
The following application of
"zoom:1" sets the "hasLayout"
property to "true" and prevents
first tier submenus of a MenuBar
from hiding when the mouse is moving
from an item in a MenuBar to a
submenu in IE 7.
For more on the "hasLayout" property:
http://msdn.microsoft.com/en-us/library/ms533776(VS.85).aspx
I have a form inside jQuery tabs; I create tabs in a simple way:
$("#tabs").tabs({selected: 1});
The selected index 1 is the tab where form is placed. The problem is, on remote computer with IE6 both selects only display a small blank line instead of list with options when dropdown arrow is clicked:
Incorrect dropdown http://queen3.at.tut.by/DropDownIE6jQuery.PNG
The options are there in page source, and everything actually works on other machines, in other browsers and also in IE6 (though I use IETester).
Everything also works if I
remove tabs creation, that is .tabs() - options do appear and work; or
first select tab without form (tab 0), and then click on it - options do appear and work
only when clicking; programmatic .tabs("select", 1) after tabs creation doesn't help
Does anyone know what can cause this? Is it IE6 bug or something with my scripts?
Update: hm, thanks to this, I found it's something with my CSS - if I disable Site.css it works. I thought about scripts only. Still have to find out what's that.
Update: OK, this was caused by this CSS rule:
body { font-size: 0.7em; }
It works if I set 0.8 or greater, but for 0.7 and less IE6 does the indicated bug.
Can someone explain this? Yes it is IE6 - weird by definition, but this one is too weird in my opinion.
I have also ran into this exact problem, although I couldn't fix it by altering any body font sizes, I did manage to get around it using the (slightly modified) "Ugly hack" method as described in the dev.jqueryui.com/ticket/4734 link, posted by CiscoIPPhone:
// Ugly hack to switch tabs in IE6, fixing select menu bug.
if($.browser.msie && $.browser.version.substr(0, 1) <= 6) {
$("#tabs").tabs({ selected: 1 });
setTimeout(function() {
$("#tabs").tabs("select", 0);
}, 10);
}
Seems as though the timeout is the key to avoiding this bug.
I found that this workaround fixed the issue on some machines, but not on others.
My solution was to hide all the select elements initally in the style sheet, then after calling $( "#tabs" ).tabs() I use $('select').show() to display them.
That fixed it for me.