Closed Bug 81546 Opened 23 years ago Closed 22 years ago

XHTML form documents fail to appear intially in browser window

Categories

(Core :: XML, defect, P2)

Product:
Core
Component:
XML
Type:
defect

Tracking

()

Status:
RESOLVED FIXED
Milestone:
mozilla1.1beta

People

(Reporter: chrispetersen, Assigned: hjtoi-bugzilla)

References

(
URL
)

Details

(4 keywords, Whiteboard: [workaround on 1.0 branch 5/17][real fix on trunk 2002-07-17])

Attachments

(8 files)

reduced test case
245 bytes, text/xml
Details
stack showing event getting unwedged
8.97 KB, text/plain
Details
stack: extra dummy reflow request added to loadgroup
9.23 KB, text/plain
Details
stack: HTML dummy reflow request added (note diferent stack)
4.10 KB, text/plain
Details
patch: Don't add dummy reflow request if we are in the middle of a reflow
597 bytes, patch
Details | Diff | Splinter Review
XHTML testcase - textarea
1.80 KB, text/xml
Details
another XHTML testcase - input/tabindex
2.03 KB, text/xml
Details
Fix: Add flush to EndLoad
553 bytes, patch
harishd
: review+
jst
: superreview+
scc
: approval+
Details | Diff | Splinter Review 
Build: 2001051704
Platform: All
Expected Results: Textarea, input xhtml documents should load properly in the 
browser without additional user interaction.

What I got: After typing url path and pressing returning, the throbber continues 
to cycle but no test case is displayed.


Steps to reproduce:

1) Type in any of the following url's in N6:

http://slip/projects/marvin/xhtml/transitional/input_onblur.xml
http://slip/projects/marvin/xhtml/transitional/input_onselect.xml
http://slip/projects/marvin/xhtml/transitional/input_onfocus.xml
http://slip/projects/marvin/xhtml/transitional/input_tabindex.xml
http://slip/projects/marvin/xhtml/transitional/input_type_hidden.xml
http://slip/projects/marvin/xhtml/transitional/textarea.xml
http://slip/projects/marvin/xhtml/transitional/textarea_onchange.xml
http://slip/projects/marvin/xhtml/transitional/textarea_onfocus.xml
http://slip/projects/marvin/xhtml/transitional/textarea_disabled.xml
http://slip/projects/marvin/xhtml/transitional/textarea_onblur.xml

2) The throbber will cycle and not displayed the test case content


3) The user must place focus in the url field and press return multiple times to 
cause page to reflowed. The page should be properly displayed.

4) This appears to xhtml/xml only since identical HTML files render without this 
problem.
Adding xhtml keyword
Keywords: xhtml
Huh! Bad. Is this a regression?
Severity: normal → major
Yes, the last time ran all of my XHTML tests (April 25th build) I wasn't having
this problem. This is isn't happening to all of my xhtml test just about 22 or so.
I believe hyatt changed when we paint quite recently. Maybe that caused this
regression. Could be necko changes as well, I guess. Cc:in hyatt first.
Doubt this is mine.  As long as the onload handler fires, I'll unsuppress 
painting.  You can verify by putting a breakpoint in DocumentViewer's 
LoadComplete method.

I see this bug in the Windows nightly build 2001-05-10-09. So now the time
period when this regressed seems to be 04-25 to 05-10.
I'm still able to reproduce using the files specified in the latest Win32 branch
build (20010606).
Priority: -- → P2
Target Milestone: --- → mozilla0.9.3
Eric, any ideas why form elements would cause these problems in XHTML?
Target Milestone: mozilla0.9.3 → mozilla0.9.4
Dave, it seems your assertion is correct - as soon as we fire onload, the
document paints.  The problem is, we don't fire the onload unless some outside
action happens (I was able to get it to happen by having multiple windows open,
switch focus to another, and then return focus to this window.)

Also, it does not seem to matter if there is a form in the document, just as
long as there is an input of some kind, the bug is reproducible.  For example,
in this testcase, the alert won't pop up until I give focus to another window,
then return it to this document:

<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Transitional//EN"
  "http://www.w3.org/TR/xhtml1/DTD/xhtml1-transitional.dtd">
<html xmlns="http://www.w3.org/1999/xhtml">
 <body onload="alert('foo\n');">
   <input value="1" />
 </body>
</html>
(FWIW, the value="1" seems significant, if I remove it, the testcase works fine)
Status: NEW → ASSIGNED
Attached file reduced test case — 

    
    

    
  
Forgot to also confirm: in addition to the alert not popping up,
DocumentViewerImpl::LoadComplete() is also not hit until focus is switched...

