Steps: 1. Apply the attached patch which adds a constructor to the <resizer> which does: this.style.MozTransform = "scaleX(-1)"; 2. Open a page that has a resizable textarea, such as this bug The browser hangs, apparently reflowing and reconstructing the binding repeatedly. Some notes: 1. Just using a <resizer> directly in a xul document does not cause a problem and the resizer is rendered horizontally reversed as expected. 2. Setting the MozTransform using a timeout does work but applies the transform to the entire textarea instead of just the resizer. The latter makes me think it has something to do with the resizer being in native anonymous content.

> 1. Apply the attached patch which adds a constructor to the <resizer> which > does: this.style.MozTransform = "scaleX(-1)"; Changes to MozTransform require a frame reconstruct. We do not support frame reconstructs on roots of native anonymous subtrees (because the frame constructor would have no idea how to reconstruct it correctly, for one thing!). Depending on the setup, such a reconstruct would either reframe the parent of the anon content (though I wouldn't expect it to hang unless something else weird is going on) or might just make the anon content disappear if we change some things about frame construction. But the fundamental upshot is that you can't reframe native anonymous content. Why do you need to set MozTransform in the constructor, exactly?

ccing Timothy, since he has a patch that would somewhat change the reframing behavior here. What you're doing would still be unsupported, though.

The reason we hang is actually because PresShell::HandlePostedReflowCallbacks ends up flushing because the scrollframe asks it to, which processes the restyle, which recreates the entire scrollframe (due to our attempt to reframe the parent of the anon content), and then we reflow that scrollframe, which lands in HandlePostedReflowCallbacks, etc. I really want to make the flush HandlePostedReflowCallbacks does async if possible... it it possible?

I need some means of supporting rtl resizers which apply when direction: rtl is in effect. I came across this bug while trying out a possible implementation. Note that I didn't originally set the transform explicitly in the constructor. Instead, I set an attribute which causes a css rule to match that sets the transform. Perhaps you could suggest another means of achieving the desired effect?

> but applies the transform to the entire textarea instead of just the resizer I can't reproduce this, with this constructor: var x = this; setTimeout(function() { x.style.MozTransform = "scaleX(-1)" }, 0); though I get lots of: ###!!! ASSERTION: Unexpected document: 'capturingContent->GetCurrentDoc() == GetDocument()', file ../../../mozilla/layout/base/nsPresShell.cpp, line 6037 Bug 558663 is the bug that might change behavior here.

> Perhaps you could suggest another means of achieving the desired effect? Under what conditions do you need to apply the transform? Does it depend on the computed style of the <textarea>, basically?

(In reply to comment #6) > Under what conditions do you need to apply the transform? Does it depend on > the computed style of the <textarea>, basically? Yes. Would it work if I just set an attribute on the resizer in CreateAnonymousContent when direction: rtl was set on the textarea and then used a style rule as follows: resizer[rtl] { -moz-transform: scaleX(-1); }

It would work if you also changed the restyle hint for the direction property from reflow to frame reconstruct. I think that should be safe enough; dynamic direction changes ought to be rare.

(In reply to comment #3) > I really want to make the flush HandlePostedReflowCallbacks does async if > possible... it it possible? That would mean we could be in a state where we've scrolled down further than the current content's layout actually requires/allows. That would probably trigger assertions, but maybe there would be no real badness as far as scrolling as concerned. Of course the other users of reflow callbacks would have to be audited.

Can web content trigger this bug?

No, since it can't style native anonymous content.

(In reply to comment #8) > I think that should be safe enough; dynamic direction changes ought to be rare. That's not really true. See bug 581536 which shows up on Google Translate. I guess we'll see more of this type of dynamic direction changes in the future as well.

> That's not really true. Maybe I should be clearer about what I meant by "rare". I don't mean "doesn't happen on many pages". I mean "doesn't happen many times in quick succession on many different unrelated elements, so taking a bit more time to handle it should not be a problem". If you think that they won't be rare by that definition, then we need a different idea here, yes.

(In reply to comment #13) > Maybe I should be clearer about what I meant by "rare". I don't mean "doesn't > happen on many pages". I mean "doesn't happen many times in quick succession > on many different unrelated elements, so taking a bit more time to handle it > should not be a problem". If you think that they won't be rare by that > definition, then we need a different idea here, yes. I think this is OK at least for now, but we probably need to keep an eye open for problems when we implement direction: auto.

I agree with them being rare under the definition of comment 13. But dynamic direction changes to dir=auto for example would be a problem if we try to reconstruct all the frames in the document, for example. Although I'm not sure how frequent (meaning, on how many pages) such a dynamic change would occur.