Skip to content


Subversion checkout URL

You can clone with
Download ZIP


IOS compatibility #37

Gozala opened this Issue · 138 comments

Ace could be a ideal editor on IOS devices (iPad, iPhone) if you just could type, but unfortunately virtual keyboard never shows up with ACE, also I believe someone had a patch for bespin to make that work.


We know, and it will be taken care of soon. Thanks for the suggestion!


could you lookup the patch for us?


I'm also interested in iOS (and particularly iPad) support.
Looking forward to hearing about your progress on that front.


You can checkout the ipad branch. It is not perfect yet but at least typing works. Use two fingers to scroll.


Excellent, I hadn't noticed the ipad branch.
Thanks, I'll have a look at it!


The keyboard didn´t show using the ipad branch. Using the master branch it shows, but there´s a bug with the cursor positioning. :/


Forget what I've said! It's cool that the keyboard didn't show up! You could write your own keyboard, much friendlier for programmers and less space consuming. :o)


Testing on iPad running iOS 4.3; current master fails to show keyboard or insertion point, and doesn't scroll vertically (I can scroll horizontally with two fingers, if the text is wider than the available area).

iPad branch hasn't been updated since February 3... testing it, I see that vertical scrolling works with two fingers (yay!) but is very slow. I can put focus into the editor and pop up the on-screen keyboard, but the insertion point ends up flying off away from the editor when the window scrolls up to fit the keyboard.

Trying to tap around the editor seems problematic; I can sorta tap within the line being edited, but tapping other lines above seems to lose focus and closes the keyboard. I can only reliably put focus at the end of the document.

While scrolling vertically, the insertion point seems to jump up/down a line at a time, but when I start typing, it jumps back to the end of the document to add new chars.


(iPad branch on regular Firefox 4 also has issues -- it seems to make assumptions about the window's scroll position, and clicking in the editor ends up placing the caret at wrong position if I've scrolled the window down to fit the editor in the visible space.)


any updates on the ipad branch?


Unfortunately not. This branch is currently not under active development. We plan to resurrect it but we have no estimated time when.


Sorry to resurrect a dead thread, but has there been any progress on the iOS front?


Obviously, there is massive interest in this. Ill take a look and see if I can help




A web-based component that doesn't support the iPad can no longer be rightfully called a web-based component, IMO.


I second this. I'm writing on an iPad right now, wishing that I were using ACE to be programming instead...


+1 need this pretty urgently too on iPad


+1 to the urgency


I would also like iOS support too, and very soon. If I can find the time, I'd be happy to sit down and do this myself. So if there are any pointers on where I should get started in the code, and details on how it's going wrong, it would be appreciated.


There's no way of bringing that damn keyboard up with javascript, thumbs up for a custom keyboard.


Not true. Assign an element as content editable and them give it focus, and the keyboard should appear. You could also do tricks with textsreas and text inputs to get it working.

The keyboard also comes up with the version of Ace I'm using on my site, it's just not usable.


@PlayMyCode If I can't call someting like ios.showKeyboard() than it's true that I can't bring it up whit javascript, this what you said are all quick fixes...


It just doesn't work like that.

If the content isn't editable, or if it's not a text input, why would the keyboard be displayed? The characters won't go anywhere, you will not receive input from the keyboard.

The keys have to go somewhere for the keyboard to be displayed. If they don't have anywhere to go, then it doesn't appear. If they do have somewhere to go, it will appear. That's not a hack, it's just how text entry works.


@PlayMyCode - characters don't necessarily need a textinput to go to, they could just "go" to javascript -- if you had a set of keypress listeners, you'd be able to get the characters and put them wherever you wanted...


@hjwp your right, but again it's not that simple. I believe the elements must be able to obtain focus, or the browser will not send the event to the element, and many elements cannot receive focus. For example the canvas will only listen to key events if you add a tab index (or at least I am finding this just now in Chrome). iOS also only brings up the keyboard for canvas if you set content editable.

Either was this is an academic argument. iOS support is what is important, and it shouldn't be sidelined simply because a solution looks too much like a hack (unless of course there is a better alternative).


How about putting the focus on an hidden text input and clearing this on keypress?


Wasn't older versions of Ace positioning a textarea or input element under entry, originally? That approach will bring up the keyboard.


Wasn't older versions of Ace positioning a textarea or input element under entry, originally

new versions of ace do the same.
textarea goes out of sync with cursor while scrolling but that's easy to fix
i haven't seen ace on the ipad but on android typing and moving cursor around works, only there's no way select text.
but more importantly

  • ace on android browser is super slow, fennec is a little bit better but still unusable (maybe using setTimeout here with longer interval could help but not sure)
  • default keyboard and autocompletion suggestions are completely useless for programming (so making custom keyboard instead of trying to show default one seems like a good idea). overall i don't think ace can be useful on tablets yet.

custom keyboard sounds nice!


I'm skeptical about a custom keyboard. Building a good, polished keyboard is not trivial, and is worthy of being a large project in its own right. I would also expect a pure HTML keyboard will be slower then the inbuilt one.

It would also need to work well on different screen sizes and different layout orientations. For example I wouldn't want to use the iPad keyboard on the iPhone, and its not nice using the iPhone keyboard on the iPad. They have different keyboards for a reason. Most of all it means everything on the iPad and iPhone uses one keyboard, except Ace. In short, users already have a keyboard they expect, and in many cases it's customized (like setup as a split keyboard).

My recommendation would be to just get the keyboard working, as I'd expect this would be less work then building a custom keyboard. Then worry about building a custom keyboard in the future as a seperate issue. It would also allow you to optionally fall back onto the OS keyboard as an alternative to a custom one, such as if it didn't work well on a particular device.


This site also says you can turn auto complete and auto capitalisation off on particular inputs:


A custom keyboard will also be unable to use the full screen width if Ace is placed within an iframe.

This might sound like a corner case, but both JSFiddle and allow you to embed editors within iframes on other sites, and it's something I'd like to do myself.


@PlayMyCode - Seconded: a custom keyboard would be an extremely bad idea for many of the reasons you mentioned and more.


@PlayMyCode - I agree, custom keyboard sounds perilous. I also suspect that those who have suggested it have little to no experience working with iOS APIs. But I could be wrong, im just going by what @cranic said about ios.showKeyboard(), the native APIs don't have anything equivalent to that... The closest would be calling becomeFirstResponder on a UITextInput control ...but I digress.

This should be entirely doable, probably with little effort. I'm guessing that it's along the lines of giving focus to an element that has contenteditable set. From iOS 5.0, contenteditable is supported, see the very end of Creating Compatible Web Content


There is a JavaScript for editing code inside a browser that fires up a keyboard on iOS: CodeMirror, see e.g. for a demo (works on the iPhone) and for general. So maybe there is something in their code that could help iOS support in ace?


@bertoltmeyer, CodeMirror is based on textareas, that's why it can open the iOS keyboard, ace is a lot more complicated...


@cranic actually Codemirror2 is very similar to ace and uses, which uses the same textareas
if Codemirror2 works on ipad, fixing ace, to work the same way shouldn't be hard


I am writing from the perspective of an R statistician who - like thousands of others - uses RStudio for coding. RStudio is the most popular IDE for R and is built on ace. If ace supported iOS, so would RStudio Server. In this ideal world, I could just access our RStudio Server from my iPad and do all my coding from there. I (and thousands of other R guys) wouldn't have to use my laptop any more. So seriously, ace's lack of support for iOS is the only reason why I am still carrying a laptop around and I am sure that there are loads of other people like me out there. So if I spoke javaScript, which I don't, I would be working on this with top priority. But since I cannot code in js, all I can really say is please please please please can someone try to fix this. Sigh. I (and others) would really support a kickstarter on this issue if necessary.


Hey, I've taken a quick look at the code but all I see is divs; where is the canvas?


ace never used a canvas, it was bespin


with 2f6a6ce will not be scrolled out of view.

btw. one more reason to make virtual keyboard


I echo @bertoltmeyer with regards to enthusiasm for getting ace onto iOS so that RStudio can be used on an iPad.


I'd love to see this working on an iPad as well - it would enable a lot of functionality in downstream applications (I also came here by way of RStudio, but just realized that ACE is in use in a few other web tools I use sporadically, so for me this would solve many different problems).


@velniukas Good idea with kickstarter, I wouldn't be surprised if quite a few folks (like myself) would donate to such a project.


I would also chip in at least 200 USD to a kickstarter project for ace iOS compatibility. I am sure that we would be able to raise quite a bit of money for this from the R community. I am unable to contribute to the coding because I don't speak enough js, but I am willing to help with the fundraising in the R community if someone gets a kickstarter going. @velniukas , would you be able to identify potential collaborators and contact them with regard to setting up such a project?


It's not a matter of money, but it's a matter of having enough dev capacity for this.


I know - but sometimes money can help people to be motivated to free capacities. ;-)


One option would be to post a description of what needs to be done to and solicit bids so we can get a feel for how many devs would be available for this and at what rates.


OMG how I wish I could unsubscribe from updates on this thread...


@Gozala guess you are looking for antenna at the bottom of the page : )

can someone who have an ipad test
it is just improvement to ime but must improve typing on ipad as well


@nightwing Keyboard doesn't popup on iPad.


@nightwing Oh thank you :D You made my day!


@nightwing Perhaps I'll bring this up to @fjakobs when he comes to San Francisco this week. Getting the keyboard to show up on iOS 5 is extremely easy: Just add a contenteditable to the body, boom, done.

Navigation doesn't work, though, which is obviously more difficult. It just sits at {row: 0, column: 0}. I guess it has to do something with the <textarea> that's the first child of ace_editor that seems to act as a sort of cursor.


+1 for iOS Compatibility


Please note the januar 15 2011 commit at the @javruben fork, maybe it works?


@Gozala You can unsubscribe from notifications an the end of this page with the link "disable notifications for this issue"


In reference to previous comments from members of the R community, I installed R-Studio server version 0.96.228 on Ubuntu, and used Wireshark to examine incoming network traffic. I logged into R-Studio server on the iPad successfully using Safari. The keyboard pops up fine now, both in text boxes (e.g., for search) and in the browser pane that contains R-console. The problem comes when hitting Return when typing into the pane that contains the R console: the iPad browser is sending FIN, ACK which causes the R-Studio server application to reset the session. Any idea what causes this?


Any updates on this - I'm in favor of offering a bounty on this feature - if we can find suitable developers who understand the issue.


You can add another name to the list of people who would like to see ACE work with mobile browsers, in particular tablets. That said I'm sure this is not a trivial task. What can those of us who are interested in seeing this happen but who don't have the JavaScript chops to get it done do to help to make this happen? I would willing put money in to a Kickstarter project if it would help.


The last time I worked on this (admittedly year(s?) ago) I tested on the iphone and I got the keyboard to show up. Typing worked, but the cursor was offsetted and I believe inserting a \n would insert two.

There are the following problems to solve:

  1. Keyboard to show up
  2. Any typing interaction needs to be tested
  3. Selection with touch events
  4. For scrolling to be fast a new renderer should be implemented without a virtual viewport
  5. Possibly add a fake keyboard for quicker access to keys used by the language mode (dynamic)

Please comment if you are willing and capable of helping with one of these tasks. I'll see what other resources I can gather.


I am also looking forward to this. Creating an app that requires code editing on the web. This is about the only thing that is preventing me from sending it out into the real world.


@velniukas any updates on this? Looks like there are so many people requesting this feature, and quite a lot of people willing to help. Let's organize and get do it!


This has got to be the number one 'must have' feature. Why? Because without iPad compatibility the credibility of ACE is completely undermined and vunerable to competing projects that can and do offer this level of support. As a company we are already looking at switching. After all this issue was first raised over 2 years ago and has shown no signs of going away.


@emeraldspy I appreciate the dead honesty you're taking with this situation. The reality is: you're right! Mobile support in ACE is a must. In fact, we made a call to the community 2 weeks ago to lend support towards this effort:

and the list of issues referenced in the blog:

Response? Zilch. While we at Cloud9 shepherd the project, we cannot dedicate ourselves to this effort fulltime. We can only make gradual improvements. So what can we do? What would you do in this situation? We hoped that by creating a more open license it would garner more contributions towards mobile support, but this has yet to happen.

We feel ACE is a really special project and we want many more developers in the future to benefit from its exceptional performance and sophisticated feature set. But we cannot force others to simply contribute mobile support. So we have come up with a few ideas that may work:

  • Host a weekend hackathon dedicated to implementing these features
  • Work directly with another company who uses ACE and can dedicate dev resources
  • Rework our promotional materials (like to bring this task to more eyeballs

This project may be suffering from the "bystander effect." That is, there is such a high level of interest in ACE, that someone will assume others will implement the new feature request. The reality is: only a few people contribute. Of course we love those contributions and bug fixes! But those contributions have not added up to end-to-end mobile support. Currently only Android works well.

If all of you who are reading this have ideas, please contribute them here. We do not want this mission to die in a silent "someone else will take care of it" whimper. We are motivated, we just do not have the resources to do this all ourselves. So we need your support!

So let's take some action already! And if you want to e-mail me directly about dedicating your own developers to this effort, then please do: my e-mail is And I'm nearly always in #ace on Let's go!


Thanks Steve! I've added you on Skype. For all those interested in the results of our conversation (and any future conversations we have with others willing to contribute), we will post updates in a public forum (prob GitHub).


@mattpardee please do make sure you will post any updates. On behalf of the codebender team, we were interested in taking part in a hackathon like you suggested in your reply to @emeraldspy

Let's just fucking do this


@tzikis Awesome. We are discussing options with Steve, but a cross-national weekend Google Hangout hackathon sounds like the perfect way to pull this off. We're looking at options. Stay tuned!

update: to be more clear on what we're discussing, Steve has done some research on the performance of mobile support and we're looking at how performant a mobile client can be.

If we do this weekend hackathon I am driven to forge it within the next two weeks while the iron is hot. Ideally we will coordinate with @nightwing and @fjakobs to provide some guidance on best practices. Expect to see more about this soon.


I'm using ACE just as a syntax highlighter of XML files (read-only, no editing).
Everything works fine but the scroll in mobile devices.

Solving this issue should be a start. Scrolling is a big problem in ACE due to the partial render of code lines.
At least everything else is working for me in an iOS device (more or less).
Otherwise you could provide a way to render the whole lines (at least for small to medium files)
and try to the solve the problem.

I'm also open to collaborate in a hackaton. Let's do it!


Hey @velniukas.

We are in the process of nailing down a venue in SF to coordinate the hackathon; we are estimating about 4 weeks from now. I'm putting together guidance materials from @nightwing and @fjakobs and developing a site to promote it. We are pursuing the idea of holding it over a couple days. The first day dedicated to getting as many features covered, and the 2nd to bringing these changes together into one cohesive piece.

So far we have developers from Hong Kong, Amsterdam, Greece, Armenia, and SF interested. So we are promoting this idea as an International Hackathon (perhaps the first of its kind?).

@nightwing has ideas on how we can get a more performant mobile implementation that would be a distinct piece from the way desktop browsers handle the virtual renderer. We will keep everyone apprised of his guidance and nail down a weekend very soon.


Fantastic, Steve! This could turn into a landmark event. Given the time zones I would prefer to start very late Friday, early on Saturday PST and go for 24 hours. The site I'm working on will manage teams to pick specific tasks so no one is duplicating work. If anyone has done this before or has ideas for how this can go best, let me know.

@jwcooper jwcooper referenced this issue in adafruit/Adafruit-WebIDE

Supporting iPad #50


FYI I'm still putting the details of this event together. Cementing dates, getting a venue together, e-mailing prospective teams, and building the website. When I have more interesting information I'll post here. Looking forward to making this happen!


This would be great. Currently I am having to use codemirror for mobile needs. Would love to use ace for all needs.


OK everyone watching this issue. We have a first step in the right direction with iOS scrolling support. Before testing the link below, there are a few orders of operation & caveats to be aware of:

  1. Wait for the entire file to load
  2. After file has loaded, click the "Mobile Mode" checkbox at the very bottom left
  3. Don't change orientation.
  4. Start scrolling
  5. I tested this on iPad v1 and iPhone 5. The iPhone performed brilliantly but iPad 1 was pretty terrible. More on that in a second.

How this was achieved

  • I created a div that overlays the editor with the following CSS:
#scroll_div {
     -webkit-overflow-scrolling: touch;
     overflow-y: scroll;
     pointer-events: none;

Rule 1 is required for the smooth touch-based scrolling, and rule 3 is to allow the overlay to sit on top but not receive any of the events we want to send to the elements below. This leaves open the opportunity to put in accurate typing support in the future.

  • Built a custom inertia algorithm. This is the simplest algorithm I could devise that got "close enough" to what iOS does natively. It simply iterates over an interval of 24msec and decreases the velocity by 94.9% for each interval. The initial velocity is set based on the distance in pixels between the last touch and second-to-last touch (the math of this could probably be improved by incorporating the amount of msecs between the last two touches as well).

  • Whenever the newest position from the interval changes, the touch-scrollable overlay is updated as well. This is so the custom algorithm takes precedence over the iOS algorithm and the divs don't get out of sync.


Joe Hewitt explored these same ideas extensively during his scrollability work, as blogged here:

Why didn't I use scrollability in the first place? Ace depends on a virtual viewport and Joe ended up using webkit animations. The two are not compatible. I have to set the "scrollTop" position of Ace which then has to update the virtual renderer to change the position. I could have hacked in Joe's code to the scrollable div and then applied the results of his 3D transforms to the Ace layer, but eh -- the adventure was more fun :-)


As noted this is just for scrolling. We still need to get accurate typing support in there.

For more modern iOS devices that can handle the speed, this approach works remarkably well. But there are definitely optimizations that can be made. We'll continue exploring options on old and new hardware alike.

Since this is just a demo and not part of the primary Ace codebase, the next step is to put it in the core.

Looking forward to getting your guys' experience on different devices and feedback for how this can be improved. Cheers~


Hey Matt,

Super happy to report this is much more stable on my iPad4 today moreso than yesterday. Nice work! I also tested it on my Samsung Galaxy Nexus running Android 4.2 and it's looking good. (Please don't let's make a solution that's iOS only.) Text insertion also worked flawlessly on Android, while my iPad had a weird double cursor issue (but I could still type.)


@mattpardee That is amazing!

Unfortunately, it seems to completely break Android browser (Android v4.1.1) and Chrome Mobile (v18.0, Nov 2012) support for me. Those browsers had minor issues before, but now I just get a big white div in place of Ace.




@lennartcl what device are you using? And this only happens when you check the Mobile Mode option?


@mattpardee That's on the Galaxy S3, and happened regardless of the mobile option. But I actually tried again today, and now it seems to work as before in both browsers.


Great! Now I can continue with world domination.


I was just trying kitchen sink from master on iOS Simulator with ipad iOS v5 and it doesn't seem to start editing.

When I was hitting the live site kitchen sink with my ipad 3 iOS 5.1 it did edit, but always tries to capitalize the letters. Looks like it is continuously in a select mode with the start and stop blue copy buttons.

Is this latest code in master or should we be looking at a branch or pull request?


Hey Jeff,

Check out the feature/ioscroll branch.

This should at least enable scrolling in the editor (and you don't have to select any options to enable it).


@mattpardee Yes, that enabled scrolling in the iOS simulator, but I could not figure out a way for it to bring up the editor to allow editing. I guess that is still in the works?


Yeah still in the works, although admittedly I don't know if I have the ability to get that working myself. Some of it is related to touch events to invoke focus or blur on the underlying textarea, but the majority of the hard work would be with updating the cursor handler. The distance of the offset of the cursor from its true editing position accumulates towards the end of the line, so there is something basic about the math it's doing.

Hoping someone is up to the challenge!


ok. thanks for the update.


Is there a way at least I can detect if the browser has the min requeriments to run ACE the browser so I can fallback to textarea?


@jfromaniello you could use Modernizr

Modernizr is a JavaScript library that detects HTML5 and CSS3 features in the user’s browser.

@faceleg yes, but what features ACE need.. For instance iOS has a lot of features but the on-screen-keyboard doesnt show.


Any updated on cursor position? Scrolling looks good.


Is anyone still actively working on this?


@MarkMurphy To be honest, I think not. See @mattpardee's comment above for the last state.


Concerning scrolling, what about the other way around?
Like creating div large enough such as height: 10000px; and scoll that inside another, smaller div. It's not perfect, though native scrolling would be much preferred over using extra resources to emulate it. See Dylan blog-post "Making Ace Editor Fill the Available Space"


At least we now know how the virtual keypad should look and behave like:


Just curious: what was the status of this? Is it still an unsolved problem for iOS?


If anyone's motivated to work on this, I have a hint and possible workaround. The problem seems to be that the keyboard doesn't come up when the ace textarea is selected by touch. However it does come up when the textarea is part of a form and it is selected using the "Next" ... "Previous" buttons supplied by iOS. I think...

I noticed this some time ago but have not been able to find the time to verify it. So YMMV.


my page have a select to change the language mode of editor.

when first load the page, the soft keyword won't trigger when I touch the editor,
BUT, after I manually change language from the select, then touch the editor will trigger the keyboard.

hope this will help.


Downstream bug for Wikipedia's use of Ace to edit template code modules:

As a workaround we can blacklist Ace on iOS and use a plain textarea for now.

@jakesankey is using Ace and they have it fully functional on iPad, complete with selections. I may look into this.


Any news on this?


This bug is also breaking Cloud9 IDE on iOS. :+1: for this issue to get some attention!


hello guys, is there anybody out there?


+1 also have problem with editor on ipad


+1 — We're using the Markdown mode for the editor and copy/paste is a big thing that's missing from Ace in iOS.


Can't use because of this bug. Kitchen sink demo won't scroll either ( Happens on ipad and my Android Transformer (which is awesome for light-weight development needs).


For my web app, I used to use CodeMirror. However, I recently switched to ace because of the abundance of modes and features. The lack of mobile support is causing me to reconsider my choice.

Has any progress been made to enable scrolling on mobile devices? It doesn't work on any iOS or android device I've tried.


@mkaminsky11 +1. I'm also deciding between CodeMirror or Ace, and iOS support is the thing holding me back.


As @jakesankey said, uses ace. I tried looking through the code to see how they made it work with mobile devices, but to no avail. Would contacting them and asking for help be a viable solution?


We serve Orion on mobile at Codecademy.


Is it fixed now?


It works just fine on my Asus Transformer, if I "Request Desktop Version". Too bad the browser won't remember those settings though.


Hi, just for reference, I use ace for my project. The virtual keyboard issue is troublesome and I end up with making the editor to be content size. There might be a performance issue.


This is still a Problem, seen on


This issue is also blocking (iPad Air iOS 8), which is a shame because the rest if the editor fully supports the iPad, and overall is quite an insane showcase of what HTML5 can be!


+1. currently investigating a workaround involving manually creating some scroll buttons, to sit next to the editor, using scrollBy


+1 for scrolling problems.


+1 for scrolling problems


+1 for scrolling problems.


+1 for scrolling problems.


Hello guys, I'm not good / patient enough to fix the editor itself, since the whole concept of touch vs. mouse is different. But with the script below, you can get ACE editor to scroll on touch devices (IOS / Android). Just put it into the configuration section of the editor (where the editor is declared, and options are added).


@iq77 What is that code supposed to do? I am trying it and so far it makes no difference? I'm one of the people who really would like this to work normally on touch devices...


@tluyben on "touchstart" it saves the x/y coordinates of the touch event. On "touchmove" calculates the difference between start and end, then passes the x/y values to ACE's "renderer". The renderer does the scrolling. It works on my script, but maybe you have to adapt some class names etc. to your own needs. Also there is some jQuery in there, you might have to replace this.


This is a great thread, but I found it difficult to tell (a) what the nature of the "scrolling issue" is, (b) what devices/OS versions are affected, and (c) what workarounds are available. If someone would be willing to summarize where these are at, that would be superb.

I just tested the Kitchen Sink on [iPad Air 2 running iOS 8 and Safari 8] and [Nexus 10 running Android 5.1 and Chrome 40], and was able to scroll both horizontally and vertically (in landscape; I did not test with devices in portrait orientation). Steps to repro:
1) Browse to
2) Add a bunch of lines (blank lines work fine) in the editor pane until there are more lines than will fit on the screen.
3) If needed, zoom out to view the full browser. (Editing the contents of the editor pane may automatically zoom you in, making it difficult to tell whether you're scrolling the pane or just moving the zoomed-in view around.)
4) Swipe up/down on the very right edge of the editor pane. No scrollbar will appear, but the editor pane contents should scroll as expected.
5) To test hscroll, create a long string of characters that's wider than what will fit on the screen; zoom out if needed; swipe left/right on the very bottom edge of the editor pane. I see a fading scrollbar on Android, but no scrollbar on iOS... but hscrolling works on both, regardless.


I've been searching through the issues and from what I can work out this is the definitive 'everything touch-related' thread. Correct me if I'm wrong and I'll keep digging / file a new issue.

iOS touch is seemingly unable to bring up the context menu in an Ace context (significantly, this allows cut + paste). Normally this can be triggered by tapping the cursor, but Ace overrides this behaviour to move the cursor forward by one character instead.


@barneycarroll, this does seem to be the touch related thread. I've been working recently trying to get at least some touch support implemented for scrolling. Right now, you can scroll if you scroll over just the right area in the far right or bottom of the editor viewspace (where the scroll bars would be). But that's not a viable solution.

I think I'm on to something with getting some touch support implemented, I have it working on the iOS simulator. Check out the fork (, you currently need to build it to compile (as that is the source code), but if you follow the build instructions in the realm, it's cake. I would love some help with any improvements, as it doesn't seem that touch support is a high priority right now (but that's the benefit of open source, we can fix it ourselves). If everything looks good, I'll make a pull request to get it implemented.

@laughinghan laughinghan referenced this issue from a commit in mathquill/mathquill
@laughinghan laughinghan Hide blinking blue cursor in iOS 8, fixes #310
Also fixes #70 :D

+1 for copy/paste in iOS. The problem is the custom cursor handling? What would be a plan of attack to resolve that?

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Something went wrong with that request. Please try again.