Closed Bug 297388 Opened 19 years ago Closed 19 years ago

nsIWebBrowserStream unusable with text/html input

Categories

(Core Graveyard :: Embedding: APIs, defect, P1)

Product:
Core Graveyard
Component:
Embedding: APIs
Type:
defect

Tracking

(Not tracked)

Status:
RESOLVED FIXED
Milestone:
mozilla1.8beta4

People

(Reporter: mjscod, Assigned: Biesinger)

Details

(Keywords: fixed1.8)

Attachments

(2 files)

My .mozconfig used to build the trunk
585 bytes, text/plain
Details
patch
1.35 KB, patch
caillon
: review+
darin.moz
: superreview+
asa
: approval1.8b4+
Details | Diff | Splinter Review 
User-Agent:       Mozilla/5.0 (Windows; U; Windows NT 5.1; de-DE; rv:1.7.8) Gecko/20050511 Firefox/1.0.4
Build Identifier: Mozilla/5.0 (Windows; U; Windows NT 5.1; de-DE; rv:1.7.8) Gecko/20050511 Firefox/1.0.4

The nsIWebBrowserStream::AppendToStream fails when the stream was opened as a
text/html stream.


Reproducible: Always

Steps to Reproduce:
1. Query a nsIWebBrowserStream implementation from nsIWebBrowser object
(instance of NS_WEBBROWSER_CONTRACTID)
2. Open stream with text/html as content type
3. Add data using the AppendToStream function

Actual Results:  
It asserts with the following error:

###!!! ASSERTION: data loss: 'writeCount == nBytes', file e:/Develop/checkouts/m
ozilla/mozilla/embedding/browser/webBrowser/nsEmbedStream.cpp, line 281
Break: at file e:/Develop/checkouts/mozilla/mozilla/embedding/browser/webBrowser
/nsEmbedStream.cpp, line 281


Expected Results:  
The problem is that HTML parser requires a buffered input stream but the
implementation of nsPipe uses an unbuffered input stream.

This is the GDB backtrace:
#0  0x7c911231 in ntdll!DbgUiConnectToDbg () from ntdll.dll
#1  0x00557e52 in nsDebugImpl::Break (this=0x6d62618,
    aFile=0x77a65f0 "e:/Develop/checkouts/mozilla/mozilla/embedding/browser/webB
rowser/nsEmbedStream.cpp", aLine=281)
    at e:/Develop/checkouts/mozilla/mozilla/xpcom/base/nsDebugImpl.cpp:314
#2  0x00557dc0 in nsDebugImpl::Assertion (this=0x6d62618,
    aStr=0x77a682d "data loss", aExpr=0x77a6818 "writeCount == nBytes",
    aFile=0x77a65f0 "e:/Develop/checkouts/mozilla/mozilla/embedding/browser/webB
rowser/nsEmbedStream.cpp", aLine=281)
    at e:/Develop/checkouts/mozilla/mozilla/xpcom/base/nsDebugImpl.cpp:294
#3  0x004f1bbc in nsDebug::Assertion (aStr=0x77a682d "data loss",
    aExpr=0x77a6818 "writeCount == nBytes",
    aFile=0x77a65f0 "e:/Develop/checkouts/mozilla/mozilla/embedding/browser/webB
rowser/nsEmbedStream.cpp", aLine=281)
    at e:/Develop/checkouts/mozilla/mozilla/obj-i686-pc-cygwin/xpcom/build/nsDeb
ug.cpp:108
#4  0x07790a10 in nsEmbedStream::ReadSegments (this=0x6d41770,
    aWriter=0x52d778 <TestInputStream(nsIInputStream*, void*, char const*, unsig
ned int, unsigned int, unsigned int*)>, aClosure=0x23f9b0, aCount=1,
    _retval=0x23f9b4)
    at e:/Develop/checkouts/mozilla/mozilla/embedding/browser/webBrowser/nsEmbed
Stream.cpp:281
#5  0x0052d7c4 in NS_InputStreamIsBuffered (stream=0x6d41770)
    at e:/Develop/checkouts/mozilla/mozilla/xpcom/io/nsStreamUtils.cpp:606
#6  0x10eb2a38 in nsParser::OnDataAvailable (this=0x6da8338,
    request=0x6d35368, aContext=0x0, pIStream=0x6d41770, sourceOffset=0,
    aLength=38)
    at e:/Develop/checkouts/mozilla/mozilla/parser/htmlparser/src/nsParser.cpp:2
594
#7  0x07790770 in nsEmbedStream::AppendToStream (this=0x6d41770,
    aData=0x6dd572c "<html><body>Hello world!</body></html>", aLen=38)
    at e:/Develop/checkouts/mozilla/mozilla/embedding/browser/webBrowser/nsEmbed
