Closed Bug 69840 Opened 24 years ago Closed 20 years ago

document.createProcessingInstruction for XHTML not implemented

Categories

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

Product:
Core
Component:
DOM: Core & HTML
Type:
defect

Tracking

()

Status:
RESOLVED FIXED
Milestone:
mozilla1.7beta

People

(Reporter: mhearn, Assigned: bzbarsky)

Details

(Keywords: dom2)

Attachments

(2 files, 2 obsolete files)

Useful testcase
305 bytes, application/xhtml+xml
Details
Patch
10.52 KB, patch
jst
: review+
jst
: superreview+
Details | Diff | Splinter Review 
Hi, basically I need this command for an app I am writing with Mozilla. Please
can it be implemented, I doubt it's hard :)

thanks -mike
Creating processing instructions does work in XML document, are you trying to
create processing instructions in HTML? (that should not work so I wouldn't
count on that being implemented any time soon). Or did you try this in XUL?
Please give more details.
need a test case...
Keywords: dom2
Component: DOM Level 2 → DOM HTML
I was trying it in XUL and got the error "Method not implemented" so I assumed
it had been futured or something. Am I wrong?
Attached patch Proposed fix (obsolete) — — Splinter Review 

    
    

    
  
I just attached a fix for this, good ol' cut n' paste style fix for now :-).
r/sr= anyone?
Status: UNCONFIRMED → ASSIGNED
Ever confirmed: true
OS: other → All
Priority: -- → P3
Hardware: PC → All
Whiteboard: [HAVE FIX]
Target Milestone: --- → mozilla0.9

    
    

    
  
r=jag

    
    

    
  
Fix cheked in, thanks for the reviews.
Status: ASSIGNED → RESOLVED
Closed: 24 years ago
Resolution: --- → FIXED

    
    

    
  
Wow, thanks guys, that was very fast :)

    
    

    
  
How on earth did I end up QA on this. -> desale@netscape.com
Component: DOM HTML → DOM Core
QA Contact: ian → desale

    
    

    
  
Updating QA contact to Shivakiran Tummala.
QA Contact: desale → stummala

    
    

    
  

      
      
      
      

        Attached file
          
        testcase attached (obsolete)
        — 
      

    


  

    
    

    
  
looks like it is not yet implemented...reopening bug...
This is what javascript console reads

Error: uncaught exception: [Exception... "Component returned failure code: 
0x80530009 [nsIDOMHTMLDocument.createProcessingInstruction]"  
nsresult: "0x80530009 (<unknown>)"  location: "JS frame :: 
file:///c|/kiran/test/69840.html :: <TOP_LEVEL> :: line 6"  data: no]

testcase shamelessly stolen from 
http://www.zvon.org/xxl/DOM1reference/Output/examples/Document_createProcessingI
nstruction.html 

testcase:
<html>
<body>
<script>

var pi = document.createProcessingInstruction('php', 'echo("another example")');
  var output1 = pi.target;
  var output2 = pi.data;
alert (output1);
alert (output2);
</script>
</body>
</html>

Status: RESOLVED → REOPENED
Resolution: FIXED → ---

    
    

    
  
You tried this on a html document.
Comments from jst on 2001-02-22:
"are you trying to create processing instructions in HTML? (that should not work
so I wouldn't count on that being implemented any time soon)"
I guess it depends whether there is another bug for createProcessingInstruction
for HTML.


    
    

    
  
As the current DOM HTML spec is written a HTML DOM should *not* implement this
method, so mozilla does the right thing.

However, for XHTML documents this should work, but we're not quite there yet.
Futuring.
Status: REOPENED → ASSIGNED
Target Milestone: mozilla0.9 → Future

    
    

    
  
Adding "for XHTML" to the summary so that we don't confuse with XUL or HTML.
Removing [HAVE FIX] from whiteboard. Sorry for the spam.
Summary: document.createProcessingInstruction not implemented → document.createProcessingInstruction for XHTML not implemented
Whiteboard: [HAVE FIX]

    
  
Priority: P3 → P5

    
    

    
  
Filed bug 166467 for a similar bustage in XUL (which has been touched on 
previously here, but apparently not investigated yet).

    
    

    
  
Mass-reassigning bugs to dom_bugs@netscape.com
Assignee: jst → dom_bugs
Status: ASSIGNED → NEW

    
    

    
  

      
      
      
      

        Attached file
          
        Useful testcase
        — 
      

    


  

        Attachment #40459 -
        Attachment is obsolete: true

    
    

    
  

      
      
      
      

        Attached patch
          
          
        Patch
        — 
          — Splinter Review
      

    


  
Just push the function up to nsDocument and make sure HTML doesn't call them.

        Attachment #26137 -
        Attachment is obsolete: true

    
  

        Attachment #142506 -
        Flags: superreview?(jst)

        Attachment #142506 -
        Flags: review?(jst)

    
    

    
  
Comment on attachment 142506 [details] [diff] [review]
Patch

- In nsDocument::CreateCDATASection():

+  if (FindInReadable(NS_LITERAL_STRING("]]>"),begin,end))
+    return NS_ERROR_DOM_INVALID_CHARACTER_ERR;

This is not per the DOM spec, but I know you didn't write this now... At some
point we should allow this, and let people catch silly stuff like this in
normalizeDocument() or while serializing.

r+sr=jst

        Attachment #142506 -
        Flags: superreview?(jst)

        Attachment #142506 -
        Flags: superreview+

        Attachment #142506 -
        Flags: review?(jst)

        Attachment #142506 -
        Flags: review+

    
  
Assignee: general → bzbarsky
Priority: P5 → P3
Target Milestone: Future → mozilla1.7beta

    
    

    
  
Fixed.
Status: NEW → RESOLVED
Closed: 24 years ago → 20 years ago
Resolution: --- → FIXED

    
    

    
  
bz:
Is it possible that this patch caused the OS/2 bustage (see
http://tinderbox.mozilla.org/showlog.cgi?log=SeaMonkey-Ports/1078267320.4475.gz) ?

    
    

    
  
That tbox is testing a beta compiler that was pretty clearly miscompiling
Mozilla (oragne and all) even before it went red.  The bustage seems to be that
it's just not linking the right things together (notice that it can't find nice
things like operator new for parts of the code that are nowhere near what this
patch touches).

    
    

    
  
I'm in the process of building the latest code on OS/2.  I've just gotten past
layout, and it built the DLL just fine (I am also using this beta compiler).  So
for the moment, it looks like it was a machine error.

    
  
Component: DOM: Core → DOM: Core & HTML
QA Contact: stummala → general

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






  

    
  







  

    

      
Attachment

      

      
      
      
      
    

    

      

        

          

            
General

            

              Creator: 



            

            
Created: 

            
Updated: 

            
Size: