I have an angular app which is using http://binarymuse.github.io/ngInfiniteScroll
In one of my feature tests, I am trying to simulate the user scrolling to the bottom of the page, it's pretty straight forward, there is an expectation that the page has the selector '.spinner' after scrolling down to the bottom.
50% of the time it works, 50% it fails. When I watch the test live in Chrome, the scroll bar goes down to the bottom of the page and nothing happens. If I throw a breakpoint in there, and then use my mouse scrolling up and down over and over, nothing happens. It's as if infinite scroll is dead. If I keep rerunning the test, eventually it will work (deep sigh), so it's one of those annoying bogus things that only make our love for Capybara that much stronger.
I've tried scrolling the page with:
page.execute_script "$('body').scrollTop(99999999999)"
and
page.execute_script "window.scrollTo(0, 99999999999)"
both of them yield intermittent results... I also tried iterating over a loop and scrolling the page in chunks to literally make it look like it's being dragged down to the bottom. Same nonsensical results.
I am now having to solve my problem by manually triggering the method that gets called by infinite scroll:
page.execute_script "angular.element('.listing').scope().nextPage();"
Which absolutely sucks and kind of defeats the purpose of an integration test.
Can anyone offer any suggestions how to resolve this severe case of obnoxious bogusness?
Related
So, I haven't been able to figure this out yet, because when I pause execution... Xcode doesn't really show what's going on:
This freeze happens when I scroll a very long UITableView around in the center of its scrollable area constantly, so that it's constantly reusing cells. I think that perhaps there is something not being retained for a dispatch block that might happen there, but I'm not yet sure since no data is displayed using the standard debugger and its a fairly complex view. (reference: https://stackoverflow.com/a/23501382/963901 )
I'm going to attempt some manual diagnosis here, but is there any other way of approaching this with Instruments or something, perhaps?
To investigate this sort of problem I'd suggest the following:
Disable the setting in Xcode's debug navigator pane that hides intermediate stack frames from you. It's one of the buttons at the bottom right of the pane that shows the stack trace.
Look at the newly-revealed portion of the backtrace to see what code is blocking on the semaphore.
Look at the other threads in your program to see which appear to be doing work related to the code discovered in step 2.
I have a weird issue in an iOS app written in Xamarin. That happens is that the lower left item from time to time loads late.
I'm not quite sure which information is relevant to this issue, since I tried to remove almost all complexity (stuff like custom delegate and and UICollectionViewFlowLayout)
What makes this even weirder is that when it loads it is shown for about a second and then disappears, until i start scrolling past it.
Has anyone experienced a similar issue?
I'm having a weird problem with UIScrollviews. I use them in various screens, menus, iCarousel, sometimes with paging and bounce.
After using the app for a while the scroll animations stop working. I can still scroll but after dragging ends there is no more "animation with velocity", scrolling just stops right away, even if I swipe "hard". All events still seem to fire. scrollRectToVisible works fine at the beginning but stops working completely after point of break. Even very simple scrollviews that have not been customized won't bounce back anymore.
I couldn't find a real cause/trigger so far, thus it's tough to post code since scrollviews are all over the place. I'm developing for iOS for more than 4 years now, using scrollviews extensively in most of my projects and I checked the obvious places in my code already. I hope someone else came across this and knows what's causing it.
I have an iOS app that, in one view, makes a toolbar in code. Nothing fancy here; just a bunch of standard UIBarButtonItems (initialized with initWithImage, and each one invoking a different selector), added (along with spacers) to the toolbar using UIToolbar setItems:animated (with no animation).
This works fine most of the time... but sometimes, after going to another view and back to this one many times, the toolbar's touch-handling appears to be off. It highlights and invokes the wrong button. It's not always the same wrong button, either; sometimes it's one right next to the one I actually tapped, but other times it is further away, even clear over on the other side of the toolbar.
There is no pattern to it, but if you try long enough (switching to another view and then back to this one), it always happens. It seems to happen more often when the other view is at a different screen orientation (forced by its shouldAutorotateToInterfaceOrientation implementation), but even when all views have the same orientation, it still happens now and then. When it happens, my selector gets invoked with a sender that matches the button that was actually highlighted, rather than the one I touched. So it really seems to be a matter of something in iOS not processing the touch correctly.
My google-fu has utterly failed to turn up any other reports of this issue... seems like it must be an Apple bug, since none of my code is involved in the toolbar touch handling. This happens both in the simulator and on the device, under iOS 4.3 (haven't tried other versions yet).
Has anyone else run into this issue? Any suggestions on how to avoid it?
OK, I found the problem. It wasn't the code that creates the toolbar itself; it was where (and how often!) it was being called.
This was legacy code, and we hadn't noticed that the create-the-toolbar code was being called from the view's didRotateFromInterfaceOrientation method (for reasons we can't imagine). That method gets invoked quite frequently, and the old toolbar wasn't being torn down, so it was creating toolbars on top of toolbars. Not too surprising that the touch handling went wonky in that situation.
Deleting the call there (and putting it in viewDidLoad like one would expect) solved the problem. Sorry for wasting everybody's time... but maybe the next person to stumble across screwy toolbar behavior will find this helpful.
I have a program based on UITableView (the user can edit the contents of the cells). After a long time open (mostly in the background) it will sometimes suddenly stop allowing you to fully scroll to the bottom of the list. The scroll is set to bounce, so it will bounce up and you can see the last few rows, but it will bounce right back down and hide them again.
I am using the navigation controller's toolbar, so in some ways it seems like the toolbar hides the last few items, but I think that's not really what's going on. (I think the last item or two would be off the screen anyway.)
Again, there is no problem scrolling most of the time.
It happens so rarely that I haven't been able to get very close to identifying the cause. It seems like it might happen after rotating to landscape mode, but many many rotations can occur without causing the problem. It also seems to show up after my phone has gone well below 10% battery before being recharged (I notice the problem after the battery is back to full, but it could be it starts before that, or that the battery status is totally unrelated).
Since it happens after the program has been running for days (mostly in the background) and is fixed by restarting the phone, I have suspected a memory leak, but I don't get any memory warnings and the program runs normally otherwise, even when the scrolling stops behaving correctly.
I have run Leaks a few times, and only once found a 16 byte leak on exiting the program, which I haven't been able to reproduce.
Any thoughts would be deeply appreciated.
Leaks wouldn't cause such problems by themselves. Sounds like your table gets resized, either automatically with UIViewAutoresizingFlexibleBottomMargin/UIViewAutoresizingFlexibleHeight resizing mask or manually.