Occasionally when I search a project, the search bar and the navigation icons disappear from the screen. I can look through different files, but can’t cancel the search or go anywhere else. There’s nothing to be done except close Scrivener and start again. This is on an iPad in landscape mode. A screenshot is attached.
Interesting! If you figure out how to make the controls disappear like that at will, please let us know. It can probably be fixed.
In the meanwhile, there may be a way out of this condition without shutting down the software entire. Try swiping right from the very left edge of the screen—just like “Back” in a browser. That gesture works for all sidebar navigation in Scrivener. Search results are consider a navigation event in that you can go “back” to them from drilling down into search results, and you can go “back” from them into the folders you were looking at before, too.
I have the exact same issue, also on iPad, using the Apple smart keyboard - it’s happening EVERY time I search from inside a folder.
I tried swiping right from the left edge of the screen but it did nothing (except make the screen greasy - I should really lay off the potato chips).
I am unfortunately not seeing that result with the same configuration. Typically we need very precise instructions to find a bug, since there are so many things that can be done around the basic description of an action that can add variation to the results. Here is what I tried:
- Restarted Scrivener and plugged in the Apple keyboard.
- Loaded the Tutorial.
- Tapped into Draft and then “The Main Interface”, to fulfil the condition of being inside a folder.
- Scrolled down on the binder list.
- Typed in “binder”.
Then what? Does it vanish immediately after typing or do you need to do something else?
I just had this happen to me on my iPhone 6S Plus. I had the phone in landscape mode, searched, and went in to do some extensive work on one of the results files. It was OK as long as I just tapped on the search result and examined a file, but when I started editing and put the edit view into full screen mode, this bug occurred when I displayed the sidebar view again.
And yet I don’t seem to be able to reproduce it at will by repeating those steps without extensively working on a file in between. I added about 500 words, which usually takes me an hour. I can, however, confirm that the intermittent bug does occur even on a large-screen iPhone.
I’ll keep banging on this as I have opportunity, and keep you informed.
I had this happen a couple days ago, and reproduced it reliably on my iPad Pro (12.9”, landscape, external keyboard):
Create new project (local or dropbox).
Create enough documents with similar or identical content to run off the end of the binder in search. (13 or 14 for me on iPad Pro. These can be the same document over and over, duplicated. I had 24 documents with “asdf” as the content, then searched for “asdf”. I can share this project if it would help.)
Search something common to all the files, so the binder is now filled with search results and runs off the bottom. Scroll down. (Search results must exceed full length of the binder.)
Scroll back up. The controls at the top of the binder are gone, can no longer cancel the search or navigate back to binder view.
(Workaround: swipe left on any document in the search, choose options, and reveal in binder. That returns you to a normal view of the binder if you hit this.)
Thanks! I got it I think (whether Keith will see it is another thing!). For me the problem is very simply found by scrolling the search result list a few times, and doing so in a way that causes inertial scrolling to hit the bottom of the result list. I had to flick up and down a few times to see it happen, but eventually I did.
As noted above: a good work around for now is to invoke any action that would “Reveal in Binder”, or in general, cancel the search. This includes:
- The aforementioned swipe on any search result to “Options” and “Reveal in Binder”.
- Tapping in the header bar of the editor (to do the same thing for the viewed file).
Thanks for repeating the workaround and expanding on it. I had missed that.
Thank you, Amber, for the workaround. I hadn’t been able to replicate the problem, but now I can — and also recover from it. Thanks!
FYI, it just occurred to me that this might be new with iOS 11.3. I did a lot of mass character name changes on iOS Scrivener before, and did not run into this problem until I was updating a manuscript on Friday (post iOS update). ISTR the search one before, crashing when out of results, was a timing issue introduced by a new version of iOS. It’s possible this may similarly be exposed by an OS-level change rather than something in the app.
Are there any plans to fix this?
I found the way to solve the problem for anybody else that might be interested. I went to the Project Settings >> Binder and turned all options on. And now the search bar stays all the time I want to search anything in the Binder.
We do think we have a fix for this, yes.
And thanks for the additional tips, Chris!
This is the only workaround that worked for me. Thanks!
This works, but you then can’t view each search result and the list of results without running the search over and over each time you do the workaround to get back to the binder. It’s better than exiting the app, true, but still I think it would be better to have it fixed, nearby nine months after first report.
This doesn’t work for me on iPhone.
I bought Scrivener for iOS a few days ago because I had to take one of my big Scrivener Mac projects on the road. I encountered this bug right away.
Each time I do a search, the search bar disappears after giving the results. Exactly like in the other posts above. It’s a very annoying bug for me considering my workflow, even with the workaround. I understand this bug hasn’t been fixed yet, is there a timeline for its resolution?
It’s on an iPad Pro 10.5" – iOS 12.4
Thanks for your help!
Edit: I just noticed the iOS version hasn’t been updated in over a year… Is this version of Scrivener still supported?
This appears fixed in v. 1.2.