Early Bird Registration for DrupalCon Portland 2024 is open! Register by 23:59 PST on 31 March 2024, to get $100 off your ticket.
If you place the wysiwyg in the same "horizontal tab" (http://drupal.org/project/field_group) as the file field widget or on an edit for without any horizontal tab items it works as designed.
If you place the wysiwyg on Horiz tab 1 and the file widget on horiz tab 2 when you try to insert you get the following error and the action doesnt work:
E is undefined
http://domain.com/sites/all/libraries/ckeditor/ckeditor.js?lrkqe7
Line 95
It seems like the display: none; that horizontal tabs applies to the fieldset makes the wysiwyg unavailable for manipulation? Wontfix is a totally valid answer here but i thought you might have an idea that i hadnt considered for an easy fix. Cheers.
Comments
Comment #1
quicksketchWe previously had the exact same scenario with Vertical Tabs, but we've built support for them directly into the Insert module. See issue #852038: Partly broken if textarea is within a Vertical Tab.
Depending on the popularity of other tab-based modules and on the ease of implementing, we might consider building int support for those too. You're right what the problem is in any case: You can't manipulate a WYSIWYG that is currently within a display: none parent. You have to set the other tab to be active, then insert the changes.
Comment #2
michaelfavia CreditAttribution: michaelfavia commentedThere are about 10,000 fieldgroup module installs and the insert failure is such that people might just think the module doesnt work or they didnt configure it right because very few people know how to read JS consoles, etc.
Is there a generalizable approach maybe that would encapsulate both possibilities? perhaps i can do some research tomorrow. Thx for the response regardless.
Comment #3
quicksketchI'll accept patches for this functionality, but I'm not going to look into this personally.
Comment #4
johnpicozziJust wanted to drop a note of some strange stuff going on with the following...
Insert 7.x-1.3
Field Groups 7.x-1.2
Ckeditor 7.x-1.13 (JS Version 3.6.6)
In Firefox 23.0.1 (worked in chrome) Vertical tabs did not allow me to insert an image when the WYSIWYG editor was enabled (worked fine for a text area) and on a separate tab. If I changed the tab orientation to horizontal everything works fine.
Comment #5
Snater CreditAttribution: Snater commentedBrowsing through D7 issues, while working on the module's D8 version. Although it dates five years back, I can confirm the most recent comment is still valid. Chrome works, but Firefox does not. I tested using CKEditor module 7.x-1.18 with CKEditor version 4.10. Firefox version is 61.0.2.
This was quite an investigation. The error is not caused by Insert module code. Regarding Insert, this is a won't fix.
The error is triggered in CKEditor code:
range is undefined
is triggerd at https://github.com/ckeditor/ckeditor-dev/blob/4.10.0/core/editable.js#L1615I tracked the issue further down to https://github.com/ckeditor/ckeditor-dev/blob/4.10.0/core/selection.js#L..., where
ranges
/cache.ranges
is undefined in Chrome, while in Firefox it is an empty array, which does not seem to be expected at all, ascache.ranges
is supposed to be aCKEDITOR.dom.rangeList
, unless undefined.Debugging is quite tricky as there are quite some anonymous functions, but when adding
|| ranges.length === 0
to the if clause in https://github.com/ckeditor/ckeditor-dev/blob/4.10.0/core/selection.js#L..., code moves to https://github.com/ckeditor/ckeditor-dev/blob/4.10.0/core/selection.js#L..., wheresel
is a Selection object in Chrome, while in FF it is null.That boils further down to https://github.com/ckeditor/ckeditor-dev/blob/4.10.0/core/selection.js#L... Chrome returns a Selection object on calling
getSelection()
on the window object, while FF returns null. The documentation at Mozilla regarding getSelection(), as well as the W3C specification does not mentiongetSelection()
may return null (while it may on the document object as to the W3C specification)So, as far as I am concerned, this is a Firefox implementation error. Quickly scanning through the tickets over there, these ones appears to be the issues, as CKEditor renders in an iframe:
Also note https://bugzilla.mozilla.org/show_bug.cgi?id=585229.
Unless there are any additional comments, I will close this ticket after a couple of days, as it is a won't fix regarding Insert.
Comment #6
Snater CreditAttribution: Snater commentedAs per last comment.