Closed Bug 91240 Opened 23 years ago Closed 20 years ago

In view source, XML processing instructions end at the first > instead of at ?>

Categories

(Core :: DOM: HTML Parser, defect)

Product:
Core
Component:
DOM: HTML Parser
Type:
defect
Priority:
Not set
Severity:
normal

Tracking

()

Status:
RESOLVED FIXED

People

(Reporter: WeirdAl, Assigned: mrbkap)

References

Details

(Keywords: testcase)

Attachments

(7 files, 1 obsolete file)

XHTML 1.0 Transitional document (testcase)
806 bytes, text/xml
Details
Screenshot of testcase rendered
30.49 KB, image/gif
Details
Screen-shot of View, Page Source for testcase
13.59 KB, image/gif
Details
Abbreviated testcase (following a hunch)
261 bytes, text/html
Details
abbreviated testcase as text/xml
261 bytes, text/xml
Details
Screen shot of trying to view source XML in phoenix .5
9.22 KB, image/png
Details
patch v2
1.41 KB, patch
rbs
: review+
jst
: superreview+
Details | Diff | Splinter Review 
From Bugzilla Helper:
User-Agent: Mozilla/5.0 (Windows; U; Win95; en-US; rv:0.9.2) Gecko/20010628
BuildID:    Mozilla/5.0 (Windows; U; Win95; en-US; rv:0.9.2) Gecko/20010628

I created a valid XHTML 1.0 Transitional document with a PHP processing
instruction.  The PHP contained HTML tags which it would echo to the client.  I
had my Apache test server off, and PHP was thusly disabled.  The page rendered
as if all the tags except the first one were active XHTML tags, instead of being
inactive as they should have been within the processing instruction.  The
view-source was particularly interesting.  Some other minor glitches as well,
which you will see in the first attachment I post to this bug.

In the attachment, I have changed the <?php ?> to <?test ?>, on the assumption
Bugzilla supports PHP.

Reproducible: Always
Steps to Reproduce:
1.  Make sure any test servers you have for this are OFF.  (Hopefully, Bugzilla
doesn't run PHP.
2.  View the first attachment, changeLog.xml.  (Identical results as changeLog.htm)


Actual Results:  Mozilla renders all XHTML tags except the first within the
processing instruction.

Expected Results:  Mozilla ignores the XHTML tags within the processing instruction.

First attachment:  the testcase
Second attachment:  screenshot of the testcase rendered
Third attachment:  screenshot of the view-source for the testcase.

    
    

    
  
The rendering wfm, win98 mozilla trunk build 2001071604. I believe what you are
seeing is bug 88354, fixed on the trunk 2001-07-04.

View Source, on the other hand, colors the syntax wrong, as shown in screenshot.
 Updating summary to that.
Status: UNCONFIRMED → NEW
Ever confirmed: true
Summary: Moz attempts to render second XHTML tag inside PI → View source doesn't color PI completely

    
    

    
  
heh, bugzilla doesn't do php (yet), sometimes I wish it did though. Anyways, I
think the problem is either multiline <? ?> is not handled properly or <? ?> is
not handled at all but is treated as a normal tag like <test>, so <?test> and
<?test <test> would be considered a tag by view source. Need better testcase.

    
    

    
  
Better testcase (found something more specific)

<?xml version="1.0" ?>
<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Transitional//EN"
"DTD/xhtml1-transitional.dtd">
<html xmlns="http://www.w3.org/1999/xhtml" >
<head><title></title>
</head>
<body>
<p>
<?test
echo "3 > 2";
?>
</p>
</body>
</html>

What the browser should output:


What the browser outputs:
 2"; ?>

If the above isn't a dup, we have two bugs in this report.

    
    

    
  
Something very funny is going on here.  The first testcase, when I looked at it
offline, rendered.  When I looked at the same case from Bugzilla, I got nothing
on the screen at all.

The fourth attachment, though, renders identically from my client and from
Bugzilla.  No idea why.

Another thing I should note for the above testcase:  It shows Moz in violation
of XML 1.0 Second Edition, Section 2.6.  A PI must end with "?>"; Moz is ending
it at ">".  I couldn't make much sense of the fixed bug above, but from the
context it looks like this is a separate issue.

I think the view-source is telling us the browser is ending the PI at the ">",
and the bug may come before it gets to view-source.



    
    

    
  
seeing this on Linux too
OS: Windows 95 → All
Hardware: PC → All

    
    

    
  
See which, the miscoloring or the PI ending at > ???

I don't want to file another bug report or change the summary report on this one
yet without knowing what we're looking at here.  Is the view-source issue coming
from within the view-source routines?  Is the PI bug I've just found a dup or a
new issue?  Are the two related?

    
    

    
  
seeing both, with the "abbreviated" testcase.

View source uses the parser for its syntax highlighting, so an error in the
parser would affect both.

    
    

    
  
If I view the original testcase attachment 42670 [details] from bugzilla (text/xml) it
renders right. The second testcase attachment 42684 [details] (text/html) renders "wrong"
from bugzilla.
Both testcases, saved locally as .xml or .xhtml render right....  saved as .html
render "wrong".

The mimetype (decided by file extension for local files) decides whether the
document is treated
as xml ( http://www.w3.org/TR/REC-xml#sec-pi ), or
as html ( http://www.w3.org/TR/html401/appendix/notes.html#h-B.3.6 )

Messing with the summary again. The rendering is correct, view source is wrong.
Summary: View source doesn't color PI completely → view source should not treat xml files as html

    
    

    
  
Whoops. That's "the original testcase attachment 42668 [details] from bugzilla (text/xml)"
                                                 ^^^^^


    
    

    
  
I'm willing to concede there's a bug in the way view-source shows up, but my
second testcase, 42684, says there's a bug in how Moz handles processing
instructions in the first place.  The rendering is not correct as far as the
processing instruction is concerned.

Times like this, I wish Bugzilla would let us look at a particular file from
multiple mime-types... ;)  something like
bugzilla.mozilla.org/showattachment.cgi?attach_id=42668&mime_type=text/html


    
    

    
  
OK.  Looks like Tuuka is right based on that last testcase.

    
    

    
  
Verified -- ouch.  :)

    
    

    
  
AIUI, PIs end with a single '>' in SGML/HTML, but with "?>" in XML. My fix for
bug 57724 will handle both cases.

*** This bug has been marked as a duplicate of 57724 ***
Status: NEW → RESOLVED
Closed: 23 years ago
Resolution: --- → DUPLICATE

    
  
QA Contact: bsharma → moied

    
    

    
  
Reopening 57724 dependencies for independent resolution.
Status: RESOLVED → REOPENED
Depends on: 57724
Resolution: DUPLICATE → ---
Keywords: testcase

    
    

    
  
--> Clarence
Assignee: harishd → c
Status: REOPENED → NEW

    
    

    
  
*** Bug 179786 has been marked as a duplicate of this bug. ***
Blocks: 84430

    
    

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

    
    

    
  


  
Trying to view www.amazon.com.

    
    

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

    
    

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

    
    

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

    
    

    
  
--> me. I have a patch for this. I'll attach it when I get a chance.
Assignee: c → mrbkap

    
    

    
  

      
      
      
      

        Attached patch
          
          
        patch v1 (obsolete)
        — 
          — Splinter Review
      

    


  
I'm not entirely sure what the scope of this bug is. This patch ensures that
all PIs are actually ended by a ?>. If there are SGML PIs that end with >,
please let me know.

If there are more issues with this, please open new bugs.
Depends on: 226099

    
    

    
  
Comment on attachment 161115 [details] [diff] [review]
patch v1

This ignores HTML PIs (http://w3.org/TR/html4/appendix/notes.html#h-B.3.6).

I'll have a patch sometime later this week that accounts for these (note: this
is a trivial change to this patch).

        Attachment #161115 -
        Attachment is obsolete: true

    
    

    
  
Changing summary to reflect what this bug is actually covering now.
Summary: view source should not treat xml files as html → In view source, XML processing instructions end at the first > instead of at ?>

    
    

    
  

      
      
      
      

        Attached patch
          
          
        patch v2
        — 
          — Splinter Review
      

    


  
This makes us correctly parse processing instructions in both HTML and XML.

    
    

    
  
Comment on attachment 161210 [details] [diff] [review]
patch v2

Since bug 261503 is checked in, asking for reviews on this patch. (note: the
patch may not apply completely cleanly, it may be off by 1 line).

        Attachment #161210 -
        Flags: review?(bzbarsky)

    
  

        Attachment #161210 -
        Flags: review?(bzbarsky) → review?(rbs)

    
    

    
  
Comment on attachment 161210 [details] [diff] [review]
patch v2

r=rbs

        Attachment #161210 -
        Flags: review?(rbs) → review+

    
    

    
  
Comment on attachment 161210 [details] [diff] [review]
patch v2

jst, could you give this sr= and check this in please?

        Attachment #161210 -
        Flags: superreview?(jst)

    
    

    
  
Comment on attachment 161210 [details] [diff] [review]
patch v2

sr=jst

        Attachment #161210 -
        Flags: superreview?(jst) → superreview+

    
    

    
  
bz checked this in, marking FIXED.
Status: NEW → RESOLVED
Closed: 23 years ago → 20 years ago
Resolution: --- → FIXED

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






  

    
  







  

    

      
Attachment

      

      
      
      
      
    

    

      

        

          

            
General

            

              Creator: 



            

            
Created: 

            
Updated: 

            
Size: