BUG: reactie editbox in Konqueror (en preview)

[Soultaker]

1. Sinds de nieuwe lay-out op de front-page is het al zo dat ik in Konqueror mijn reacties niet echt kan editen op de front page. Dat is te zeggen, ik kan ze wel editen, maar als ik op het edit icoon klik is het vak met tekst leeg. Dat is bijzonder irritant want dan moet je dus je hele bericht opnieuw intypen. Copy pasten helpt wat, maar ik wil nog wel eens links en andere ubb-code in mijn post gebruiken, en die moet je dan toch nog opnieuw toevoegen. Even snel een spelfoutje verbeteren doe je dan niet zomaar.

Zijn er plannen om dit nog op te lossen? Voor zover ik weet is Konqueror voor het forum wel gewoon suported, dus het zou wel fijn zijn als dit soort basisfunctionaliteit op de frontpage ook werkt. (Ik heb een tijdje gewacht met rapporteren omdat er bij de introductie van 2.0 genoeg bugs op te lossen waren, en ik hoopte dat dit ook vanzelf meegenomen zou worden, maar dit gaat wel erg lang duren .Werkt het trouwens wel met Safari?)

2. Semi-gerelateerd aan bovenstaande: het zou aardig zijn als de editbox ook een preview-feature had.

[moto-moi]

Voor beiden hebben we Devtrack

[crisp]

Voor zover ik weet werkt de edit-functionaliteit prima in Safari. My best bet is dat we iets doen in javascript dat Konqueror (nog) niet support of we triggeren een bug in Konqueror zelf. Fact is dat Konqueror een niche-browser is en niet door ons gebruikt wordt om zaken te testen. Je bent overigens ook de eerste die dit meldt.

Persoonlijk denk ik dat je ook meer kans maakt om dit gefixed te zien door het te melden en te laten onderzoeken door het KDE team

[Soultaker]

Ik heb eens gedebugt (dat duurde even omdat ik mijn eerdere post niet meer kon editen en geen test-post wilde maken) en het gaat fout omdat jullie tekst in de value-attribute van een textarea stoppen. Konqueror rendert die niet want de tekst in een textarea is niet een attribuut, maar een child element (in HTML is het <textarea>content</textarea> en niet <textarea value="content"/>; het is geen input-element).

Blijkbaar werkt dit in andere browsers wel, maar het is me niet helemaal duidelijk waarop het gebaseerd is dat dit zo zou moeten kunnen. Het lijkt mij eerder een bug in jullie code, tenzij er ergens een spec is die expliciet zegt dat het value-attribuut tenminste vanuit Javascript ook geaccepteert moet worden. Enig idee, crisp?

Ik kan het probleem simpel fixen door in reacties.js in de methode editHere de volgende code:

JavaScript:

this.reactionFormContent.value = reactionRaw;

te vervangen door:

JavaScript:

this.reactionFormContent.appendChild(document.createTextNode(reactionRaw));

(Dit zou ook probleemloos moeten werken in andere browsers.)

Soortgelijke code (met reactionFormContent.value) komt ook nog wel op twee of drie andere plaatsen voor in reacties.js en mogelijk gaat het ook elders op de site fout.

[Victor]

Soultaker schreef op zaterdag 17 november 2007 @ 21:51:
Blijkbaar werkt dit in andere browsers wel, maar het is me niet helemaal duidelijk waarop het gebaseerd is dat dit zo zou moeten kunnen. Het lijkt mij eerder een bug in jullie code, tenzij er ergens een spec is die expliciet zegt dat het value-attribuut tenminste vanuit Javascript ook geaccepteert moet worden. Enig idee, crisp?

De spec die je zoekt is DOM Level 1 (en hoger), waarin het value attribuut voor het textarea element gedefinieerd wordt.

Zie hier de definitie in DOM Level 2: http://www.w3.org/TR/2003...109/html.html#ID-24874179

[ Voor 10% gewijzigd door Victor op 17-11-2007 21:57 ]

[Soultaker]

Ah, mijn fout; Konqueror support die value attribuut ook prima. Het gaat ergens anders mis: de textarea wordt voor het wijzigen van de content uit de DOM-tree gehaald, dan wordt de inhoud ingesteld, en daarna wordt 'ie weer toegevoegd. Bij dat toevoegen reset Konqueror de inhoud naar de initial contents van het element.

Dat is ook te fixen door de assignments een paar regels naar onder te plaatsen. Andere wijzigingen van de content die de textarea niet eerst uit de DOM-tree halen hoeven dus ook niet gewijzigd te worden. (Mijn eerdere fix werkte doordat ik simpelweg de initial contents aanpaste.)

Ik weet niet precies in hoeverre dit gedrag gespecificeerd is, maar toch lijkt het me dat Konqueror hier het goede doet: als een textarea element aan de DOM-tree wordt toegevoegd, wordt er een textarea control geïnstantieerd, die als huidige waarde de tekst onder het textarea-element krijgt. Daarna is de waarde van de control (maar niet de DOM-tree) te wijzigen via het value-attribuut. (Maar als de textarea niet in de DOM-tree zit, heeft 'ie geen control geassocieerd en heeft het value-attribuut geen betekenis.)

Volgende vraag dus: klopt het dat een element pas een control krijgt als 'ie in de DOM-tree komt, of moet er een vaste control gemaakt worden zodra het element aangemaakt wordt?

[ Voor 3% gewijzigd door Soultaker op 17-11-2007 22:09 ]

[crisp]

Thanks voor de analyse Soultaker, daar kunnen we zeker wat mee

Je laatste vraag is een interessante; ik zal zelf ook eens onderzoeken in hoeverre dat gespecificeerd is. Indien het echter niet gespecificeerd is dan denk ik niet dat je zondermeer kan stellen dat Konqueror het goed doet (en dientengevolge dus alle andere browsers het fout doen).

[crisp]

Ik heb nog even wat dingen nagelezen maar kon niets vinden wat je bewering dat wanneer je een form-element tijdelijk uit de DOM haalt dat het daarmee ook geen control meer zou zijn staaft (ook geen bewijs in het tegendeel btw ).

Sowieso lijkt er nogal tegenstrijdigheid te zijn wanneer een form-element nu een control is en wanneer niet, HTML4 scheert het over 1 kam terwijl de DOM specificatie wel een (niet nader gespecificeerde) scheiding lijkt te maken tussen element en control.

Persoonlijk zie ik wel logica in de behaviour van andere browsers wanneer je een form-element (en daarmee de control) uit de DOM trekt en daarbij een reference naar de node terugkrijgt dat die reference niet alleen sec het element omvat, maar ook de huidige (control)state, en dat die state niet gereset zou moeten worden bij het opnieuw invoegen in de DOM. Ik ben ook wel benieuwd wat de behaviour is van konqueror indien je niet eerst expliciet een removeChild zou doen (een appendChild van een node die al bestaat in de tree resulteert in een impliciete removal voor de append).

Ik zal in ieder geval kijken of de 'workaround' eenvoudig in te passen is in onze code

[Soultaker]

Als ik 'm append aan een andere node, dan wordt 'ie ook gereset. Zelfs als ik 'm aan dezelfde parent toeken, maar op een andere plek (ten opzichte van z'n siblings dus) wordt 'ie gereset. Alleen als 'ie op dezelfde plaats blijft staan, blijft de content behouden. Dat is dus niet heel consequent.

Ik was misschien iets te snel met m'n uitspraak dat Konqueror het "goed" doet; het lijkt me redelijker om te stellen dat Konqueror het niet verkeerd doet, als er tenminste niet ergens gespecificeerd is dat het anders moet werken. Dan zou dus ook het gedrag van andere browsers goed zijn, en zou je in je code het browser-afhankelijke gedrag moeten vermijden.

