This one is a nightmare to debug since it almost always happens only on a native android device, where it is impossible to inspect the DOM (or is there a way?).
Essentially, once this bug is triggered, no more scrolling is possible in the app until a full refresh is done.
Note: LightSwitch does not support jq-mobile newer than 1.3.2
This issue happens quite more rarely on desktop. But since it finally did, I was able to dig thru the DOM to see what was happening. Once I knew where the issue was, it didn't take long to find a documented bug in jq-mobile-1.3.2 that LightSwitch uses: https://github.com/jquery/jquery-mobile/issues/6515
Root cause: sometimes when LightSwitch refreshes the data, the screen get's stuck in a transitioning mode (jq mobile feature), and transitioning CSS class has a overflow:hidden property set.
The link above describes how to modify jquery-mobile to make transition state more robust, but for the purposes of LightSwitch, just add the following CSS into user-customization.css
.ui-mobile-viewport-transitioning, .ui-mobile-viewport-transitioning .ui-page {
overflow: auto !important;
}
Related
The specific warning message is:
Unable to preventDefault inside passive event listener due to target being treated as passive.
This issue can also be reproduced easily in the demo site by JTSage if you use chrome F12 "Device" mode -- many warning in F12 console.
http://dev.jtsage.com/DateBox/jqm/timeflipbox/
http://dev.jtsage.com/DateBox/
Is it something to be concerned about? Occasionally my Chrome simulator would freeze. But I do not know for sure if this is related to those warnings.
I have also googled a bit to find below link, but I do not know enough on how to apply their suggestions on jtsage timeflipbox yet:
https://github.com/bevacqua/dragula/issues/468
Any suggestions?
Use this CSS:
.ui-datebox-container {
touch-action: none;
}
Reference: https://developer.mozilla.org/en-US/docs/Web/CSS/touch-action
I've made a fairly simple "Coming soon" page for a client here and I have a very strange problem. Normally I'm the "go-to" CSS specialist of everyone I personally know, but on this one I am out of resources/ideas trying to figure it out.
On iPhones, using the default browser (Safari), the email input, which has a type="text", just like the name field, displays a white border instead of a blue one. The client reported the problem (she has an iPhone6 - not sure if S or not) and I tested it myself with on an ancient piece (4s) we just keep around the office for testing. For all I know, border-color is a CSS1 property, same as border-width and border-style. They are all applied explicitly so, basically no browser in the world should have a problem rendering it.
I haven't been able to reproduce the issue in any emulator or online snippet tool, so I don't see any point in posting code here. I'm assuming someone with proper iOS/Safari debugging tools/environment might be able to inspect the element and see why the CSS doesn't apply. I also tested the CSS for errors. The one I applied (child theme) is bug free. The parent theme CSS reports some issues but they're mostly vendor prefixes. But it's a good, well designed and well coded theme: Enfold by Kriesi.
EDIT: On further testing I just discovered the color property is also set to white too, when it should be the same blue: #255AA8.
Any idea on how I could debug this (on a Windows 10 machine) is also welcome.
Thank you for your time.
I found the problem... in the themes's .js.
Apparently, it detects if on mobile (somehow they do it properly - as the script doesn't fire in emulators) and if the field requires an email address, the type attribute is changed from text to email via js, so the email keyboard layout pops up when user inputs their email.
Adding
#top div .av-light-form input[type="email"] {
}
to my list of selectors did the job.
Is it just me, or is the angular-material "Getting Started" example broken?
On that page (link above), there's an inline codepen to show using angular-material. But the demo doesn't work! (In particular, I don't see a button to collapse the sidebar.)
Since I used this example in my started project, I spent quite some time troubleshooting it -- to no avail. Then, I realized the example itself it may be broken. And sure 'nuff, it is!
Does anyone know what the actual bug is, so I can work around it on my test app? It must have worked at some time; but I can't figure out why it's broken now.
Thanks!
That particular pen is working fine for me but I have noticed a few are not working, and it's due to the angular-material.js link being incorrect in the dependencies (under the pen's settings) the link provided redirects to the CSS.
This is intentional - the sidebar only becomes collapsable on smaller screens and is open on larger screens. Shrinking your browser window will show the collapse button.
That being said, the Getting Started page is definitely in need of an update. It is a good guide for a basic page structure, but the individual demo pages will be a lot better if you're looking to try out some of the components. (Every demo has a CodePen link to open an editable version.)
I'm writing an angular app, using angular-ui-router to manage states / routing.
On desktop browsers (Chrome / Safari) this is working fine. However, on Mobile Safari on IOS 6 on iPhone 4 (and to a lesser extend on IOS 7 on iPhone 5) changing state, via $state.go, can take anything up to 2 seconds.
I'm using ngTouch, so I don't think that it's the 300ms that the native click event takes to fire. ngClick attributes that don't call $state.go now seem to work pretty much instantaneously.
How can I debug this to find where the time is being spent?
ngTouch doesn't work with the ui-sref directive. We used fastclick.js to handle the click behavior, and removed ngTouch. The issue is that the directives step on each others events, and are in fact incompatible. You can see this by reading the implementation of both directives.
Use console.time to print out in the Mobile Safari Console,
https://developer.chrome.com/devtools/docs/console-api#consoletimelabel
...in association with the ui-router listeners :
$stateChangeStart
$stateChangeSuccess
$viewContentLoading
$viewContentLoaded
/* EXAMPLE - INCREMENT THE TIMER
FOR EACH ONE OF THE LISTENERS, TO DETECT THE BOOTLENECK */
// START TIMING NOW
console.time('state_transition');
/*
http://devin-clark.com/what-you-might-not-know-about-chrome-devtools/
*/
$rootScope.$on('$stateChangeSuccess',
function(event, toState, toParams, fromState, fromParams){
console.timeStamp('state_transition');
});
// STOP TIMER
console.timeEnd('state_transition');
http://www.ng-newsletter.com/posts/angular-ui-router.html
Who knows, maybe for improving ui-router's reactivity on mobile devices, FutureState from UI-router's extras could be something worth to explore :
http://christopherthielen.github.io/ui-router-extras/#/future
...but the only way to be sure is to understand the innards of the mobile browsers and their DOM/JS/GPU's management/computing limitations in respect of desktop browsers.
It could be that ng-animate requires too much of a mobile browser by building the "next" template ahead of its appearance into the viewport. And yet it could be something completely trivial.
Please let us know your progress.
I'm getting a weird error while trying to click on a Capybara Element
I'm using find(:xpath,"//a[contains(text(),'Connect')]").click
(find(:xpath,"//a[contains(text(),'Connect')]").present? return true)
the error I get is:
Selenium::WebDriver::Error::MoveTargetOutOfBoundsError Exception: Element cannot be scrolled into view:javascript:void(0);
i did some research and the only solution i found is that setting the selenium version to 2.16 may fix this issue (i'm using 2.25).
anybody got an idea?
It may happen when the page being tested is not fit into the current window size. If you know such pages where usually these error happening, you may explicitly scroll down before doing the operation on such hidden elements(like click, clear etc). Here the code to explicitly scroll down the page.
In java,
JavascriptExecutor js = (JavascriptExecutor) driver;
js.executeScript("javascript:window.scrollBy(250,350)");
From the times I used selenium webdriver to test .NET apps, I would get that error when the issue was exactly what it sounds like: It's looking for an object on the page that it cant scroll to for some reason. In my case it was because some dialogue boxes would appear without scrollbars and the driver had no way to "scroll the object into view"
Can you watch the execution of your test and see if that's the case? I had some luck rolling back to a previous version of firefox because 15+ was (as of about 2 months ago when I had the issue) unsupported by web driver and had this problem periodically. Rolling back selenium versions may help too.
First step though is definitely to watch the execution of the test and see whats happening though. And a good debugging idea may be to try to work through your steps manually yourself to make sure the test works by hand.
Its also worth noting that for the webdriver to be able to execute click the object actually has to be visible. IsPresent doesnt require that, it just searches the page files. Also an issue I ran into. IsPresent will still return true for objects that are not and cannot be made visible on the page (i.e. something at the bottom of the page that you cant see at the time)
Couple of tips here:
Webdriver should ideally be on the most recent update, it's what most use (Unless you're doing Ruby Automation)
Use css selectors, xpath (Whilst rendered), is almost always heavier on both resources and code.
Try defensive coding, first of all ascertain it exists. There are many ways to do that dependent on what package you are using. In ruby you would do page.has_css?('css_string')