Ich bin ja interessiert an richtigem dem Standard entsprechendem Javascript. Demzufolge bin ich auch Verfechter der Meinung das man in Javascript Ereignisse mit EventHandlern behandelt, die man über element.addEventListener(eventType, eventHandler, bubbling) hinzufügt. Durch diese Methode hat man Zugriff auf die Ereigniseigenschaften und man hat auch die Möglichkeit mehrere EventHandler anzufügen und diese der Reihe nach abzuarbeiten, bzw die weitere Abarbeitung durch Ereignismethoden zu unterbinden. So Zeugs wie element.onEvent = eventHandler; oder sogar onclick="javascript: eventHandler();" lehne ich grundsätzlich ab. Ich halte es einfach für unsauberen Stil, und in der DOM Spezifikation ist so etwas auch nicht enthalten. Der richtige Weg ist es addEventListener zu benutzen.

Jetzt habe ich allerdings über zwei Stunden damit verbracht den FCKeditor in meine Testversion von dWing einzubinden. Ich habe mir also einen EventListener für das submit Ereignis des Formulars registriert um das Formular im Hintergrund per XHR zu übertragen. Hat auch super funktioniert solange bis der FCKeditor nicht eingebaut war. Außerdem wollte ich den speichern Button des FCKeditors benutzen um mich nicht selbst um einen submit Button kümmern zu müssen. Nur leider ging danach nichts mehr.

Ich dachte zuerst der FCKeditor wäre an allem schuld denn er spielt selbst mit dem submit Event umeinander um vor dem Abschicken des Formulars die Eingaben des FCKeditors in eine versteckte textarea zu kopieren. An sich sehr gut. Somit kann ich direkt den Inhalt des textarea verarbeiten ohne direkt auf FCKeditor Methoden zugreifen zu müssen.

Es funktionierte aber nicht. Wie sich aber heraus gestellt hat war nicht der FCKeditor schuld sondern Firefox. Mit einem Klick auf den speichern Button im FCKeditor ruft dieser die form.submit() Methode auf. An sich müsste das ja kein Problem sein. Ein submit Ereignis wird ausgelöst und es erscheint logisch das jeder EventHandler darüber informiert wird. Dank eines Bugs in Mozilla ist dies aber nicht der Fall.

Noch schlimmer ist, dass die Leute bei Mozilla den Fehler gar nicht beseitigen wollen. Gründe dafür sind, dass sie die Abwärtskompatibilität zu 8 Jahre alten Browsern nicht stören wollen und weil jemand der über Script die form.submit() Methode aufruft auch gleich den EventHandler aufrufen könnte. Na wunderbar.

Ich bin mal wieder sehr angepisst das ich über zwei Stunden einem Fehler nachgejagt bin den niemand ausbessern will. Ich hoffe mal dass z.b. die WHAT Arbeitsgruppe etwas dagegen unternimmt und ein einheitliches Verhalten festlegt. Dann sollte dieses Verhalten noch in einem möglichen Acid4 Test überprüft werden und vielleicht kann ich dann in 3 Jahren die ganzen Hacks aus meinem Javascript Code rauslöschen.

So wie es aussieht ist per HTML5 Standard dies das gewünschte Verhalten.

The submit() method, when invoked, must submit the form element from the form element itself.

If the submitter is anything but a form element, then fire a simple event that bubbles, named submit, at form.

Ich habe ein wenig experimentiert und es gibt doch einen recht komplexen Workaround wie man per Script ein Formular abschicken kann, und zwar so dass dabei ein submit Event gefeuert wird.

Man erzeugt einfach ein verstecktes <input type="submit" /> Element, hängt es an das Formular dran und ruft dessen click() Methode auf. Die click Methode wiederum schickt das Formular ab und feuert ein submit Event.

Ich habe auch schnell einen Patch für den FCKeditor geschrieben der diese Methode benutzt. Jetzt gibt es allerdings noch ein Problem mit der Reihenfolge der EventListener. In DOM2 Events ist die Reihenfolge in denen diese Abgearbeitet werden nicht festgelegt. In DOM3 Events schon. Nur ist dies eine FIFO Reihenfolge. Also wenn ich meinen EventListener als erstes hinzufüge wird dieser auch als erstes ausgeführt, noch bevor der EventListener des FCKeditors den Inhalt der textarea verändern kann. Eine Möglichkeit die Reihenfolge selbst anzupassen ist im aktuellen DOM3 Events Entwurf leider nicht enthalten.