jejacks0n / mercury

Mercury Editor: The Rails WYSIWYG editor that allows embedding full page editing capabilities directly inline.
http://jejacks0n.github.com/mercury
Other
2.63k stars 529 forks source link

Microsoft IE (from Ecosystem Engineering team at Microsoft) #430

Open jejacks0n opened 10 years ago

jejacks0n commented 10 years ago

[developer note] I'm creating this issue here so others can benefit from the conversation, and so it's more understood. There was a brief back and forth, so it's worth making public. It started when I received an email yesterday that contained the following:

I’m a PM with the Ecosystem Engineering team at Microsoft and help communicate compatibility issues as provided by Internet Explorer (IE) test. I came across your email address on Github and wanted to share some information regarding IE and the Mercury Editor tool.

Based on IE testing, it has been reported that we do not support the required parts of the HTML5 spec of the Mercury Editor tool. Please see below for steps to reproduce:

Reference #: 542511 Description of the Problem: Internet Explorer does not support HTML5 content editors within Mercury Editor tool Steps to Reproduce:

  1. Using IE11 desktop, navigate to http://jejacks0n.github.io/mercury/
  2. Click "Check out the Demo" button.
  3. Click in the editable region.
  4. Click "Link" button in top nav to insert a link.

Expected Result: Browser supports the ability to edit content with a rich content editor. Actual Result: An empty popup will appear and stay empty forever, with following error in console:

SCRIPT5007: Unable to get property 'cloneContents' of undefined or null reference File: mercury.min.js, Line: 466, Column: 25786

If you haven’t heard already, Windows 8.1 is here and available to download! Additionally, consumers on Windows 8 can now download the free update through the Windows Store.

Call to Action:

  1. Download Windows 8.1 which includes Internet Explorer 11 through the Windows Store, learn more online at http://windows.microsoft.com/buy or download IE11 for Windows 7
  2. Learn more about Internet Explorer 11, http://msdn.microsoft.com/library/ie/bg182636(v=vs.85) or http://msdn.microsoft.com/library/ie/dn384059(vs.85)
  3. Test your site using Modern.ie - Microsoft’s new tool that will help identify and resolve common compatibility issues. A virtual machine option is available to assist in testing sites with IE11.
  4. While testing, make sure your site isn’t running in Compatibility View or else you may not see the problem

--- Want to back this issue? **[Post a bounty on it!](https://www.bountysource.com/issues/1329626-microsoft-ie-from-ecosystem-engineering-team-at-microsoft?utm_campaign=plugin&utm_content=tracker%2F134071&utm_medium=issues&utm_source=github)** We accept bounties via [Bountysource](https://www.bountysource.com/?utm_campaign=plugin&utm_content=tracker%2F134071&utm_medium=issues&utm_source=github).
jejacks0n commented 10 years ago

Thanks for contacting me, I can provide some feedback. Hopefully this will help clarify my struggle.

It’s always been a hope of mine that the Mercury project would support IE (or IE would support Mercury), however, I find it very difficult to test and develop for IE. To do so my only option is to buy Windows about every year or two, and maintain those setups for previous IE versions. With Chrome, Safari, Firefox, and Opera I have the ability to check it on the system that I run. It’s only with IE that I find this to be a challenge.

It's hard to justify buying a Windows test machine for a free and open source project, that I don’t profit from, just develop and test in IE. I’ve tried installing the VMs that are available for download, but it seems that I still need to purchase a license. Might I make a recommendation that IE, if not compatible with other platforms, should be easy to install and run (reliably) through something like Wine or similar, because I also find it difficult to dedicate several gigs of my hdd for an OS VM that I don’t use outside of testing for one application. I hope that that becomes a priority sometime in the future, as it would ease most of the pain points that I’ve outlined.

I’m not bashing on IE, or Windows, but hopefully explaining why it’s difficult for an open source developer to support the platform helps,

jejacks0n commented 10 years ago

[developer note] I received a follow up shortly there after:

Hi Jeremy – thank you for taking the time to provide the feedback. I apologize that there is no immediate resolution here, however we do strive for the best browser experience for our current and future users and your input is greatly appreciated. In the meantime - you may be aware, but I wanted to make sure you knew about http://www.browserstack.com as well as http://www.modern.ie/en-us.

I will communicate the below to IE and keep you in the loop if there is further investigation applicable to your site.

In the meantime, please feel free to reach out anytime if you have any questions regarding the latest in IE.

jejacks0n commented 10 years ago

There was a little bit of back and forth where I asked if I could put this into github issues so it can be tracked easier. They said that was ok if I didn't put the emails thread in it's entirety, which is understandable.

I think this was a nice thing to get, and I plan to check out browserstack to see if that might help provide an inexpensive (free) and easy way to test for IE. I'll let you know how that goes.

jejacks0n commented 10 years ago

Also, I was tempted to suggest that someone there submit a pull request for the project, but figured that might be less than productive.

tobyoconnell commented 10 years ago

FYI, the cause of this symptom is that IE loses the current selection's ranges when an input is focused in a Mercury action's modal or lightview (e.g. insertLink or insertMedia). This IE behavior is not specific to Mercury. After submitting the modal form, Mercury expects the selection to still have a range (hence the null reference for cloneContents). This behavior does not occur when you can complete an action by only clicking and not focusing an input (e.g. bold, italic).

The workaround is to save the range before focusing on any form input, then restore the range to the selection before executing the action that modifies the contenteditable contents.

Obviously, such a fix will still do nothing to support the older IE versions that have their own selection/range API.