(Heikki, sorry for marking this ASSIGNED, I thought it was assigned to me!  ;)  )
Status: ASSIGNED → NEW

    
    

    
  
When loading an XHTML file with a text control in it (<input type=text/password>
or <textarea>), we get an extra dummy reflow request added to our loadgroup *and
not removed* (it is added, then later removed in the HTML case).  If there is no
text control, we don't get the dummy request, so that's why we're not seeing
this with every XHTML page.

Looking in to why it is not removed for XHTML but is for HTML...

    
    

    
  
CC'ing Nisheeth and Rick - can you look at the patch I'm going to attach?  The
purpose of the patch is to just block this dummy reflow request generated by the
nsGfxTextControlFrame2::SetTextControlFrameState() from going through.

I can't tell if it's a hack, or the right thing to do: I'm relying on the fact
that the PresShell is in the middle of a reflow here, but doesn't seem to be in
other cases where we *do* want the DummyReflowRequest added...

    
    

    
  
pollmann intended to CC: Nisheeth and Rick (Potts?). Please check his comments
above.

    
    

    
  
I believe waterson was working or at least reviewing some stuff lately that had
to do with dummy reflows etc. Chris, what is your opinion on pollmann's findings?

    
    

    
  
Yeah, your last patch looks right. r=waterson. cc'ing attinasi.

    
    

    
  
I think the patch (43623) is right too. I recently made a similar change to
ensure that we do not remove the dummy reflow request if in the midst of a
reflow, and it seems that adding one is equally ill-advised. [s]r=attinasi

BTW: is it the case that the dummy reflow request that was being added was never
getting removed because there were no subsequent reflow commands from the
document load?

    
    

    
  
Eric, you fixed this so you deserve the glory ;)
Assignee: heikki → pollmann
Priority: P2 → --
Target Milestone: mozilla0.9.4 → ---

    
    

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

    
    

    
  
> is it the case that the dummy reflow request that was being added was never
> getting removed because there were no subsequent reflow commands from the
> document load?

Yes, this is the case.  The dummy reflow request is being added by the document
inside the nsGfxTextControlFrame2, which happens in the final reflow of the
containing document.

Thanks for the r=/sr= - I'll check this in tonight!


    
    

    
  
Fix checked in.  To verify, view the attachment marked "reduced test case" 
above.  The page should display immediately after clicking on the link with no 
further user action required.  Thanks!
Status: NEW → RESOLVED
Closed: 23 years ago
Resolution: --- → FIXED

    
    

    
  
Marking verified in the Aug 6th branch builds
Status: RESOLVED → VERIFIED

    
    

    
  
Tested this using 02_25_22_0.9.4ec mfcembed build. This bug was fixed on the
trunk back in 8/2001 but and worked on the original 0.9.4 branch build. However,
it is now a regression. Open up any of the XHTML urls found below - the document
will not render unless you reload after first loading. This behavior happens
with XHTML and XML documents. This is a regression in 0.9.4 branch builds.

    
    

    
  
nominating for EDT - page does not display unless reloaded
Keywords: edt0.9.4

    
  
URL: http://slip/projects/marvin/xhtml/tra...
QA Contact: petersen → chrisd

    
    

    
  
I suspect this is the same as bug 113884. Reopening and taking.
Status: VERIFIED → REOPENED
Keywords: nsbeta1
Priority: -- → P2
Resolution: FIXED → ---
Target Milestone: --- → mozilla1.0

    
    

    
  
Taking.
Assignee: pollmann → heikki
Status: REOPENED → NEW

    
    

    
  
The regression were found on the branch however it seems there may be a problem
on the trunk as well. I am attaching two testcases because the ones shown below
are on a local server.

    
    

    
  
Testing on 2/15 trunk build with the two attached testcases, now it's not even
working when you try to reload.

    
  
QA Contact: chrisd → petersen

    
    

    
  
minusing for 094. Comment as appropriate
Keywords: edt0.9.4 → edt0.9.4-

    
    

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

    
    

    
  
