Closed Bug 267225 Opened 20 years ago Closed 20 years ago

text in textarea is not displayed until after window.onload

Categories

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

x86
All
defect
Not set
minor

Tracking

()

RESOLVED FIXED

People

(Reporter: miles, Unassigned)

References

()

Details

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.
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 ***
Status: UNCONFIRMED → RESOLVED
Closed: 20 years ago
Resolution: --- → DUPLICATE
"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.
Status: RESOLVED → UNCONFIRMED
Resolution: DUPLICATE → ---
Assignee: firefox → nobody
Status: UNCONFIRMED → NEW
Component: General → Layout: Form Controls
Ever confirmed: true
Product: Firefox → Browser
QA Contact: firefox.general → core.layout.form-controls
Version: unspecified → Trunk
The basic problem is probably that we do the initial reflow before firing onload
but the ensuing invalidates are not processed before onload....
Actually, this may also be due to bug 228557.  The event we post there probably
needs to block onload.
Blocks: 228557
This was "fixed" on aviary by backing out bug 228557, but we still need to
resolve this for trunk...
Flags: blocking1.8b?
OS: Linux → All
Flags: blocking1.8b? → blocking1.8b+
To do that we could use something similar to DummyParserRequest in
nsHTMLContentSink.cpp
If bug 228557 was never checked in on the trunk, then there's no reason to think
that bug caused this regression.
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?)
Blocks: 262760
No longer blocks: 228557
Component: Layout: Form Controls → DOM
Boris, any idea who can help here? 
Flags: blocking1.8b2+
Flags: blocking1.8b-
Flags: blocking1.8b+
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?
Actually, it looks like the patch for bug 281157 will have the side-effect of
"fixing" this (by firing onload async after reflow completes).
Depends on: 281157
I'm going to mark this fixed, by checkin for bug 281157.
Status: NEW → RESOLVED
Closed: 20 years ago20 years ago
Resolution: --- → FIXED
Component: DOM → DOM: Core & HTML
You need to log in before you can comment on or make changes to this bug.