We have a PWA (web app) that the user can add to the homescreen to make it look more like an app. Some users have reported a strange issue that only seems to appear on IOS sometimes when the following step has been made.
Open the app from the homescreen
Use the app for a while
Put it into background
Turn off the screen for a while
Turn the screen back on and put the app to foreground again
The bug is that nothing seems to happen when you click on a select or date input control. First I thought that there was some overlay in the app that was blocking the ui controls but the elements receive focus on click, but not options are shown.
Now it really becomes strange. When I tried to click a little bit under the select input an option was selected. The same thing occured with a time select. If I first clicked on the timeselect input control and then a little bit under, it updated the time.
So, the controls seems to be there but nothing is visible on the screen. I have only been able to reproduce this on my own once but multiple users have been reporting the same thing. The only way to work around the bug is to restart the app.
It seems to be for all native safari controls that shows some kind of modal/popover.
I've did an indepth investigation on this select dropdown problem and posted an issue at bugs.webkit.org: https://bugs.webkit.org/show_bug.cgi?id=238318
It's a problem with dropdowns of several components (such as select, input file/date/month) where either the animation to have the dropdown appear or disappear seems to get stuck. You can sometimes see the dropdown being tiny and very transparent (if you zoom into a screenshot) and sometimes you'll be able to select an option even though you don't see the dropdown.
It is hard to paste all the code because I do not exactly know what is happening. My app is using a Tab Navigator as it's main navigation, and it works perfectly fine when I run it normally.
HOWEVER,
Whenever I forcefully quit it using the Android left button, it stops working when I reopen it.
Once it is re-open, I am able to swipe through all my tabs but each screen is FROZEN. I cannot click anything and the Tab Navigator does not update (it shows the initialRoute still selected).
I am very confused on what is causing the problem, my initial guess would be something to do with listeners but I really don't know which part of my app causes this. I have added the Firebase tag for this reason. I would like to try turning off all my listeners if the app is force closed, but I don't know if this is possible.
Other details:
I mostly use 'on' listeners.
Thanks.
I am seeing a weird bug that I am looking for help with.
I have an iPad iOS 7 app that allows people to fill out forms. Their entries are stored in a Sqlite database. When they reopen a form they have worked on entries they have made are redisplayed.
When the iPad goes to a new city all the entries seem to disappear. When the app is reactivated in the new location the current page appears fine, but scrolling left or right shows nothing but blank fields. The current page is also blank if you scroll away from it and back to it.
If you print or email the form while its data is not visible, the output contains all the missing data. The data also comes back if you double-press the home button, truly exit the app, and then restart it. But simply re-opening the form does not bring the data back.
When I took my Mac and iPad to a new city, the disappearing data effect happened but went away shortly after I started testing it. I don’t know whether it always goes away eventually. I didn’t test for it immediately when I got back home, and when I did start testing the bug was not happening.
Each field is backed by an object that includes a strong string property for the field’s value. The only thing I know for sure is that in forms with invisible data that string property is nil for fields that should have data. All the other field properties retain their correct values.
So far, a change in physical location is the only thing I have found that triggers this bug. My app uses location when the user gives permission, but runs fine without it. Changing the location in the simulator does not trigger the bug. I need a way to reproduce this bug but dread having to travel all over the state (or country!) just see it.
Thanks in advance for any thoughts or suggestions.
I've recently upgraded to Xcode 5.1 and I'm experiencing the most annoying bug. The instant search or method search dialog that allows you to search the methods on the given source file you are looking at isn't allowing me to enter more than one character. I have large source files and I tend to rely on that a lot. Any idea why this might be happening. I've tried re-installing Xcode (simply be dragging it in the trash).
You can find the search field I'm talking about by clicking the method as shown in the screenshot and simply typing something.
When I type the character gets replaced with the last letter entered.
(This one's just informational: I don't think it will fit in a comment, and want to report on what suggestions worked and didn't.)
I ran into this same problem. I accidentally typed some other key combo when trying to do Ctrl+6 to open the Document Items dropdown, and it was all out of whack after that.
As clance_911 mentioned, the filtering would work after clicking in the search box. So for example, to filter for "init", I could hit Ctrl+6 to open the Document Items, type "i" to start filtering (but then any subsequent letters would replace the i), click into the search text box, and continue typing the "nit". This works, but it's a pain.
As Moze pointed out, this seems to be specific to external displays. Sure enough, it worked fine on my MacBook display, but if I moved Xcode over to the external display, it stopped working. In my case, dragging the menu bar in the display Arrangements settings (to make the external monitor the main display) did solve the problem: the filter worked correctly with Xcode in either window. Sorry, Etienne :-(
The other solution that worked for me was simply closing the MacBook: use it in clamshell mode with only the external display. This is my normal setup anyway, but I know that's not ideal for everyone.
It happens if Xcode is open in external display that is not main display.
To fix it, open display setting's Arrangement tab and drag menu bar to display that you are working on.
This is more of a general annoyance. Every time after stopping the simulator, Xcode jumps to main.m for some reason. On the left nav, it jumps to the Debug Navigator.
Is there a way to fix this?
It's annoying because I might be testing a certain line of code, and now each time, I need to make a couple of clicks just to go back to that code.
This problem is not new, seems to get worse though. At the time of writing this, I was on the GM seed, but this problem persists in XCode 4.2 final. This was not a problem in previous versions of XCode.
When we start debug from xcode, the debugger sets itself up to monitor signals from OS. When we press stop button in XCode (or hit cmd + R - which first stops existing instance running and then try to start new one, somewhat equalant to we press manually stop first and then run) SIGKILL is sent to the debugger.
Whenever the cause of interruption is from outside the app (in other words all cases where SIGKILL is sent, like stop button press) , debugger jumps to main, since main is the root of the app and the place where your app meets the OS. Debugger has no way to identify why this SIGKILL is issued (pressing stop button in xcode/ press cmd + R/ delete app from multitasking bar etc), but it treats SIGKILL as outside interrupt, and nothing related with your code. So it jumps to main.
If the cause of interruption is from inside the app (like app crash/SIGABRT) debugger handles it and jumps to the place of crash, which we normally see.
I do not consider this as an xcode bug, rather a normal way of handling SIGKILL. But if you want to stay at your code and do not want to jump to main you can do two things
You can do as Gabe suggested. As BBonified said, it is like a band-aide,
but I think it should work (personally I never tried that)
Report a bug/request for a feature here. Let me tell you you
are not the first one to do so. Already a bug has been reported. See
this and this. But I don't have much hope of a positive action from Apple
And I agree with you, it is sometimes annoying. Especially if you have experienced differently in previous XCode versions. But we can only take what they give here.
I guess it's fair to call it a bug, Xcode 3 specifically suppressed this useless artefact.
I've had success (four times and counting) with this one-liner in ~/.gdbinit:
handle SIGKILL nostop noprint nopass
Taken from this gdb manual:
http://www.delorie.com/gnu/docs/gdb/gdb_39.html
Not sure if it applies to lldb as well.
I tried what David suggested but that didn't work for me, so I tried something similar:
Open Preferences, select Behaviors tab.
Select "Run exits unexpectedly" from left column.
Select "Show debugger with current views".
I'm using Xcode version 4.2 build 4D199.
EDIT: That worked for about 15 minutes. Then it reverted to bringing up main.m in the editor again.
I had the same problem and it WAS really annoying, especially when you were in the middle of debugging, stopping/launching the app several times in a row after small modifications.
Everything is solvable through settings in Xcode user preferences:
Just go to "run completes"
There find the "Show" line and click the checkbox
On the same line modify target to go to "Current" in the dropdown menu.
There you go. Xcode will not move your editing view from now on. Enjoy.
PS: Xcode version 4.2 Build 4C199
Go to Preferences -> Behaviors. Choose "Run Completes" in the left hand side. Check the box next to "Show Tab" and enter a tab name. I use "Edit". This way whenever you stop, you will always be back at a tab called Edit.
None of the other solutions listed were suitable for me, so I made a macro (using an external hotkey utility).
(wait 0.1 second after each step)
command-period
command-1
down arrow
up arrow
command-j
enter
Use this key instead of the normal stop, and you end up with your cursor positioned where you left it. Very nice.
Xcode -> Preferences
Under Behaviors
Click on Run Starts
Checkbox for [Show] debugger with [Current Views]
...worked for me.
None of the preference adjustments seem to work for me.
I have been able to track the offending sequence of events. The SIGKILL error message will occur when you run your app and use multiple threads. For instance, when using UIWebView in my app it will abort to main.m. I verified that when UIWebView is not called, XCode can be stopped without the SIGKILL error message returning the user to main.m
It looks like there are at least two threads that get started when initializing a UIWebView.
However, any threads created by you during the running of your app will cause the SIGKILL to improperly notify XCODE to return to the main.
You can see this in the GDB that there is a switch just before SIGKILL:
[Switching to process 24957 thread 0x2103]
[Switching to process 24957 thread 0x7403]
[Switching to process 24957 thread 0x207]
Program ended with exit code: 0
It is definitely still a bug with XCODE that will hopefully be fixed.
For now, if you avoid executing code that launches a separate thread, it will not change the view back to main.m For code that does launch additional threads, I would recommend quitting the simulator to return to edit mode in XCODE.
None of these solutions worked for me and I find the behavior too intrusive to put up with.
I get round it by using the 'Assistant Editor' instead of the editor as my main editing window. You access the Assistant Editor using the tiny little bow tie button at the top right of the single window.
You can set then it to 'Manual'. Click on the button that is the far left crumb of the breadcrumb trail at the top of the Assistant Editor frame and select Manual from the pop-up menu that appears. The Manual setting allows you to select the file you're editing by clicking on the second to last crumb of the breadcrumb trail and selecting the file from the pop-up that appears.
I then just minimize the size of the main editor - or use it as a secondary editing window, useful given that you can't split the editors into multiple frames any more. Far from ideal - but that's XCode 4 for you.
This might not be much. I was able to avoid this problem 99% of the time by waiting for 2 seconds or so after stopping the app, before relaunching it.
UPDATE: After upgrading to the latest Xcode, I am prompted to use LLDB instead of GDB. The problem seems to be gone now.
I was trying to find the offending line when my code was breaking, so what I did was:
Go to where you define your breakpoints (breakpoint navigator, according to the documentation)
Click in the "+" sign in the left bottom corner of the navigation area
Click on Add Exception breakpoint
You click Done
Run your app
Xcode shows you the offending line.