Concreet lijkt me dat je als work-around die assignment aan value gewoon een stuk naar onder kunt schuiven, omdat je toch verder niets met de inhoud doet voordat je de textarea toevoegt aan de DOM-tree. (Desnoods doe je een extra assignment als er ook browsers zijn die graag hebben dat de inhoud van de textarea wordt ingesteld voordat 'ie wordt toegevoegd, maar dat is natuurlijk wat meer een hack.)

edit:
Oh ja, conceptueel lijkt me dat er onderscheid te maken is tussen de inhoud van de DOM-tree (die van/naar bijvoorbeeld XML te serializen is) en de toestand van een webbrowser die die tree rendert. Die DOM specs suggereren dat ook zo'n beetje (een assignment aan value wijzigt immers wel de browser state maar niet de DOM-tree). Zo bezien zou je kunnen zeggen dat als je een DOM-element uit een browser-context haalt, hij ook geen state meer heeft die niet onderdeel is van de DOM-tree. Maar hoe dat precies zit blijft een beetje onduidelijk. Kun je bijvoorbeeld een DOM node uit één tree halen en aan een ander toevoegen?

[ Voor 23% gewijzigd door Soultaker op 18-11-2007 01:04 ]

[crisp]

Kortom: dit reset al de value tot de initial value in Konqueror?

HTML:

<script>

window.onload = function()
{
    var t = document.getElementById('foo');
    t.value = 'woei!';
    document.body.appendChild(t);
}

</script>
<body>
<textarea id="foo">tralala</textarea>

[Soultaker]

Hangt er vanaf wat er na komt. Zo niet:

HTML:

<script>
window.onload = function()
{
  var t = document.getElementById('foo');
  t.value = 'woei!';
  document.body.appendChild(t);
}
</script>
<body><textarea id="foo">tralala</textarea></body>

Want dan is de textarea al de laatste child van body en zou 'ie niet verplaatst worden. (Resultaat is hier dus "woei!".)

Met extra character data op het eind wel:

HTML:

<body><textarea id="foo">tralala</textarea>
</body>

(Resultaat is hier dus "tralala")

Je moet 'm dus echt verplaatsen, anders wordt 'ie niet gereset.

[ Voor 112% gewijzigd door Soultaker op 18-11-2007 01:12 . Reden: Met foo ipv t werkte 't ook om een of andere reden. ]

[crisp]

sorry, zat een bugje in. Probeer het nog eens? (t.value ipv foo.value)

[ Voor 20% gewijzigd door crisp op 18-11-2007 01:10 ]

[crisp]

Soultaker schreef op zondag 18 november 2007 @ 01:05:
[...]

(Resultaat is hier dus "tralala")

Je moet 'm dus echt verplaatsen, anders wordt 'ie niet gereset.

Dat is dus piss-poor want dat impliceert dat er in Konqueror geen manier is om een complete form, of form-elements in de DOM te verplaatsen met behoud van control-state. Dat riekt dan toch echt naar een bug imo...

[Soultaker]

Een hack die daar wel tegen werkt is het formulier of de individuele elementen die je wil verplaatsen in een <div> te wrappen, en die te verplaatsen, want als het element zelf niet verplaatst wordt maar zijn parent wel, dan wordt 'ie ook niet gereset. Dit lijkt niet te kloppen. Volgens mij heb je gelijk: als je DOM-elements met een control eraan verplaatst, dan blijft de state van die control niet behouden. Het is dus altijd alsof je het element verwijderd en opnieuw aanmaakt. (Tenminste, ik generaliseer het nu naar alle controls, maar ik heb alleen maar met textarea getest.)

Het is in ieder geval niet echt consistent, maar in dit geval wel makkelijk omheen te werken i.m.o. Ik zal morgen misschien eens wat KDE-mensen schoppen om te zien of dit by design is.

Wel raar dat dit onder Safari wel werkt, trouwens, want die gebruikt behalve de HTML engine ook de JavaScript engine van KDE; ik zou verwachten dat dit soort dingen daar ook onder vallen. Misschien heeft Apple het zelf gefixt.

[ Voor 54% gewijzigd door Soultaker op 18-11-2007 01:25 ]

[crisp]

Soultaker schreef op zondag 18 november 2007 @ 01:20:
Een hack die daar wel tegen werkt is het formulier of de individuele elementen die je wil verplaatsen in een <div> te wrappen, en die te verplaatsen, want als het element zelf niet verplaatst wordt maar zijn parent wel, dan wordt 'ie ook niet gereset.

Het is inderdaad niet echt consistent.

Dat is dan inderdaad niet consistent, en destemeer een reden dat ik naar een bug neig...

Maar in dit geval wel makkelijk omheen te werken i.m.o.

Dat is waar omdat ik in dit geval sowieso de value overschrijf. Ik heb echter ook andere plekken in de code waar ik bepaalde values wijzig alvorens het formulier te verplaatsen (ik ben dit nu aan het wijzigen, maar dit moet nog getest worden allemaal).

Misschien morgen even de KDE-mensen schoppen om te zien of dit by design is.

Keep me posted, ik ben benieuwd wat ze ervan zullen zeggen

[crisp]

Ik heb ondertussen al wat aanpassingen gedaan in de reactie-js-code, editten zou als het goed is nu ook in Konqueror moeten werken (met dank aan jezelf, zonder jouw tests was ik hier nooit opgekomen)

[ Voor 20% gewijzigd door crisp op 18-11-2007 01:55 ]

[crisp]

Ik heb trouwens even een testcase gemaakt:

HTML:

<script>

function moveForm()
{
    var form = document.getElementById('myForm');
    document.getElementById('foo').appendChild(form);
}

window.onload = function()
{
    var form = document.getElementById('myForm');
    form.elements['text1'].value = 'after script value';
    form.elements['select1'].value = 'after script value';
    form.elements['textarea1'].value = 'after script value';
}

</script>
<body>
<form id="myForm" action="#">
    <input type="text" name="text1" value="initial value">
    <select name="select1">
        <option value="initial value" selected>initial value
        <option value="after script value">after script value
    </select>
    <textarea name="textarea1">initial value</textarea>
</form>
<input type="button" value="move form" onclick="moveForm()">
<div id="foo"></div>
</body>

[Soultaker]

In jouw testcase gaat het opvallend genoeg alleen mis met de textarea (die heeft "initial value" maar de andere form-elementen hebben wel "after script value") dus het lijkt wel een textarea-specifieke bug te zijn.

In de KDE bug database kwam ik deze bug report tegen:
Bug 120607: changing the value of an invisible <textarea> with javascript

Dit is een soortgelijk probleem bij het wijzigen van de value als de textarea weliswaar in de DOM tree zit, maar niet zichtbaar is. In dat geval lijkt het me zeker een bug en de KDE developers beschouwen het ook als zodanig. Er is ook al een patch voor, die ik lokaal heb getest (duurt veel te lang altijd ) en die lost ook ons probleem op, dus dat is mooi.

Wel jammer dat nergens bediscussieerd wordt in hoeverre dit gedrag correct is. Maar aangezien die webstandaarden toch flink ondergespecificeerd zijn is het misschien maar het beste om het op dezelfde manier te doen als de grote browsers, want dat is dan de-facto gewenst gedrag.

Conclusie is dus dat het opgelost is, maar de patch zit in de trunk voor KDE 4.0, dus waarschijnlijk is Konqueror pas gefixt als 4.0 uitkomt (en mensen daar naar upgraden); dat kan nog wel een tijdje duren. De huidige work-around werkt prima, dus laat die voorlopig maar mooi staan.

[ Voor 13% gewijzigd door Soultaker op 18-11-2007 15:53 ]

[crisp]

Soultaker schreef op zondag 18 november 2007 @ 15:45:
[...]
De huidige work-around werkt prima, dus laat die voorlopig maar mooi staan.

In ons geval maakt de volgorde van verplaatsing van het form en de toewijzing van de value aan de textarea niet zoveel uit, dus de huidige 'workaround' kan gewoon blijven wmb