WYSIWYG on mobile devices.

I've been working on a similar issue today for a client. The newer versions of TinyMCE won't attempt to load on iOS devices, which helps. The one thing that creates a problem though is that wysiwyg_form_alter disables the teaser js always. I did a simple hack, setting a global for 'disable_wysiwyg' and setting it for true. I put a check for this at the top of wysiwyg_form_alter and if it is set to true, the function just returns. Perhaps this would be a solution that would allow the mobile modules to hook in.

Another benefit of this method is that the TinyMCE js isn't loaded in at all. That's a big benefit given the slower networks a lot of mobile devices reside on.

The first and foremost question is what the actual goal is. Is it to entirely disable any client-side editor, or is it to dynamically fall back to an editor that "should" work on mobile devices? In turn, which editors work on mobile devices? Can we detect mobile devices on the server-side, or does all of this need to happen on the client-side? Should editors pre-define on which kind of user agents and devices they work, or should this be manually configured through Wysiwyg's administrative UI?

As far as I've seen, no editor that relies on an element in design mode work in any mobile browser. They're simply not detected as editable fields. So, "WYSIWYG" editors which aren't actually WYSIWYG tend to work better as they'll let you enter text using the original textarea, but inserting snippets like <strong></strong> around a selection might not work because they don't execute the scripts on the client.

Just remembered we have these issues as well:
#743702: Disable on certain browsers
#651382: iPhone support?

Pretty much WYSIWYG can be turned off for all mobile devices.

What a more optimal solution would be is to include code in WYSIWYG, as well as the regular HTML editors like BUEditor so that modules can switch enable/disable the different editors. That would open up an API for a new "mobile_editor" module (or even in the existing mobile module) that can detect the user agent string and disable WYSIWYG and (if installed) enable something like BUEditor.

That'd be really complex to pull off. We couldn't possibly avaluate programatically how the mobile editor should be configured to replace another editor. An admin would have to configure one replacement/mobile profile for each regular profile.

Something like it might be easier to do when we have support for multiple profiles per input format. if the admin could indicate which profile is a mobile fallback.

Please also understand that Wysiwyg module *is* the arbitrator module itself. The author of BUeditor merely chose to provide no sane way to use BUeditor as a stand-alone editor library, which complicates the already existing effort to make Wysiwyg module also support BUeditor in #429684: Add editor: BUEditor -- everyone who wants support for that editor should contribute over there. For this discussion, it would be wise to replace the term "BUeditor" with "markItUp", or even better: "pseudo editors".

What I'm trying to say: No module needs to be enabled or disabled in any way for this to work. But we need to discuss the technical requirements and also the desired functionality and ideal behavior to make any progress.

I've tried to outline some of the most obvious questions and challenges in #2. Would love to hear some actual ideas and feedback on those.

I've played around with a few different WYSIWYG editors on different mobile devices and can't find anything that works. Having found that, it would be best to totally disable full WYSIWYG for any mobile devices.

I would say we do this on the server side. WYSIWYG JS libraries are typically pretty big and given the slower nature of mobile networks, having those files download unnecessarily would be a waste of bandwidth and time. Perhaps this could be done by using the browsercap module?

It would be nice to have a standard HTML editor that could be loaded in through WYSIWYG as a replacement for mobile devices. I'm thinking along the lines of WP, where they have the 'code' view tab with the helper buttons on top. Honestly this could be a nice feature overall for WYSIWYG, having a way to tab between the rich editor and a basic code editor, complete with helper buttons. That really would be another issue though (ie: #429684).

Perhaps an intermediary solution would be to do a module_exists('browsercap') and then offer a new setting on which user agents to disable WYSIWYG on?

@intoxination: So you're saying that not even pseudo editors like markItUp or BUeditor worked in your mobile device tests? Which mobile device(s) did you test (and, which browsers)?

I've tested iPhone and Blackberry (hopefully will have a droid to test on this weekend). I also didn't try markItUp. Here's what I got:

iPhone - Rich editors don't work (TinyMCE doesn't even render, but that's due to detection for iOS in TinyMCE preventing it). BUEditor works fine.
Blackberry - No rich editor or BUEditor. Just plain textarea.
Blackberry (Opera Mini) - No rich editor (TinyMCE renders but not editable). BUEditor renders but onclick button bindings don't take.

From what I can tell doing late even bindings is what breaks in BUEditor. For example, the regular markup editor in WP works fine in both Opera Mini and the BB default browser. Those buttons don't do any late bindings though.

If we want an actual markup/html editor, we might have to develop one more geared towards mobile devices that actually adds the buttons in hardcode, with onclick, instead of letting JS render them. Something like that could be built as a separate project that hooks in with WYSIWYG. Just spinning off the top of my head there.

Though not a test I would consider 100%, I did just try TinyMCE in the Android 2.2 SDK emulator and it works fine. So does BUEditor. I'm hoping to have access to a droid this weekend to really test it on and will let everyone know.

Thanks! That's a start. I'd like to see more actual test data/facts, before drawing any conclusions.

Based on those BUeditor results, testing markItUp would be very interesting. Functionality-wise, it's basically the same, but markItUp is much more bullet-proof, and especially also used outside of the Drupal world - in short, a nice little rock solid jQuery-based pseudo editor. Thus, before drawing the conclusion that pseudo editors fail equally, we need to test the available.

we might have to develop one more geared towards mobile devices

The absolute last thing this world needs is yet another editor library. All of the existing are plain duplication and a major waste of developer time. In a sane world, Wysiwyg module wouldn't have to exist at all.

MarkItUp works on Android and iPhone. It acts the same as BUEditor in BB Opera. On the standard BB browser is doesn't render at all.

I just tested on a Android running v2.2.

- Markitup works fine
- BUEditor works fine
- TinyMCE renders, but on the touch screen models there's no way to get the keyboard up.

So it's looking more and more like we need to disable WYSIWYG on anything mobile.

bump

it would be nice to have an option to disable wysiwyg at all on mobile devices.

I can confirm that TinyMCE 3.3.8 with wysiwyg is disabled on iPhone, virtual keyboard is shown, but not for androids, there is no virtual keyboard shown when i click into textarea

If we fall back to not providing a WYSIWYG editor on mobile devices, could we specify a fallback input format? E.g. one that uses line breaks? What I'd prefer to do is specify input filter by the user platform detected by the server. Then I could say "for iOS or Android, use input format A, for all others, use input format B," where A is a format that retains line breaks, or someday uses BUEdit or BBcode or whatever, and B is TinyMCE. Alternatively, I could let my users pick a "preferred" editor from those I choose to supply.

emdalton, good idea, it would be nice to have an option to choose default input filter if wysiwyg is disabled (for mobile phones)

Just as another data point, iOS5 handles WYSIWYG-enabled textareas quite well, if they use ContentEditable (CKEditor and TinyMCE do). I haven't tested with Android ICS or anything beyond 2.3.7, but I'm guessing/hoping that this problem will be less of a problem as time goes on and the editors and phone OSes are updated to work better together.

I just got ICS on my phone and hadn't noticed that, thanks!

This may be a dumb question, but can WYSIWYG use something like the browscap module to identify the client platform and select a different editor (such as markdown) or none at all for the client browser? This might be helpful for older devices.

We can't at this point. Firstly because there is only one editor per format, and the editor is picked on the server side where we have no if-this-browser-then-do-that-code in place. Just disabling the editor would be easier to accomplish first, but I personally have no experience with the browsercap module so I can't say if the API we'd need to have to identify mobile browsers exists.
Support for multiple profiles per format could get things closer to a if-this-browser-then-that-editor-solution, but I can't promise anything.

Here is a patch to use WYSIWYG with Mobile Detect. For now it sets parameters to "hide editor, show toggle link" for all editors on mobile devices. Tested with old Android and Opera Mini.

This is currently failing. I'm needing this though and CKEditor 4.x is not working so I'll give this a go tomorrow. Will reroll the patch if needed too.

I have rewritten the patch to the latest wysiwyg version. The general wysiwyg form has been removed so the Disable on Mobile setting is now a setting within each profile.

+1 , using this in the media_dev distribution