Right-click and some other actions cause the page to paint. The problem is
either the same old problem with dummy reflows, or HTML is doing more flushes
with form controls (for example Boris Zbarsky noticed in the dupe that adding
flush to XML doc's EndLoad seems to fix this).
Status: NEW → ASSIGNED
Keywords: nsbeta1 → nsbeta1+

    
  
Keywords: topembed+

    
    

    
  


  
It does not appear that the dummy reflow situation has changed, so something
else is causing this (something new).

Like Boris Zbarsky noticed, adding FlushPendingNotifications() to EndLoad fixes
this. I propose we'll fix it like that for now. In HTML, we call that function
several times, for example from nsHTMLDocument::ResolveName() which gets called
2 times before EndLoad() and 2 times after EndLoad(). The stack for those calls
involves XBL or XUL which to me seems kind of weird, but...
Whiteboard: [fixinhand]

    
    

    
  
Comment on attachment 71687 [details] [diff] [review]
Fix: Add flush to EndLoad

r=harishd

        Attachment #71687 -
        Flags: review+

    
    

    
  
Comment on attachment 71687 [details] [diff] [review]
Fix: Add flush to EndLoad

Hmm, this smells kinda bad. This is just a workaround for the problem, doesn't
seem like a real fix. But I'm fine with that for now. We should either leave
this bug open or open a new bug to track the removal of this and getting a real
fix for the problem.

sr=jst

        Attachment #71687 -
        Flags: superreview+

    
    

    
  
ADT3 per ADT triage.
Whiteboard: [fixinhand] → [fixinhand][ADT3]

    
    

    
  
This issue is affecting the mfcembed March 28 build. The mentioned test cases
refuse to load in the browser.

    
    

    
  
This is perhaps the most glaring XHTML bug we have right now. This makes
practical XHTML totally unusable. I really don't want to check in the workaround
if I can help it.

Chris, anyone: could we pinpoint when this happened?

John, I understand you have been working with forms lately so maybe you would
have some ideas about this...
Keywords: helpwanted, 
          
            mozilla1.0, 
          
            qawanted
Whiteboard: [fixinhand][ADT3] → [have workaround][ADT3]

    
    

    
  
I will start looking at when this regressed. I known this hasn't worked properly
for several months now.

    
    

    
  
This problem is happening on the oldest trunk build I can find. OS X
(2001-11-19-08) and Windows ME (2001-11-22-03). With these builds, simply
reloading the page will display the content. In the latest Windows trunk
(2002-04-15-06) , reloading doesn't repaint window. Instead, I must right-click
mouse in order for content to appear.
Keywords: qawanted
Whiteboard: [have workaround][ADT3] → [have workaround][ADT2]

    
    

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

    
    

    
  
Asking ADT approval for BRANCH ONLY for the workaround. I want to leave this open
for the trunk for a better fix, which is probably going to be more involved.
Please note that I changed the impact to ADT2 since this makes practical XHTML
documents impossible.
Keywords: adt1.0.0

    
  
Keywords: topembed+

    
  
Keywords: topembed+

    
    

    
  
Hi,

I think not this will help to find the bug, however, it enabled me to use xhtml
forms with that bug (without the user noticing it): I just begin every xml page
which contains a form with this line

<div><img src="nasty_workaround_for_bug_81546" alt=" " /></div>

The fact that the image does not exist appears to trigger some repaint thus the
page is displayed correctly on initial load.

regards
-- jochen

    
    

    
  
adt2 rtm, adt1.0.0- -- let's get this in for RTM, but not for beta.
Keywords: adt1.0.0 → adt1.0.0-
Whiteboard: [have workaround][ADT2] → [have workaround][ADT2 rtm]

    
    

    
  
Comment on attachment 71687 [details] [diff] [review]
Fix: Add flush to EndLoad

a=scc for checkin to the mozilla 1.0 branch; but (in accordance with jst's and
others' comments, please don't let this work-around stall the search for the
real fix)

        Attachment #71687 -
        Flags: approval+

    
    

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

    
    

    
  
FWIW, I can get *one* (whatever I try first) XHTML document with a form to load
per session.

    
    

    
  
Heikki,

What's kind of strange is that I not able to reproduce this problem under Mac OS
9.1 (2002-05-16-05 1.0.0). All of XML textarea test cases load flawlessly. This
is not the case under OS X , Linux Redhat , and Windows ME builds.

    
    

    
  
adding adt1.0.0+.  Please checkin to the 1.0 branch after getting drivers approval.
Keywords: adt1.0.0 → adt1.0.0+

    
    

    
  
Comment on attachment 71687 [details] [diff] [review]
Fix: Add flush to EndLoad

a=chofmann,brendan
please check in to 1.0 branch asap to get this in rc3.

    
    

    
  
Checked in the workaround on the 1.0 branch.
Keywords: adt1.0.0+ → fixed1.0.0
Whiteboard: [have workaround][ADT2 rtm] → [ADT2 rtm][workaround on 1.0 branch 5/17]

    
    

    
  
Verified on the following branch builds:

OS X (2002-05-19-05 1.0.0)
Windows ME (2002-05-19-09 1.0.0)
Linux RedHat 6.2 (2002-05-20-09 1.0.0) 





    
    

    
  
Adding verified1.0.0 keyword since problem has been resolved on branch builds.
Keywords: verified1.0.0
Keywords: nsbeta1+
Whiteboard: [ADT2 rtm][workaround on 1.0 branch 5/17] → [workaround on 1.0 branch 5/17]
Target Milestone: mozilla1.0 → mozilla1.1alpha
Target Milestone: mozilla1.1alpha → mozilla1.2alpha

    
    

    
  
Now that the real fix has been pushed away to 1.2alpha, could the workaround,
please, be checked into the trunk for the time being? This bug causes major loss
of functionality to those of us who use trunk builds and want to do things with
XHTML as well.

    
    

    
  
The work-around doesn't work well. Some people have shown me pages that still
exhibit this bug with m1.0.

    
    

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

    
    

    
  
This bug remains a major blow for the XHTML cause. It seems there is still a
missing link in the logic re:dummy request, for the bug seems to go away when I
set the pref:
pref("layout.reflow.async.duringDocLoad", false);

Whiteboard: [workaround on 1.0 branch 5/17] → [workaround on 1.0 branch 5/17] [but workaound isn't always reliable]

    
    

    
  
From what I could gathered: the fact that the XML/XHTML content sink isn't
incremental is where the difference lies (bug 18333).

In the HTML case, a dummy request gets added because reflow requests come into
being during the construction of the content model (as seen in attachment 43616 [details]).

In the XHTML/XML case, a full reflow kicks off only after the content model is
already built (as seen in attachment 43614 [details] with StartLayout & InitialReflow
kicking off), and the dummy request is not created because PresShell::mReflowing
is true from there on.

Summary: there is no dummy layout request that comes into being in XHTML/XML.
Since the layout of XHTML/XML isn't asynchronous in the first place, the missing
dummy layout request has had no apparent impact. Only edge cases, such as this
bug, are left to suffer.

[The ealier pref causes a code similar to the workaround to be executed in
PresShell::DidCauseReflow()]

    
    

    
  
There is a patch on bug 156985 that fixes this bug and may even be right...
Depends on: 156985

    
    

    
  
Nope, the bug is still lurking...

Here are URLs to explore the bug. 

=================
Vanilla testcase:
=================
http://perseus.risc.uni-linz.ac.at:8080/openmath/integration.html

The page uses a <frameset>, and all links load to the content <frame>. The 
interesting thing to note here is that the "MathML output" is an XHTML page with 
a <form>, and furthermore the page uses a XSLT stylesheet. View-source of the 
page here:
view-source:http://perseus.risc.uni-linz.ac.at:8080/openmath/mmlintegral.jsp

[The other links ("WSDL" and "OpenMath output") use HTML pages. They are of no 
particular interest here, except perhaps to note that they work fine.]

     Actual Results
     --------------
     Clicking on "MathML output" shows nothing, but instead it turns the content
     area into a zombie page in all Mozilla builds (m1.0, m1.1trunk).

     Expected Results
     ----------------
     The page should display fine.


========================================
Testcase with workaround of comment #48:
========================================
http://perseus.risc.uni-linz.ac.at:8080/openmath/integrate.html

This is a copy of the vanilla testcase, with the bogus 
<div><img src="not-found"> per the work-around indicated in comment #48.
View-source of the page and scroll to the bottom to see the hack:
view-source:http://perseus.risc.uni-linz.ac.at:8080/openmath/mmlint.jsp


Additional Notes
================
The page with the above work-around shows up in m1.0 & N7PR1 (be sure to use 
different profiles when doing such dual testings...). But it doesn't show up in 
m1.1trunk.

    
    

    
  
Marking FIXED...

It has turned out that the remaining issue is related to XSLT. When I remove the 
processing instruction that invokes the XSLT stylesheet, the page renders fine.
Status: ASSIGNED → RESOLVED
Closed: 23 years ago → 22 years ago
Resolution: --- → FIXED
Whiteboard: [workaround on 1.0 branch 5/17] [but workaound isn't always reliable] → [workaround on 1.0 branch 5/17][real fix on trunk 2002-07-17]
Target Milestone: mozilla1.2alpha → mozilla1.1beta

    
    

    
  
The follow-up bug that is related to the XSLT stylesheet has been filed as
bug 158457 - Transformation of Universal MathML Stylesheet doesn't complete

    
  
QA Contact: petersen → rakeshmishra

          You need to log in
          before you can comment on or make changes to this bug.
        






  

    
  







  

    

      
Attachment

      

      
      
      
      
    

    

      

        

          

            
General

            

              Creator: 



            

            
Created: 

            
Updated: 

            
Size: