Skip to content
This repository

IOS compatibility #37

Open
Gozala opened this Issue January 11, 2011 · 116 comments
Irakli Gozalishvili

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.
@gissues:{"order":96.27329192546586,"status":"backlog"}

Sergi Mansilla

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

Fabian Jakobs
Owner

could you lookup the patch for us?

Guillaume Laforge

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

Fabian Jakobs
Owner

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

Guillaume Laforge

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

André Fiedler

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

André Fiedler

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)

Brion Vibber
brion commented April 15, 2011

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.

Brion Vibber
brion commented April 15, 2011

(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.)

Dharmesh Malam

any updates on the ipad branch?

Fabian Jakobs
Owner

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

Andrew Heiss

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

Rusty

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

Harry Percival
hjwp commented April 02, 2012

+1

Matthew Dean

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

Bacon

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

velniukas

+1 need this pretty urgently too on iPad

cranic

+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.

velniukas
cranic

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.

cranic

@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.

Harry Percival
hjwp commented April 07, 2012

@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).

André Fiedler

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

Matthew Dean
Matthew Dean

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

Harutyun Amirjanyan
Collaborator

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.
André Fiedler

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: http://davidbcalhoun.com/tag/javascript

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 JS.do.it allow you to embed editors within iframes on other sites, and it's something I'd like to do myself.

Matthew Dean

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

Corin Lawson

@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

Bertolt Meyer

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

cranic

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

Harutyun Amirjanyan
Collaborator

@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

Bertolt Meyer

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.

Corin Lawson

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

Harutyun Amirjanyan
Collaborator

ace never used a canvas, it was bespin

Harutyun Amirjanyan
Collaborator

with 2f6a6ce will not be scrolled out of view.

btw. one more reason to make virtual keyboard

Mike Lawrence

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

Rui Carmo
rcarmo commented May 09, 2012

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
Mike Lawrence

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

velniukas
Bertolt Meyer

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?

velniukas
Jan Jongboom

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

Bertolt Meyer

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

velniukas
Mike Lawrence

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

Irakli Gozalishvili
Gozala commented May 10, 2012

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

Harutyun Amirjanyan
Collaborator

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

can someone who have an ipad test http://c9.io/nightwing/ace/workspace/kitchen-sink.html
it is just improvement to ime but must improve typing on ipad as well

Jan Jongboom

@nightwing Keyboard doesn't popup on iPad.

Irakli Gozalishvili
Gozala commented May 11, 2012

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

Garen Torikian
Collaborator

@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: http://c9.io/gjtorikian/ace/workspace/build/kitchen-sink.html 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.

Ethan Kramer

+1 for iOS Compatibility

muescha
muescha commented May 25, 2012

Please note the januar 15 2011 commit at the @javruben fork, maybe it works?
https://github.com/javruben/ace/commits/master

muescha
muescha commented May 25, 2012

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

jmstanto

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?

velniukas

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.

Colin Johnson

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.

Ruben Daniels
Owner

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.

velniukas
Rusty
Mike Eggleston

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.

Vasilis Georgitzikis

@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!

emeraldspy

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.

Matt

@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:

https://c9.io/site/blog/2012/09/the-ace-editor-hits-v1-0/

and the list of issues referenced in the blog:

https://github.com/ajaxorg/ace/issues?milestone=2&state=open

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 ace.ajax.org) 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 matt@c9.io. And I'm nearly always in #ace on irc.freenode.net. Let's go!

velniukas
Matt

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).

Vasilis Georgitzikis

@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

Matt

@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.

Antonio Villegas

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!

velniukas
Matt

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.

velniukas
Matt

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.

Justin Cooper jwcooper referenced this issue in adafruit/Adafruit-WebIDE October 09, 2012
Closed

Supporting iPad #50

Matt

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!

Shawn A

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

Jan Jongboom janjongboom referenced this issue in ajaxorg/cloud9 November 08, 2012
Closed

Tablet support #2429

Matt

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.

https://c9.io/c9developer/ace/workspace/kitchen-sink.html

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.

Influences

Joe Hewitt explored these same ideas extensively during his scrollability work, as blogged here: http://joehewitt.com/2011/10/05/fast-animation-with-ios-webkit

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 :-)

Future

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~

Garen Torikian
Collaborator

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.)

Lennart Kats
Owner

@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.

Sergi Mansilla

Awesome!!

Matt

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

Lennart Kats
Owner

@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.

Matt

Great! Now I can continue with world domination.

Jeff Barczewski

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?

Matt

Hey Jeff,

Check out the feature/ioscroll branch.

https://github.com/ajaxorg/ace/tree/feature/ioscroll

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

Jeff Barczewski

@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?

Matt

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!

Jeff Barczewski

ok. thanks for the update.

José F. Romaniello

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?

Michael Robinson

@jfromaniello you could use Modernizr

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

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

Joe McCann

Any updated on cursor position? Scrolling looks good.

Mark Murphy

Is anyone still actively working on this?

Garen Torikian
Collaborator

@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"

Jon Ege Ronnenberg

At least we now know how the virtual keypad should look and behave like: http://www.textasticapp.com/

Matthew Dean

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

chetstone

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.

yingfuchen

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.

Francis Irving frabcus referenced this issue in scraperwiki/code-scraper-in-browser-tool August 14, 2013
Open

Tool does not work w/ iPad. #116

Brion Vibber

Downstream bug for Wikipedia's use of Ace to edit template code modules: https://bugzilla.wikimedia.org/show_bug.cgi?id=55345

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

Jake Sankey

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

rdewolff

Any news on this?

Peter Boling

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

Luca Candela

hello guys, is there anybody out there?

Alexey Petrushin

+1 also have problem with editor on ipad

sawyerh

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

Domi

Can't use c9.io because of this bug. Kitchen sink demo won't scroll either (http://ace.c9.io/build/kitchen-sink.html). Happens on ipad and my Android Transformer (which is awesome for light-weight development needs).

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.