Xinha WYSIWYG fields broken when collapsed on load.
Reported by Aaron Fuleki | December 10th, 2010 @ 01:38 PM | in 2.0.2
Xinha editing windows appear broken (i.e. partially loaded) and inoperable on many browsers, but only if their containing element is collapsed in the UI when the browser first loads the page. The WYSIWYG window becomes operable if you do anything to trigger the UI javascript to reload (e.g., click "Save and Stay", delete some element with the AJAX-y delete button, etc.).
This affects the latest Xinha (currently v0.96.1, as well as v0.95), on all modern browsers, and IE9. Collapsed WYSIWTG elements open up and work fine on IE8. This may mean the issue stems from some IE workaround in bric's AJAX UI code (or it could be coincidental).
Browsers tested that show the issue:
- Safari 5 (Mac/Win)
- Firefox 3.6 (Mac/Win)
- Chrome 7 (Mac/Win)
- IE9 preview 6 (Win)
Unaffected Browsers:
- IE 8 (Win)
Steps to reproduce:
- Open an affected browser.
- Open/Create any story with a WYWSIWYG-enabled element or field.
- Collapse the WYSIWYG element (click the triangle to the left of the container name).
- Save the story with the element collapsed.
- Edit the story again.
- Click the arrow to expand the element.
- Notice that the WYSIWYG appears to load, but looks off (edges missing, the footer runs across the middle, etc.), and you can't click in it to edit anything.
- Do something to force the UI javascript to refresh (click "Save and Stay", delete some other element in the story, etc.).
- Notice that any WYSIWYG elements that were open before the refresh now operate as expected.
Comments and changes to this ticket
-
-
theory November 22nd, 2010 @ 08:06 PM
- Milestone set to “2.0.1”
- Milestone order changed from “10” to “0”
-
phillipadsmith November 22nd, 2010 @ 09:07 PM
Confirmed. And the solution appears to be straightforward (but is beyond my tuits today): http://www.xinha.org/punbb/viewtopic.php?id=2809
-
Aaron Fuleki December 2nd, 2010 @ 09:34 PM
Thanks for finding that!
Instead of bootstrapping Xinha at page load time, I'd recommend the following workaround:
- When the story profile page loads, record the existence and
state of all text areas earmarked for Xinha-fication, somewhere
within bric's UI JavaScript scope.
- Iterate through all of the Xinha-eligible text areas.
- If a given text area is visible, load Xinha within it, and note
that in the state variable.
- If a given text area is not visible, add a click event to its show/hide link, so that Xinha is applied the first time the user opens it (then the event removes itself).
So the three possible states of a Xinha-eligible element are:
- Hidden, never shown, Xinha never loaded (action: load Xinha the
first time the user expands the element).
- Visible, Xinha never loaded (action: load Xinha at page
load/ready time).
- Hidden or visble, Xinha loaded (action: none).
I think this would work better than the suggestions on the Xinha discussion forums (forcing them all to be visible at load time), because it avoids making the page jump around. Also, bric's current UI JavaScript remembers the previous collapsed/expanded state of an element, which we don't want to bork up.
- When the story profile page loads, record the existence and
state of all text areas earmarked for Xinha-fication, somewhere
within bric's UI JavaScript scope.
-
theory December 8th, 2010 @ 11:56 PM
- State changed from “new” to “open”
- Assigned user changed from “Bugs (at bricolage)” to “theory”
This issue is a giant PITA. I wish that Xinha would fix the underlying issue, whatever it is. I'm having a hell of a time making this work.
-
Bugs (at bricolage) December 9th, 2010 @ 03:54 AM
- State changed from “open” to “resolved”
(from [75b2415f32627ae86aa3807c470d04c7c3b43ea4]) Fix Xinha.
Update the JavaScript code to only load the editors when they're made visible.
This is a little fragile, since if we change the structure of the HTML at all,
we'll need to make sure that the Xinha code is updated to take advantage of
the new structure. That is, CSS selectors passed toElement.select()would
need to be updated.Not sure if htmlArea or FCKEditor need to be updated, as well. [#217 state:resolved].
https://github.com/bricoleurs/bricolage/commit/75b2415f32627ae86aa3... -
Bugs (at bricolage) December 9th, 2010 @ 03:54 AM
(from [7d9e377436c7901f292c5b2ff3c9f5ed0a24d359]) Fix Xinha.
Update the JavaScript code to only load the editors when they're made visible.
This is a little fragile, since if we change the structure of the HTML at all,
we'll need to make sure that the Xinha code is updated to take advantage of
the new structure. That is, CSS selectors passed toElement.select()would
need to be updated.Not sure if htmlArea or FCKEditor need to be updated, as well. [#217 state:resolved].
https://github.com/bricoleurs/bricolage/commit/7d9e377436c7901f292c... -
-
theory December 9th, 2010 @ 04:13 AM
FCKeditor and JS-Quicktags continue to work fine, by my quick test. htmlArea is a bit funky, though. Anyone use it?
-
-
Nick Legg March 16th, 2011 @ 07:09 PM
Looks like this is only a partial fix for Xinha in Bricolage 2.0.1. When I add a new element with a WYSIWIG field, Xinha fails to load until I toggle the new element closed and then open again.
-
theory March 16th, 2011 @ 07:54 PM
- State changed from “resolved” to “open”
- Milestone changed from “2.0.1” to “2.0.2”
- Milestone order changed from “19” to “0”
-
Nick Legg March 17th, 2011 @ 12:07 PM
Is it safe to assume that a newly created element will always have the highest element id?
I have attached a (very unclean) patch that boots Xinha on the element with the highest id every time Container.refresh() is called. This is called by addElement(), deleteElement(), and copyElement(). We really only want Xinha to boot on toggle() and addElement() but unfortunately the new element isn't created until after that call completes (the magic is asynchronous). Still testing here, but it's working for us so far.
-
Nick Legg March 17th, 2011 @ 12:40 PM
- no changes were found...
-
Nick Legg March 17th, 2011 @ 12:45 PM
Well, that uncovered another bug with WYSIWYG loading. If you have a WYSIWIG open, then you add or delete any other element, the WYSIWIG (Xinha in particular here) shuts down and does not re-initialize. As such, I re-re-engineered my patch to reboot all WYSIWIGs on Container.refresh().
-
Nick Legg April 28th, 2011 @ 03:51 PM
- Tag changed from “2.0.0, userinterface, wysiwyg, xinha” to “2.0.0, 2.0.1, userinterface, wysiwyg, xinha”
Just an update here.
I now have Xinha working in the following cases:
- Properly loads for already-opened WYSIWYG textareas when entering or refreshing the story profile
- Properly loads when a closed element containing a WYSIWYG textarea is toggled open
- Properly loads when a closed element containing a WYSIWYG textarea is toggled open, then closed, then open again (and so on...)
- Keeps already-loaded WYSIWYGs alive when a new element is created on the story profile
- Keeps already-loaded WYSIWYGs alive when an element is deleted from the story profile
Attached is my current patch up to this point.
There is one remaining bug that I'm aware of. In Safari, Chrome, and Firefox (not in IE, oddly) a WYSIWYG field will crash and lose its content if the element containing it is re-ordered via drag & drop. This only occurs if the moved WYSIWYG had been initialized before the move occured. If an uninitialized WYSYWIG-containing element is moved, then the WYSIWYG will start up properly once the element is toggled open. Any ideas regarding this problem?
Please Sign in or create a free account to add a new ticket.
With your very own profile, you can contribute to projects, track your activity, watch tickets, receive and update tickets through your email and much more.
Create new ticket
Create your profile
Help contribute to this project by taking a few moments to create your personal profile. Create your profile »
People watching this ticket
Aaron Fuleki
Bugs (at bricolage)
Greg Heo
phillipadsmith
theoryAttachments
Tags
Referenced by
-
#217 Xinha WYSIWYG fields broken when collapsed on load.
Not sure if htmlArea or FCKEditor need to be updated, as ...
-
#217 Xinha WYSIWYG fields broken when collapsed on load.
Not sure if htmlArea or FCKEditor need to be updated, as ...
-
#180 Xinha "create link" button does not work in Bric. 2
Related Xinha bug:
http://bricolage.lighthouseapp.com/pr...