267225 - text in textarea is not displayed until after window.onload

Status: RESOLVED FIXED

(Core :: DOM: Core & HTML, defect)

Description

[Miles Lubin]

User-Agent:       Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.7.3) Gecko/20041028 Firefox/1.0RC1
Build Identifier: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.7.3) Gecko/20041028 Firefox/1.0RC1

When you go to the above webpage, you need to respond the alert before seeing
the contents of the textarea, showing that the textarea isn't filled until after
window.onload. In IE, the textarea is filled before window.onload.

Reproducible: Always
Steps to Reproduce:
1. Go to page
2. Notice the lack of text in the textarea when the alert pops up

Actual Results:  
There is no text in the textarea.

Expected Results:  
There should have been text in the textarea.

Comment 1

[Robin Monks]

Similar to Bug 103928.  I'm duping to that bug.  Reporter, if you feel this was
done in error, please REOPEN.

*** This bug has been marked as a duplicate of 103928 ***

Comment 2

[Boris Zbarsky [:bzbarsky]]

"Duplicate" means "the same", not "similar".  Bug 103928 is about a very
specific issue with XBL.  There is no XBL involved in this testcase.

Reopening, and please do read bugs carefully before duplicating.

Comment 3

[Boris Zbarsky [:bzbarsky]]

The basic problem is probably that we do the initial reflow before firing onload
but the ensuing invalidates are not processed before onload....

Comment 4

[Boris Zbarsky [:bzbarsky]]

Actually, this may also be due to bug 228557.  The event we post there probably
needs to block onload.

Comment 5

[Boris Zbarsky [:bzbarsky]]

This was "fixed" on aviary by backing out bug 228557, but we still need to
resolve this for trunk...

Comment 6

[Jonas Sicking (:sicking) No longer reading bugmail consistently]

To do that we could use something similar to DummyParserRequest in
nsHTMLContentSink.cpp

Comment 7

[Brian Ryner (not reading)]

If bug 228557 was never checked in on the trunk, then there's no reason to think
that bug caused this regression.

Comment 8

[Boris Zbarsky [:bzbarsky]]

Indeed.... On trunk, this broke between 2004-10-08-07 and 2004-10-09-09. 
Checkin list:

http://bonsai.mozilla.org/cvsquery.cgi?treeid=default&module=all&branch=HEAD&branchtype=match&dir=&file=&filetype=match&who=&whotype=match&sortby=Date&hours=2&date=explicit&mindate=2004-10-08+04%3A00%3A00&maxdate=2004-10-09+10%3A00%3A00&cvsroot=%2Fcvsroot

This was broken by bug 262760, looks like.  In particular, I bet
DocumentViewerImpl::InstallNewPresentation posts a paint event with that patch,
since it uses DEFERRED, and then calls Show(), which does the initial reflow,
etc... but the paint is deferred, while the onload handler files as soon as the
dummy layout request is removed from the loadgroup.

Not a form controls issue; the document viewer mess needs to deal with this
somehow (unless we want all invalidate events to block onload in general?)

Comment 9

[Asa Dotzler [:asa]]

Boris, any idea who can help here? 

Comment 10

[Boris Zbarsky [:bzbarsky]]

Not really quite sure.... me, roc, sicking, dbaron, jst could probably all fix
it; the hard part is deciding what the "right" fix is....  For example, should
onload generally block on a pending paint?

Comment 11

[Boris Zbarsky [:bzbarsky]]

Actually, it looks like the patch for bug 281157 will have the side-effect of
"fixing" this (by firing onload async after reflow completes).

Comment 12

[Boris Zbarsky [:bzbarsky]]

I'm going to mark this fixed, by checkin for bug 281157.