Vanishing wysiwyg content in Firefox

(Andrew Harris) #1

A weird one. Just putting it out there to see if anyone else has noticed anything similar.

 

I have an experienced user, who was editing a page in the admin interface (v5.1.4.0) using a recent Firefox (don't know the exact version).

 

They had a div with a lot of content, and needed to split it up, so they created a new div at the top of the page, cut the first section, pasted it into the new div, but when they 'Save Changes', the rest of the content in the first div vanished. The new div is OK, but the original div was saved empty.

 

Fortunately, I was able to dig it out of the system logs and restore the html for the panicked user, but then it happened again. Exactly the same. There was something about this simple cut and paste process which was causing the wysiwyg to empty the container on save. They experienced this on more than one page, on about 4 or 5 occasions, losing work each time.

 

I've tried reproducing the issue in some reliable, repeatable way, but cannot. I've heard anecdotally of at least two other users who experienced a similar issue, but again, quite random and virtually impossible to reproduce. The trouble is, by the time its happened, you've destroyed the evidence!

#2

Actually we had this problem crop up a couple of times but very difficult to replicate. We are running version 4.18.0 though. It usually happened when the WYSIWG containers were saved and one of the containers was still in source view upon saving. This usually resulted in blank content .

(Bart Banda) #3

Never seen or heard about this before. Are you using the classic WYSIWYG? Or the one in Edit+? Also, what version of Firefox and what OS are you using? 

(Andrew Harris) #4

Bart, new WYSIWYG. Can't really help with the version of Firefox (except to say that they're all managed systems, so, fairly recent versions), but all reports so far have been on Windows. I've been unable to reproduce on the Mac.

 

Just wondering though - the old WYSIWYG always had trouble with Firefox, because of the way FF converted html to its own arcane markup before rendering. There were much better, documented cases of disappearing content in that WYSIWYG , but they were usually triggered by a return/enter character, usually at the end of the content. This could easily be backed out of by simply releasing locks instead of saving - annoying, but not catastrophic. My take on this was that the WYSIWYG would attempt to wrap content with a <p> tag, creating an unexpected closure, and removing the content that didn't 'fit' in a valid container.

 

What I think is happening now, is that we still have some sort of internal cleanup of unbalanced tags taking place, either in the WYSIWYG or the browser, only now it happens when the content is saved, which is, of course, a far greater problem.

 

All of this is just a theory which, although it rings true, needs to be tested by someone with intimate knowledge of the WYSIWYG/browser relationship in Firefox. That person is not me ;-)

(Bart Banda) #5

Thanks for the additional input. The new WYSIWYG does clean up both on paste and on save, also does some clean up when viewing source code. So part of the clean up perhaps, if the HTML that has been pasted is not valid, might be removing content for you. 

 

I think the best way to investigate further is that as soon as it happens again, copy and paste the HTML that caused it into here, so that we can try and replicate on our end. There also have been several improvements and bug fixes to that WYSIWYG in the latest couple of releases so perhaps a minor upgrade would be an option to try as well. 

(Andrew Harris) #6

Sounds fair, and I'll pass on the advice, however, in the instance that kicked all this off, it wasn't the content that was pasted into a new div that caused the problem. It was the content that was left over after a 'cut' which vanished. Could have been triggered by the same issue - an invalid leftover fragment of html - but no way to back out of it, or rescue the lost content.