So I’ve got you. This doesn’t make much sense, does it? All except the oldest among you used a newline in your first program. The tough problem is not re-displaying the page as it changes, that’s easy. Okay, maybe not easy, but at least it’s already been solved.
Imagine that you’re typing an email to a lovely lady you want to move here from St. Petersburg. You’ve finished a paragraph about naked scuba diving, you’ve told her about your pet rock collection and now it’s time to add you’re closing line. “Sincerely yours” is a bit too formal, and “With all my love” might scare her off. In any case, if you can’t hit enter to type that line, than she’s never going to move here and marry you.
Well, it can’t be too tough a problem, can it? Olav Kjær wrote a great article about the problems and inconsistencies involved. HTML is a great language for documents (I write software for the web, they make me say that), but its rules for containing text are pretty lax. And when you give a user a mouse and allow him to just click anywhere on the page? That’s just crazy talk!
Why do I care? Well, I was editing a *cough* wiki page on OpenPlans.org using the Firefox 3 Beta (took me awhile to finish off this post, eh?). When I clicked in the middle of the page and hit enter to start typing a new paragraph, half of my page disappeared. Expected results? Uh, a new paragraph? We use Xinha, the open source WYSIWYG editor, and a pretty old version at that, but there was no problem in any other browser, or in previous versions of Firefox.
After filing the bug, I started to search through snapshots of Minefield (the testing and development version of Firefox), and was able to narrow it down to one commit. Looking at the source (in nsRange.cpp), it turns out that the change was a bugfix that caused Firefox to correctly implement the W3C Range standard. Before the fix, trying to create a backwards selection raised an exception, and after the fix it returned an empty selection, as it was supposed to. That meant the Xinha code depended on broken behavior; and that I had work to do.
My first job was to find out what was wrong, That’s easy, I have access to the code, I just have to find out where things went wrong. Eeek. “processRng” and “processSide”. Well, it’s pretty obvious what those two functions do. The first processes a range, and the second processes a side. Thanks to some helpful comments, I know that it returns a neighbor node, and insertion type, and a “roam”. What that means? No idea. My favorite comment?
“I do not profess to understand any of this, simply applying a patch that others say is good — ticket:446”
After stepping through the code I was finally able to figure out what it was trying to do. It divided the document into two pieces. It cuts out everything from the current cursor to the end of the document, inserts a break, and then pastes it back in again. It sounds like a simple enough idea, but I couldn’t for the life of me figure out what was going wrong. So again I did what any self-respecting software engineer would do. I decided to rewrite the algorithm from scratch.
It’s now six months later, and I’ve finally nailed this bug. Of course, other things happened in between, but that’s always the case. Let’s take a look at what’s so tough about newlines.
The first would be a pointer to the “<em>” element with an offset of zero. This would mean we were pointed at the text node. The second would be a pointer to the text node with a zero offset. In this case, we are pointing at the characters of text, and not at a node.
After having finished the majority of this back when I found the bug, I shelved the code and moved on to other things. With the help of my colleague, Nicholas Bergson-Shilcock, I’ve picked this up again and finished it off. This means that the new Phoenix Release (0.96) of Xinha will get a bugfix that makes Firefox 3 usable again.
All of the code for this fix is pluggable, and should be usable by anyone needing to break lines in HTML. The only dependence is on W3C Ranges and DOM Selections. Luckily, there’s been talk of a cross-platform W3C Range and DOM Selection library.
When the guys over at 37signals released their own super-light-weight WYSIWYG editor WysiHat, they talked about wanting to help with the problem. Mozile, the Mozilla Inline Editor, actually has one, but it’s too tied to the editor to be able to useful elsewhere. TinyMCE goes the other way and has an IE TextRange implementation for Firefox, and I’ve recently been told that FCKEditor has the beginnings of a usable library. I’ve implemented the tough parts twice now (finding the DOM node and offset of the ranges start and end points) and learned the best way to do it. For the next release of Xinha (0.97) I hope to bring my work together with the work of all other interested parties and release it as a library. When we do that, users will finally be able to go back and forth between browsers and not have to fight to edit a document.