27050 - can't set the value field on xul elements unless they are part of the document

Status: RESOLVED WONTFIX

(Core :: XUL, defect, P3)

Description

[Scott MacGregor]

This is related to Bug #26586 which I've checked in a work around for. If you
have a titledbutton that isn't part of a document yet and you set a value on
that titled button, then add it to the document, the value doesn't show up in
the document unless you force a reflow.

If I set the value after the titledbutton has been added to the document then it
works!

I was able to work around this bug by doing this but it introduced at least an
extra reflow in the message pane because we layout with an empty titledbutton
for the email address then the screen flashes as we insert the text for the button.

Comment 1

[Chris Waterson]

I'll take the bug for now, but am skeptical that this is the right thing to do 
(see news://news.mozilla.org/38A0E3AD.EB7882DD%40mozilla.org). cc'ing hyatt, 
vidur, and joki, so we can duke it out.

Comment 2

[Scott MacGregor]

Chris, just so I'm clear, what part are you skeptical about? The solution
proposed in the newsgroup?

Comment 3

[Chris Waterson]

We were arguing about whether or not an event handler should be (re-)compiled 
from its attribute value when an element is inserted into the document.

I claim that (re-)compiling the event handler from its attribute value will be 
just as unpredictable as *not compiling it at all* when an element is created 
via script. (An example of such unpredictability is in the referenced article.)

Furthermore, I argued (on precedent) that the attribute's value *only* matters 
at parse time, and is allowed to become out-of-sync if there is a property that 
can be used to manipulate it. For example, what would the results be here:

  var b = document.createElement('titledbutton');
  b.setAttribute('onload', 'foo();');
  b.onload = bar;
  dump(b.getAttribute('onload'));

Certainly, you wouldn't expect to see 'bar', would you?

AFAIK, the DOM is silent wrt. how this case should be treated. (Adding shaver 
and brendan for their DOM lore...)

Comment 4

[Chris Waterson]

*** Bug 26402 has been marked as a duplicate of this bug. ***

Comment 5

[David Hyatt]

I'll be satisfied if we do nothing on the attribute set under one condition.  We 
should switch people over to addEventListener  Otherwise setting that attribute 
post-document insertion is going to cause a re-resolve of a style context, which 
could get expensive if you have to do it for every item you build dynamically.

Comment 6

[David Hyatt]

iS this bug actually about event handlers?  The title suggests otherwise.

Comment 7

[Chris Waterson]

Hmm. Maybe I did miss the boat here: mscott, I read the original bug report and 
it seems like I'm making a bunch of comments on the wrong thing. :-/

I'll file a separate bug for the event handlers (which, BTW hyatt, I'd argue 
the correct way to do it would be to just use properties; e.g., "button.onclick 
= foo;"). I've opened another bug on Vidur (Bug 26528) to figure out why 
cloneNode() can't copy event handlers. (He's posted to the DOM working group to 
get an anwer on the correct behavior there...)

Comment 8

[Paul MacQuiddy]

*IGNORE* - massive spam changing open XPToolkit bug's QA contact to
[e-mail]

Comment 9

[Chris Waterson]

I think that the resolution here was that properties are not maintained, no 
matter what.