search

cjwirth / RichEditorView

RichEditorView is a simple, modular, drop-in UIView subclass for Rich Text Editing.
BSD 3-Clause "New" or "Revised" License
1.9k stars 445 forks source link

Toolbar isn't a proper accessory #6

Closed awderh closed 9 years ago

awderh commented 9 years ago

Since the RichEditorToolbar isn't an accessory view to UIWebView (a really annoying problem; "Hacking Accessory Hiding" reference), the toolbar will overlap onto the editing view.

cjwirth commented 9 years ago

It's a shame that UIWebView doesn't allow to override the inputAccessoryView without some runtime hackery. I could add an even hackier implementation to override the accessory view with more swizzling. The thought has crossed my mind.

I decided to leave it out, because I wanted to give more freedom to the developers to implement it how they want, without having to have a lot of runtime hackery going on under the hood. I am open to the idea of putting it in, though.

If I did put it in, I would still leave the accessoryView as nil by default.

the toolbar will overlap onto the editing view.

I'm not sure what you mean. I don't think adding it as an accessory view would solve this problem. All the accessory view does is attach it seamlessly to the keyboard. I don't think it will account for updating the actual view at all ...?

awderh commented 9 years ago

EDIT: the term last line refers to the bottom-most line one can type on the view, starting from when the content would begin to overflow and require scrolling.

Sorry for the vague comment. I'm using iOS8 on a simulator. Suppose you have a full-screen RichEditor. Now suppose you're writing on the last line but without the on-screen keyboard. When you open up the keyboard (Mac + K) you'll see that you cannot see the last line (and will not be able to at all, even if you scroll) because of the toolbar being drawn on top of it. The only way to effectively type would be to always write on the second last line (whose position is right before the toolbar).

What I did was that I added a padding-bottom css entry (44px for non-retina, and 66px or 88px for retina devices) to the HTML contentEditable div. This way the last line would be pushed up.

If the toolbar was set as an accessory view, then the keyboard would take this into account and would scroll or push - I'm not sure how the view resizes when the keyboard shows up - so that the last line isn't hid behind the toolbar.

cjwirth commented 9 years ago

Yeah, it's true that when you have an actual input accessory view, it considers it part of the keyboard when it is doing it's calculations and things. If you just have it as a subview, I don't think it does this though. When you say fullscreen, is the view property of one of your UIViewControllers returning the RichEditorView?

Anyway, I made a little bit of an 'experimental' branch, feature/input-accessory-view that you can try out.

It doesn't involve as much hackery as I was expecting (roughly the same amount as before, just changing it to return a UIView instead of nil.

Let me know if this does what you're hoping it would.

awderh commented 9 years ago

I'm looking at your edits and it seem like it will do exactly what I think would fix the error.

Thanks, i'll confirm and get back to you. Perhaps you should merge it?

cjwirth commented 9 years ago

I'll merge it once I've confirmed it solves your problems.

I've already seen it display the toolbar correctly, but in my project, it didn't do anything with showing/hiding the last line of text.

awderh commented 9 years ago

Works perfectly; I no longer have to pad the bottom of the HTML body. :) The toolbar now shows up even if the keyboard is disabled, which is exactly what an input accessory should behave like. This branch is a great success :+1:

I have a seperate question though. If the RichEditor works perfectly on my iOS simulator, is there a reason why it would crash on an iOS device? It does this for some reason, but I don't even get a crash log from iTunesConnect. Any ideas?

cjwirth commented 9 years ago

I can't think of anything off the top of my head... We've had it in the App Store since May or June with no problems.

I just ran this new branch on an iPhone 6+, iOS 8.0, and it seemed to work OK. If you can debug it on the device through Xcode, does it tell you anything?

cjwirth commented 9 years ago

Since this will be an API breaking release, I will put this into the 2.0.0 release when Swift 2.0 gets officially released.

cjwirth commented 9 years ago

Took care of this in 2.0.0 :smile: