Opened 13 years ago

Closed 13 years ago

Last modified 12 years ago

#2066 closed defect (wontfix)

Getting Contents from Editor2 Widget Corrupted in Safari

Reported by: bradneuberg Owned by: alex
Priority: blocker Milestone:
Component: Editor Version: 0.4.1
Keywords: safari editor2 editor moxie Cc:
Blocked By: Blocking:

Description

The Editor2 widget is broken on Safari; this is a regression since it used to work in Dojo release 0.3.1, and broke around Dojo 0.4. When working with the Editor2 widget on Safari, if the user types text into the widget and then you programmatically get its value, such as:

var richTextControl = dojo.widget.byId("storageValue"); var value = richTextControl.getEditorContent(); alert(value);

'value' will be corrupted most of the time.

I have simplified this bug into a test case that I am attaching to this bug. The test case has two files: safari_bug.html and safari_bug.js. Drop these into your root folder where dojo.js is located in a checkout of the 0.4.1 branch, then navigate to safari_bug.html. Instructions are located on that page on how to reproduce the bug.

This bug is critical because it affects Moxie, the demo application for Dojo Storage on Safari. Moving to Editor versus Editor2 does not fix the bug, since it happens there as well. Without fixing this bug Dojo Storage's test app is not as compelling, since it doesn't work on Safari, which is one of the three major platforms supported by Dojo Storage.

I think this bug might only happen in newer versions of Safari; I am not sure. Here are my platforms details:

MacBook? Pro x86 - Mac OS X 10.4.8 - 2.16 GHz Intel Core Duo - Safari 2.0.4 (419.3)

Attachments (2)

safari_bug.js (712 bytes) - added by bradneuberg 13 years ago.
Simplified Test Case that Shows This Bug
safari_bug.html (1.7 KB) - added by bradneuberg 13 years ago.
Simplified Test Case that Shows This Bug

Download all attachments as: .zip

Change History (15)

Changed 13 years ago by bradneuberg

Attachment: safari_bug.js added

Simplified Test Case that Shows This Bug

Changed 13 years ago by bradneuberg

Attachment: safari_bug.html added

Simplified Test Case that Shows This Bug

comment:1 Changed 13 years ago by bradneuberg

Summary: Getting Value from Editor2 Widget Corrupted in SafariGetting Contents from Editor2 Widget Corrupted in Safari

comment:2 Changed 13 years ago by alex

Owner: changed from liucougar to alex
Status: newassigned

comment:3 Changed 13 years ago by alex

Resolution: wontfix
Status: assignedclosed

Adding:

height="300px"

seems to make the issue go a way. There's something very strange going on with DOM node ordering in general but it doesn't show up in the webkit nightlies (which I've got a patch to fix), but I haven't been able to debug the ordering/focus issues.

Hopefully a fixed-height workaround will be workable for you =

I'm gonna mark "wontfix" for 0.4.1, but I think we can reopen for 0.5.0 if you think it's necessaray.

comment:4 Changed 13 years ago by alex

(In [6772]) use contentEditable in more places that can handle it. Opera 9.01 added support and the webkit nightlies can handle it (thereby unbreaking them, yay!). Still am not a fan of the mandatory iframe thing.

Refs #2066

comment:5 Changed 13 years ago by bradneuberg

I'm confused; is this a valid workaround for external users of Editor2, or an internal fix? If it is an external workaround, I don't understand how to apply it.

comment:6 Changed 13 years ago by bradneuberg

Resolution: wontfix
Status: closedreopened

Just tested against 0.4.1 branch on Dec 2nd @ 3:46 PM, and still get this bug in Safari. Reopening. If there is a valid workaround for external users of this API it should be described more clearly.

comment:7 Changed 13 years ago by alex

It's an external workaround. It seems that Safari has weird focus issues around the difference between the HTML element and the body element. It seems that when you click inside the words, caret focus is placed in the document.body element, but when you delete from the end of the line and then add new stuff, you caret is in the <html> element. I know, it's really f'd up. Webkit nightlies aren't broken this way (and AFAICT, neither is any other browser). I'm looking for workarounds now.

comment:8 Changed 13 years ago by alex

wow, check *this* out:

	<BODY>
		Click Here to B
		<DIV><BR class="khtml-block-placeholder"></DIV>
		<DIV><BR class="khtml-block-placeholder"></DIV>
		<DIV><BR class="khtml-block-placeholder"></DIV>
		<DIV><BR class="khtml-block-placeholder"></DIV>
		<DIV><BR class="khtml-block-placeholder"></DIV>
		<DIV><BR class="khtml-block-placeholder"></DIV>
		<DIV><BR class="khtml-block-placeholder"></DIV>
		<DIV><BR class="khtml-block-placeholder"></DIV>
		<DIV><BR class="khtml-block-placeholder"></DIV>
		<DIV><BR class="khtml-block-placeholder"></DIV>
		<DIV><BR class="khtml-block-placeholder"></DIV>
		<DIV>egin Edi</DIV>
	</BODY>
	<DIV><BR class="khtml-block-placeholder"></DIV>
	<DIV><BR class="khtml-block-placeholder"></DIV>
	<DIV><BR class="khtml-block-placeholder"></DIV>
	<DIV><BR class="khtml-block-placeholder"></DIV>
	<DIV><BR class="khtml-block-placeholder"></DIV>
	<DIV><BR class="khtml-block-placeholder"></DIV>
	<DIV>thinger and stuff</DIV>

That's the DOM structure from the broken environment. Wowsa.

comment:9 Changed 13 years ago by alex

Resolution: wontfix
Status: reopenedclosed

Brad,

This is instractable. Between the broken selection API on safari and the performance implications of adding keystroke event handlers on that browser, it's not possible to fix this internally.

I've spent DAYS on this, working up several partial patches that address some initial selection issues but they can't address other scenarios that can crop up due to text entry and manipulation. Given the market share of safari and the fact that a fix will not be necessaray on the next version, combined with the external workaround, I have to close this as wontfix.

Regards

comment:10 Changed 13 years ago by alex

(In [6792]) commented out attempt to fix a nasty selection issue on Safari. Sadly, Safari 2's range object is thoroughly fsck'd and there are huge performance problems with attaching event handlers to keystrokes on that platform. Damned if you do, damned if you don't. Refs #2066

comment:11 Changed 13 years ago by bradneuberg

Hi Alex, thanks for spending so much time on this. An external work around is fine; can you explain a bit more about what you mean by putting height="300px" on an element? What element do I attach that to? The div that will host the Editor2 control?

comment:12 Changed 13 years ago by bradneuberg

Just opened a bug for 0.4.1 to track needing to apply this external workaround to Moxie's use of Editor2: http://trac.dojotoolkit.org/ticket/2091 . I'll apply this tomorrow (Tuesday, Dec 5, 2006).

comment:13 Changed 12 years ago by (none)

Milestone: 0.4.1

Milestone 0.4.1 deleted

Note: See TracTickets for help on using tickets.