No wysiwyg editor visible on Safari iPad

[grogy]

trafficstars

Expected behavior.

I assume I'll get the Froala editor on my iPad like I do on Safari for iPhone

Actual behavior.

Now it doesn't show up at all on the iPad (latest version). The edit box is active.

Steps to reproduce the problem.

• open in Safari for iPad URL https://froala.com/wysiwyg-editor/examples/color-themes/

Editor version.

4.1.0

OS.

iPadOS 16

Browser.

Safari - last for iPad

[Lightras]

Same here in my iPad's Safari. I can only see a placeholder text, but no toolbar or any other Froala's UI.

Tried in iPadOS 14.8 and 16.6. Froala version 4.1.1.

[DemyGlassix]

Also doesn't work on iPads for me. The "initialized" event is not called at all, no reaction on any input.

Desktop logs: Froala editor: null Froala model: null Froala config: {…} froalaEditor.initialized: v.Bootstrap {id: 2, opts: {…}, sid: 2, shared: {…}, $: ƒ, …} true Froala editor: v.Bootstrap {id: 2, opts: {…}, sid: 2, shared: {…}, $: ƒ, …} Froala model: "" Froala config: {…}

iPad logs: Froala editor: null Froala model: null Froala config: {…} Froala editor: null Froala model: null Froala config: {…}

[waleedfarraj]

yes same here , "froala-editor": "^4.1.1", on ipad's safari i can only see placeholder's text .

[adrianbinzaru]

Same here, iPad pro, latest ios and safari. Please fix ASAP

[AVargas89]

Same here on my iPad. Please fix asap.

[Krisell]

How is it possible that this bug has no response? We just found out about this, and could easily reproduce on the Froala web site. The error is missing error handling for a (possibly faulty) regexp. There's an X missing, but please don't just add that, instead write more robust code with error handling. Unexpected input (like a UserAgent) should not be able to cause a complete crash.

[Krisell]

Additional information that may be helpful. Some versions of iPadOS uses a Mac UserAgent (like the one in the image above) and not the previous iOS/iPad User Agent (like the one your regexp assumes). Your code seems to check for touchscreen first, and then uses this regexp to incorrectly determine OS version (also note that the UserAgent OS version is usually 10_15_7 even for recent versions for backwards compatibility reasons).

I'm guessing your version detection solves a bug. A minimal fix on your end is to verify a match before grabbing index 0 [0] of the result, alternatively using a try ... catch ....

We have reverted to 4.0.18 which doesn't have this check.

[adrianbinzaru]

Hey @Krisell , thanks for the tip , I'll try reverting to 4.0.18 as well for now. I contacted Froala support last week and they said they're not looking into this. They advised me to sign up to their newsletter to be notified if they ever release a fix for it... wtf

[Krisell]

I contacted Froala support and received an answer that they are working on a fix, and that it will be included in the next release.

[uvesten]

Can add a +1, we also noticed the regexp failure on iPad. Have also tested on iPadOS 17.0 Known broken froala versions: 4.1.0, 4.1.1, 4.1.2. Known good version: 4.0.19 (Also does not have the check, seems it got added in the 4.1.x branch)

[chrisdeeming]

I miss the days when this editor used to be good. Can't wait to move away, honestly.

Issues used to be fixed very quickly, even commented on by the main developer at the time. Really went downhill when Idera took over.

You never know from one version to the next what will work and what will break, and the commitment to quality seems to have really dropped off.

[ilyaskarim]

Thank you all for reporting this issue and We apologize for the inconvenience caused due to this bug. This will be fixed in next editor version 4.1.3. Improving our QA processes to prevent such cross-browser regressions going forward. We appreciate you taking the time to provide the details to help us improve Froala Editor.

[uvesten]

@ilyaskarim any ETA on the 4.1.3 release?

[shan-du]

The issue on iPad happens when the Desktop Mode is ON for Safari (e.g. Settings => Safari => Request Desktop Mode)

The navigator.userAgent value reported are diff when toggling desktop mode ON/OFF

Desktop Mode ON	Desktop Mode OFF
"Mozilla/5.0 (Macintosh; Intel Mac OS X 10_15_7) AppleWebKit/605.1.15 (KHTML, like Gecko) Version/16.4 Safari/605.1.15"	"Mozilla/5.0 (iPad; CPU OS 16_4 like Mac OS X) AppleWebKit/605.1.15 (KHTML, like Gecko) Version/16.4 Mobile/15E148 Safari/604.1"

and in this Froala JS file, getIOSVersion function, the following line of code, which is triggered for iOS, would fail for Desktop Mode because the regex match would return null

navigator.userAgent.match(/OS (\d)?\d_\d(_\d)?/i)[0] // null pointer error

The string match & parsing logic needs to be updated to consider this case because I believe all the 12.9" iPads have Safari Desktop Mode turned ON by default

[shan-du]

Hey @ilyaskarim

Not sure if the fix for this had been made or not, but if not, hopefully the comment above can help you guys identify/address the issue faster

Also same Q as above, is there any ETA on 4.1.3 release? We are getting a lot of exceptions coming in on this issue from iPad users

[uvesten]

@ilyaskarim this is a very specific issue, it is critical (the editor does not work on iPad at all), the cause is known AND there is no workaround except for downgrading to 4.0.19. Couldn’t you issue a patch release for this issue, instead of letting everyone wait for the regular 4.1.3 release, which is more than a month coming now?

[chrisdeeming]

Apparently fixed in 4.1.3.

If anyone has any comments about whether this issue is fixed and generally whether any new issues have been introduced or other outstanding bugs that might be problematic that would be appreciated