Stream.cpp:195
#8  0x0778cc3f in nsWebBrowser::AppendToStream (this=0x6cc5770,
    aData=0x6dd572c "<html><body>Hello world!</body></html>", aLen=38)
    at e:/Develop/checkouts/mozilla/mozilla/embedding/browser/webBrowser/nsWebBr
owser.cpp:1937
#9  0x0040279c in WndMain::WndMain ()
#10 0x004031c1 in TestMozilla::OnInit ()
#11 0x0040c4f1 in wxAppConsole::CallOnInit ()
    at e:/Develop/checkouts/mozilla/mozilla/xpcom/glue/nsISupportsUtils.h:201
#12 0x0129ee09 in wxEntryReal () at wxchar.h:758
#13 0x01307cb8 in wxEntry () at wxchar.h:758
#14 0x01887629 in wxEntry () at object.h:520
#15 0x00401bc7 in WinMain@16 ()
#16 0x0040aeca in main ()
Assignee: nobody → adamlock
Component: General → Embedding: APIs
Product: Firefox → Core
QA Contact: general
Version: unspecified → 1.7 Branch
this works for TestGtkEmbed...

Also, which version of Mozilla/Firefox were you using? It can't be 1.7.8/1.0.4,
as that interface does not exist there.

hm, I do see this in a debug build.
Assignee: adamlock → cbiesinger
Status: UNCONFIRMED → NEW
Ever confirmed: true
OS: Windows XP → All
Version: 1.7 Branch → Trunk
Sorry, you're right. I found this problem in CVS HEAD, Cygwin/MinGW DEBUG build.
I attach my .mozconfig.

    
    

    
  
well, I guess this explains all:
    // XXX writeCount may be less than nBytes!!  This is the wrong
    // way to synthesize ReadSegments.

    
    

    
  

      
      
      
      

        Attached patch
          
          
        patch
        — 
          — Splinter Review
      

    


  
this fixes it. I do not understand why this was implemented the way it is. I'm
also not sure why the code does not simply pass mInputStream to the input
stream channel...

does anyone see any problems in implementing ReadSegments this way? (just
passing it to the underlying mInputStream)

        Attachment #185955 -
        Flags: superreview?(darin)

        Attachment #185955 -
        Flags: review?(blizzard)

    
    

    
  
Thank you, this patch works for me.
Status: NEW → ASSIGNED
Priority: -- → P1
Hardware: PC → All
Target Milestone: --- → mozilla1.8beta3

    
    

    
  
It the underlying input stream known to always implement ReadSegments?  Maybe
this code was created to deal with cases where that may not be true.

    
    

    
  
s/It/Is/ .. sorry about that

    
    

    
  
Hm... the stream is the input end of a pipe, and has always been that.
(http://bonsai.mozilla.org/cvsblame.cgi?file=mozilla/embedding/browser/gtk/src/EmbedStream.cpp&rev=1.1&cvsroot=/cvsroot)

did pipes ever not implement readsegments?

    
    

    
  
Comment on attachment 185955 [details] [diff] [review]
patch

Ah, if this is a pipe, then this is definitely correct.  Pipes have always
implemented ReadSegments.  Maybe this code once upon a time didn't use pipes...
or whatever ;)

        Attachment #185955 -
        Flags: superreview?(darin) → superreview+

        Attachment #185955 -
        Flags: review?(blizzard) → review?(mpgritti)

        Attachment #185955 -
        Flags: review?(mpgritti) → review?(caillon)

        Attachment #185955 -
        Flags: review?(caillon) → review+

    
    

    
  
fixed on trunk:
Checking in embedding/browser/webBrowser/nsEmbedStream.cpp;
/cvsroot/mozilla/embedding/browser/webBrowser/nsEmbedStream.cpp,v  <-- 
nsEmbedStream.cpp
new revision: 1.6; previous revision: 1.5
done


    
    

    
  
Comment on attachment 185955 [details] [diff] [review]
patch

low risk fix to make nsIWebBrowserStream work correctly, especially an issue in
debug builds. This only affects embeddors.

        Attachment #185955 -
        Flags: approval1.8b4?

    
  

        Attachment #185955 -
        Flags: approval1.8b4? → approval1.8b4+

    
    

    
  
MOZILLA_1_8_BRANCH:
Checking in webBrowser/nsEmbedStream.cpp;
/cvsroot/mozilla/embedding/browser/webBrowser/nsEmbedStream.cpp,v  <-- 
nsEmbedStream.cpp
new revision: 1.5.18.1; previous revision: 1.5
done

Status: ASSIGNED → RESOLVED
Closed: 19 years ago
Keywords: fixed1.8
Resolution: --- → FIXED
Target Milestone: mozilla1.8beta3 → mozilla1.8beta4

    
  
Product: Core → Core Graveyard

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






  

    
  







  

    

      
Attachment

      

      
      
      
      
    

    

      

        

          

            
General

            

              Creator: 



            

            
Created: 

            
Updated: 

            
Size: