Closed Bug 54689 Opened 24 years ago Closed 23 years ago

Blank page loads when trying to access pdf on a secure server

Categories

(Core Graveyard :: Plug-ins, defect, P1)

Product:
Core Graveyard
Component:
Plug-ins
Type:
defect

Tracking

(Not tracked)

Status:
VERIFIED FIXED
Milestone:
mozilla1.0

People

(Reporter: shrir, Assigned: peterlubczynski-bugs)

References

(
URL
)

Details

(Keywords: regression, Whiteboard: rtm stopper [seeking reviews])

Attachments

(8 files)

6.0 trace with embedded https document
(deleted), text/plain
Details
4.0 trace with https document
(deleted), text/plain
Details
Version of Acrobat Plug-in That Works With SSL (4.X Bug Workaround is now bounded to not include mozilla)
(deleted), application/octet-stream
Details
Patch to make plugins work over https.
(deleted), patch
Details | Diff | Splinter Review
With Av's suggestion.
(deleted), patch
Details | Diff | Splinter Review
deletes cached file in stream destructor.
(deleted), patch
Details | Diff | Splinter Review
complete patch (mine merged in, conflicts resolved)
(deleted), patch
Details | Diff | Splinter Review
tester plugin release build
(deleted), application/octet-stream
Details 
build: windows branch bits 20000928.
This test is from the adobe testsuite.

Steps to reproduce :
1 Launch seamonkey
2 Click on the url given above
3 Observe that nothing loads and a blank page appears in the browser window

Expected: Pdf file should load in the browser window.

This page loads fine in 4.72 browser.
I see 'The connection was refused when attempting to contact junruh.mcom.com' 
dialog. 
Not a Netscape 6 RTM blocker. FUTURE. This bug has been marked Future because
the Netscape engineer it is assigned to is overburdened.
Target Milestone: --- → Future
*** Bug 63262 has been marked as a duplicate of this bug. ***
This bug is critical for anyone who needs to distribute or receive documents
securely. This affects financial institutions as well as online investment firms
and their clients.

Changing target to mozilla0.9.
Target Milestone: Future → mozilla0.9
I cannot reach any https: site to what happens here. Assume some problems with 
security should be fixed (first).

Over to Security.
Assignee: av → mstoltz
Component: Plug-ins → Security: General
QA Contact: shrir → ckritzer
Please assign SSL-related bugs to Security:Crypto. Reassigning.
Assignee: mstoltz → ddrinan
Component: Security: General → Security: Crypto
QA Contact: ckritzer → junruh
Unsetting Target Milestone, adding nomination keyword.  Nominating is done with
Keywords, not Target Milestone.  Target Milestone is used by the developer to
communicate the development cycle in which he intends to fix the problem.
Keywords: mozilla0.9
Target Milestone: mozilla0.9 → ---
Component: Security: Crypto → Client Library
Product: Browser → PSM
Version: other → 2.0
I bet this is happening on all platform too, not sure. How important is this? I 
nominate for mozilla 0.9.1
Keywords: mozilla0.9 → mozilla0.9.1
This works for me with the latest builds (with PSM 2.0).  Please re-open if this
is still broken for you.
Status: NEW → RESOLVED
Closed: 24 years ago
Resolution: --- → WORKSFORME
where do I install  psm 2.0 from ? Thnx!
Confirmed with Junruh, that this is still not working using today's commercial 
build on windows(0430). John, pls cehck with Bob when you visit him today. 
reopening...
Status: RESOLVED → REOPENED
Resolution: WORKSFORME → ---
Nominating nsbeta1 (it would appear that PSM 2 has some fixes on the way for
this bug).  It is critical to several people.
Severity: normal → critical
Keywords: nsbeta1
Priority: P3 → P1
Blocks: 74980
john, any update on this one?  Thx
John can you run test cases on WinME, WinNT, and Linux and see if you can 
isolate the test case?

I can confirm that this does not work for me on today's Mozilla build on WinNT.

Setting target to 2.0.
Target Milestone: --- → 2.0
2.0 ? Isn't this an 'important' bug and on our "Must Fix" list for Adobe ?
This bug is present in at least WinNT, Win98 and Win95. WinME is untested. Mac 
and Linux work OK.
how is this working on linux for you? acrobat does not launch as a plugin at all 
on linux and if I try to load this secure document using acrobat as a helper 
app, I get a message "this document can be opened from inside the browser only". 
Checking on mac...
pls ignore my comment about linux..the pdf does_open_up as a helper app  on 
linux 0503. There is another bug filed for "Acrobat not working as a plugin on 
linux". 
Mac testing with shrirang present - Acrobat will open a secure pdf file as a 
helper app, but when used as a plugin, a secure pdf file will not display.
I'm changing platform back to ALL as it's clear from testing, HTTPS links only 
work outside of the browser. Adobe expects them to work inside as in IE and Nav 
4.x.
OS: Windows NT → All
Hardware: PC → All
Note: bug 78741 may be preventing accurate testing of this.
Depends on: 78741
I can confirm that this one is pretty important to a great many users.  Does the
PSM 2.0 release coincide with 0.9.1 etc.?
Can someone from the crypto team at least explain what the issue is here?
The issue is that opening a *.pdf file on a http:// web site works, whereas 
opening a *.pdf file on a https:// web site opens a blank window.
How can I verify I have PSM built on my win32 machine. Is it built by default?

Seem like when i tried the url above, I got an endless loop of ASSERTIONs. 
Here's the stack:
NTDLL! DbgBreakPoint@0 address 0x77f9eea9
nsDebug::Break(const char * 0x01a1ffe8, int 364) line 366
nsDebug::Assertion(const char * 0x01a2002c, const char * 0x01a20028, const char 
* 0x01a1ffe8, int 364) line 290 + 13 bytes
nsUnknownDecoder::FireListenerNotifications(nsIRequest * 0x03770fb8, nsISupports 
* 0x00000000) line 364 + 35 bytes
nsUnknownDecoder::OnStopRequest(nsUnknownDecoder * const 0x0345b9d8, nsIRequest 
* 0x03770fb8, nsISupports * 0x00000000, unsigned int 2152398899) line 225 + 16 
bytes
nsDocumentOpenInfo::OnStopRequest(nsDocumentOpenInfo * const 0x03770778, 
nsIRequest * 0x03770fb8, nsISupports * 0x00000000, unsigned int 2152398899) line 
255
XPTC_InvokeByIndex(nsISupports * 0x03770778, unsigned int 4, unsigned int 3, 
nsXPTCVariant * 0x034009a0) line 139
EventHandler(PLEvent * 0x03400948) line 509 + 41 bytes
PL_HandleEvent(PLEvent * 0x03400948) line 588 + 10 bytes
PL_ProcessPendingEvents(PLEventQueue * 0x00d786e0) line 518 + 9 bytes
_md_EventReceiverProc(HWND__ * 0x002605de, unsigned int 49410, unsigned int 0, 
long 14124768) line 1069 + 9 bytes
USER32! UserCallWinProc@20 + 24 bytes
USER32! DispatchMessageWorker@8 + 244 bytes
USER32! DispatchMessageA@4 + 11 bytes
nsAppShell::Run(nsAppShell * const 0x00e29760) line 108
nsAppShellService::Run(nsAppShellService * const 0x00e2ae28) line 418
main1(int 3, char * * 0x00357f88, nsISupports * 0x00000000) line 1010 + 32 bytes
main(int 3, char * * 0x00357f88) line 1308 + 37 bytes
mainCRTStartup() line 338 + 17 bytes
KERNEL32! BaseProcessStart@4 + 115547 bytes

Actually I was hoping more for something from the PSM team as to why this 
fails. Maybe if we could find out what actually the technical problem is.

Here is a better testcase:

Go to:

http://www.nasire.org/hotissues/justice/

Scroll down. click on:

Governance Models - Draft Report [158KB PDF]

The plugin loads, but the file doesn't come up.

As far as PSM 2 goes, it IS built by default on Windows and this problem still 
happens.
*** Bug 81489 has been marked as a duplicate of this bug. ***
Argh

https://www.nasire.org/hotissues/justice/

This page is available BOTH secure and nonsecure.

If you use the https version which I put in, you do see the problem loading the 
PDF file from a secure link.
it would be a win of gargantuan proportions if this made it in by 0.9.1 time
frame (for obvious reasons).  certain parties are extremely interested in the
fate of this one ...
Just spoke with DougT and this is not a PSM problem. Necko does not cache https 
transfers so there won't be a file there for Acrobat to pick up. Doug suggested 
having the plugin code do the temporary file management as is done in Necko.

Reassigning to myself. Attempting to move to "plugins"

PDT, do you feel this is a beta stopper?
Assignee: ddrinan → peterlubczynski
Status: REOPENED → NEW
Component: Client Library → Plug-ins
Product: PSM → Browser
Target Milestone: 2.0 → ---
Version: 2.0 → other
i hate to do this, but i didn't mark this bug originally as a beta stopper
because i was led to believe that it was fixed (psm 2.0).  chrisn believes this
is beta stopper material -- cc'ing chrisn and marek.  phil, if you & pdt
approve, could you change the target milestone?
I can't connect to either https://junruh.mcom.com or https://www.nasire.org

My opinion is that if this worked in 6.0, and doesn't work now, I'd pursue a fix
for 0.9.1 *after* the byte range bug and the Macromedia crashes. If it didn't
work in 6.0, I'd push to 0.9.2.
nope, did not work on 6.0.
unless chrisn jumps in based on the reasons i raised in the e-mail to everyone
concerned, i agree with phil.
All, https is not cached.  Plugin's requires that disk cache is enabled.  

For this to work is that the plugin code must handle file downloading (writing 
to disk) if it want to support an OnFileAvail callback with either the HTTPS 
protocol, or if disk cache is disabled.


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

  

  



    
    

    
  

      
      
      
      

        Attached file
          
        4.0 trace with https document (deleted)
        — 
      

    


  

  

  



    
    

    
  
As is apparent from the attached traces, we were writing out https delivered 
bits to the local disk....eeek! 

Liz, will Acrobat work with just NP_WRITE calls vs. using a file? It's kind of 
bad to write securly delivered bits to a magnetic disk. If so, I can probably 
just convert NP_ASFILE streams to NP_NORMAL ones for https as a test.

If not, a cache like Dougt proposed needs to be made.

  

  



    
    

    
  
Oh, btw, to build PSM 2.0 on Windows you need to set BUILD_PSM2=1

  

  



    
    

    
  
Why is this any different than when you get a PDF document from a secure server 
to use as a helper app? It is cached to disk then.

I can picture cases where people might be sending very large things via http 
servers - the idea that they can't ever be written to disk might cause some 
memory problems...

  

  



    
    

    
  
Just to clarify the security requirments in this case, it is just to discourage 
3rd party snooping of traffic. The end user storing stuff on their machine is 
not such a concern. The machines are all in private homes. It's a chrarity 
extranet.

  

  



    
    

    
  
Note that all previous versions of mozilla and Netscape don't write data
retrieved over https into the disk cache. I want PDF documents loaded over https
to work, but would like mstolz's opinion about the security ramifications.
cc'ing him

  

  



    
    

    
  
Mike, the difference is that the helper application code handles the reading 
from the secure stream and writing to disk. The plugin code 
(modules/plugin/nglsrc) relies on the fact that it can pull local files from the 
necko cache.  I really don't think it is a good idea to put non-persistant files 
 in the disk cache.  This is why the plugin code has to write the stream to disk 
like the helper application code does.


  

  



    
    

    
  
note, that the right person to review putting secure documents into the necko 
cache is david drinan.  I am sure that he would agree that this is a bad idea.

  

  



    
    

    
  
In response to Peter's Q:  when you have the Acrobat plug-in installed,
using just NPP_Write calls to deliver the data to Acrobat is not
only OK, that is what we expect.  It doesn't matter if the data
is secure or not. 

When Acrobat is installed as a helper app, the browser writes the data
to a temp file and Acrobat opens that. 




  

  



    
    

    
  
Peter --


Yikes -- unfortunately, the Acrobat plug-in is telling mozilla that
we want the data as a file due to a bug work around that we put
in.  Here are the details (open NP_PDFX.cpp in
the project and look for "httpshack" or read below):





                NPN_Version(&pmjr, &pmnr, &nmgr, &nmnr);


                /* **ER - Hack to workaround PR#308636.  See bug report for full 
details.
                   Basically, with Netscape 4.x, they refuse to cache HTTPS 
files (unless
                   requested by a plug-in) on disk, but will cache them in 
memory if they
                   are small enough.  If part of the file (for the initial read) 
gets cached
                   in memory, and we make a range request, the range request 
will fail because
                   they decide that it can be served from the cache, even though 
it cannot.
                   Yucky - read the bug report.  Anyhow, we try to detect this 
condition (using
                   hardcoded guess at memory cache size - don't want to dig 
through their prefs
                   file), and in this case we'll ask NS just to download the 
file to their
                   cache and give us the filename.  Because of the backdoor that 
lets files
                   from HTTPS that are requested by plug-ins be cached, this 
will work.
                   We don't need this hack if the stream isn't seekable (no 
byteserving, thus
                   no range requests).  If the server doesn't pass back a 
content-length,
                   stream->end is 0, so we aren't going to freak out.  This hack 
makes things
                   less efficient, as any HTTPS file <= 1 megabyte gets 
downloaded entirely,
                   but that's better than not working at all.  However, if 
Netscape's bug
                   gets fixed in a future version, we should bound the use of 
this hack only
                   to relevant versions.
                */
                DoHTTPSHack = ( seekable && ( nmnr > 10 ) &&
                        ( strnicmp( (char*)stream->url, "https:/", 7 ) == 0 ) &&
                        ( stream->end <= DEFAULT_MEM_CACHE_SIZE ) );



                /* Do we want to ask Netscape to download the file to its cache 
and give us the
                   filename to open directly, or to let us use a seekable 
stream? */
                if ( !seekable || DoLocalFileHack || DoHTTPSHack )
                {
                        /* Ask Netscape to download the file to the cache and 
give us the filename
                           to open from */
                        *stype = NP_ASFILE;
                        stream->pdata = s;
                        s->mode = PDFX_STREAM_ASFILE;
                }






**************************************************************************** 
*****


The DoHTTPSHack is set to true because:


The stream is seekable and the nmnr is 12 (greater than 10), and
the other conditions also exist.



OK -- What to do?    For some future version of Acrobat, I can change
that code to make sure it applies to the Netscape 4.X product only
by looking at the other variable that NPN_Version returns.  I will
check with management to see if they would allow such a simple
fix to be in the patch release that is under development.



On your side, you could change what mozilla returns in NPN_Version
so that the nmnr is 10 or less.  I don't know if this is a good idea
since other folks may be writing code to key off of this.  OR, you
could modify mozilla so that it allowed HTTPS files to be written
to a temp file, since that is the behavior of 4.X, which you are emulating.


While you are thinking about this, I will check with my management.


Liz


  

  



    
    

    
  
I took at NPN_Version and what it returns in Netscape 4.77 versus Mozilla,
to see if I could bound our HTTPS hack bug work around (see above):

                  Moz                  Nav 4.77

Plugin major      0                    0
Plugin minor      11                   11
Netscape major    0                    0
Netscape minor    11                   12

We can, therefore, only put a bounds on our hack if the Nav 4.X product
line will never exceed 11 for Netscape minor (or they fix the bug
we were trying to work around).    Since Netscape minor has been
11 for quite a while, it may be safe to assume this (do you know
anyone in the sustaining engineering group for 4.X?  Marek was the last 
person I knew, but apparently he is now working on mozilla, right?)



  

  



    
    

    
  
I'm guessing that that last line should read:
Netscape minor    12                   11

The version was bumped to 12 for mozilla development when support for some new
values were added. It is a safe bet that no structural changes will be made to
the plugin support in 4.x so the version won't be changing again.


  

  



    
    

    
  
Liz, what do you need us to do on our side? How can we test? Even though no 
milestone is set, "they" would really like this for beta.

  

  


Status: NEW → ASSIGNED

    
    

    
  
Hi folks:

I am going to be able to put a bounds in for that bug workaround for 
our patch release for Acrobat 5.  Customers who experience this bug
should be able to therefore upgrade to the patch release. 

I would therefore make the priority of this bug MUCH LESS than
getting the DDE support (WWW_OpenURL working with Acrobat), as
well as any fixes to byte range support, which I am going to start
testing right now (hopefully all will be fine ... BUT...). 

  

  



    
    

    
  
On OS/2, the only Acrobat Reader we have is 3.0 and we have this problem. We 
can't get Adobe to fix this. (If we could, I have a few other things that need 
fixing :)

Anyway, I was hoping the fix would be in Mozilla so that it would go into the 
OS/2 version.

I don't think hacking around this in Acrobat is the right thing. This isn't a 
Windows only problem.

  

  



    
    

    
  
A quick test of this in 4.x shows that we do indeed cache the file to disk (to 
cacheXXXXXXX.pdf). This file is subsequently deleted when the page is left. You 
can, however, duplicate the file while the page is open thus bypassing its 
deletion.


  

  



    
    

    
  
I just modified the Acrobat plug-in to NOT request the PDF file
served via HTTPS as a file if the browser is mozilla ... and this
modification fixed this bug.  I will be checking this code into the first
service pack for Acrobat 5, ETA early fall.  

This means that there  **will be**  an upgrade path for customers who
experience this bug, if the mozilla team can not get another type of
fix in.  

There are, however, many millions of older versions of Acrobat out
there (like there are many millions of older versions of Netscape
browsers).  A mozilla fix, therefore, would also be desireable.


  

  



    
    

    
  
So "new" Acrobat installs should just work once the fix is in the service pack, 
right?

As for older Acrobats, I wonder if there is a way we can hack this? Should I 
spend any time on trying to do this or should we rel-note it?

  

  


Whiteboard: [will be fixed with Adobe refresh]
Target Milestone: --- → mozilla0.9.2

    
    

    
  
I beg you to try to come up with a fix for this.

some platforms (as in most non Windows) don't get Acrobat updates.

This might be fixed on Windows by Adobe, but it is still a Mozilla bug.

By the way, does anyone know if any other plugins have this problem? Have we 
tried Java applets or wav files on a secure server?

  

  



    
    

    
  
Hmm.. Liz McQuarrie repeatedly tells us that this isn't one of two important 
bugs (bug 53363 and bug 25699).  However, secure PDF is *crucial* to other 
folks.  Peter, see if you can throw together something for older Acrobats.  If 
not, more evangelism for me :-).  I'd like chrisn to make the final call. 

  

  



    
    

    
  
Looks like you won't have to evangelize too much because Liz will be making the 
changes. Maybe we should bump it up another version so we can come up with a 
hack for older Acrobats. 

We need caching code in plugins anyway for when the disk cache is turned off. I 
wonder if we could detect the version of the Adobe plugin or perhaps have a 
failsafe---cache the file if all else fails. Is this possible, Andrei, Dougt?

PDT: What do you think? Should we cache https only as a last resort only in 
plugins? I don't like the idea, but it doesn't seem that bad if it's a last 
resort and Nav 4.x and IE Mac do it. Perhaps a security rel-note?

  

  


Whiteboard: [will be fixed with Adobe refresh]

    
    

    
  
I'm interested in how mkaply's examples work, or any other data to help us
decide if this is more of a compatibility issue or more of a security hole.
Would still like to hear from mstoltz and/or lord on the latter issue.

  

  



    
    

    
  


  

  

  



    
    

    
  
yep, works fine with the attached plugin on today's branch 0605 windows.

  

  



    
    

    
  
Because a solution is close at hand by an Acrobat refresh, I'm moving this off 
to mozilla0.9.3. If I run out of bugs, I'll come back to this.

Also, still need a security opinion....

  

  


Keywords: mozilla0.9.1
Whiteboard: [Fixed with Acrobat refresh]
Target Milestone: mozilla0.9.2 → mozilla0.9.3

    
    

    
  
We need someone on the PSM team to give a security opinion here. I know there
was a good reason for not caching SSL-delivered content, and the risk of bending
that rule seems to be the issue here. I don't know how big that risk is.

  

  



    
    

    
  
OK, now I am just going to beg.

We need this fix for platforms BESIDES Windows.

Adobe's fix is ONLY for Windows.

If someone could just tell me how to hack around this in Mozilla, I would let 
this be pushed to 0.9.3, but right now I have banks that are rolling out stuff 
and this bug is huge.

The fix from Adobe only helps Adobe Windows customers.

Thanks for your support.

  

  



    
    

    
  
It sounds like this is turning into a request for HTTPS object caching.  I
didn't see any PSM bug of that sort, so I created bug 84311.



  

  



    
  
Depends on: 84311

    
  
Whiteboard: [Fixed with Acrobat refresh] → [Fixed with Acrobat refresh]rtm stopper
Target Milestone: mozilla0.9.3 → mozilla0.9.2

    
    

    
  
This is what you get when you propose the solution: more work ;-)



  

  


Assignee: peterlubczynski → dougt
Status: ASSIGNED → NEW

    
  
Depends on: 86041
Whiteboard: [Fixed with Acrobat refresh]rtm stopper → rtm stopper

    
    

    
  


  

  

  



    
    

    
  
The last patch along with the patch in 86041 allow plugins to work over https.  
I have tested this *only* with the above link and have verified that (a) the PDF 
loads, (b) when exiting all temp files are removed, and (c) non-https PDFs still 
load correctly.


A couple of concerns with the last patch:

a) The patch only cleans up temp files on exit. Is this OKAY?  What about 
profile switching?  This task is still blocked by some of Peter's work...

b} Are we saving the location in the right places.  Currently is temp files are 
saved to <profile>/plugtmp.  What should the default location of these kinds of 
temp files be?  Please don't tell me /tmp or the equiv.  

c) Diskspace.  Maybe we should be checking for low disk space and cleanly 
failing.  Well, maybe necko should be doing this in ALOT of places... So, maybe 
it is not a serious concern now.

d) Embedders.  What if they want to change the destination of these files.  I 
think that we need to invent a new directory service location that references a 
"plugin temp directory".  

e) byte range requests over a security connection that also wants to do file 
cacheing... this 'boundary' case I don't want to even think about right now.  
Maybe someone can try it out and report back how bad this doesn't work.

Peter, Mike, Av, can you please review my changes.  

  

  



    
    

    
  
Just a couple of things. Why not to delete the file right after we close the 
stream? May it be needed for navigation? And second, would probably be cleaner 
to define "plugtmp" somewhere in the header file.

  

  



    
    

    
  
FYI: 4.x reference of what to do whith https and byte range streams:

http://lxr.netscape.com/nova/source/lib/plugin/npglue.c#2980

  

  



    
    

    
  
Av, Why not to delete the file right after we close the stream... Well, if we
do, then the plugin never sees the file.  For whatever reasons, the stream is
closed as soon as onStopRequest if fired.  I origanally had the file being
deleted in the stream ~() but that didn't work.  Maybe peter can hook this
"early delete" up later?

new patch coming up which moves "plugtmp" static string to a header...


  

  



    
    

    
  

      
      
      
      

        Attached patch
          
          
        With Av's suggestion. (deleted)
        — 
          — Splinter Review
      

    


  

  

  



    
    

    
  
can I get a r=/sr= on the last patch?  Peter, can you investigate what it will
take to have the temp file be deleted on page transition?  I think you have a
similar bug wrt leaks.

  

  



    
    

    
  
Doug,

In this patch:
http://bugzilla.mozilla.org/showattachment.cgi?attach_id=38711

I'm having the link list of "active" plugin instances,
nsPluginHostImpl::mActivePluginList, take hold a reference to the stream peer
for the "full-page" case. You can probably move that logic to the more general
case of nsPluginHostImpl::NewPluginURLStream.

  

  



    
    

    
  
peter, I was hoping that you could solve this problem.

  

  



    
    

    
  
Okay, how about this: Can you put the delete file code in the destructor of the
stream (peer?) and I'll ensure the stream has a reference for the duration of
the plugin instance so the destructor won't get called until after the plugin
goes away?

Both of these patch will probably have to go in at the same time. 

  

  



    
    

    
  
peter, I would rather not do this.  This would break this patch and I could not
mark this bug as FIX when I checked in.

Let do this.  Write up a new bug wrt the page transition delete, give me a r=,
and get av to look at this patch.  :-)

  

  


Status: NEW → ASSIGNED

    
    

    
  
I added code to the destructor nsPluginStreamInfo::~nsPluginStreamInfo() but
with peter's suggested patch, I am not hitting this delete (possible leak!)


  

  



    
    

    
  
Doug, my logic was completely wrong in that patch. Can you try my fixed up one:
http://bugzilla.mozilla.org/showattachment.cgi?attach_id=38936

I confirm that with this patch, nsPluginStreamInfo::~nsPluginStreamInfo() is
called when leaving the page.

  

  



    
    

    
  
Okay.  that works for me.  I will add a delete in ~nsPluginStreamInfo().  I will
KEEP the delete in the nsPluginHostImpl::Destroy just to be safe.  Patch coming up.

  

  



    
    

    
  


  

  

  



    
    

    
  
The last patch can only be used with peter's stream changes.

  

  



    
    

    
  
Do we need a special server to issue byte ranges?

junruh: can you put up one of the byte range testcase in bug 53363 on your
secure server for testing? My favorite is:
http://access.adobe.com/browser/netscape/readtesting/gotopage5.pdf

  

  



    
    

    
  
Here it is:
https://junruh.mcom.com/gotopage5.pdf

  

  



    
    

    
  
The heavy lifting is done.  Reassigning to peter to seek permission to check in. 
 If there are any problems that come up, please let me know asap.

  

  


Assignee: dougt → peterlubczynski
Status: ASSIGNED → NEW

    
    

    
  
r=av. Although it is not easy to review two patches at once.

  

  



    
    

    
  


  

  

  



    
  
Whiteboard: rtm stopper → rtm stopper [seeking reviews]

    
    

    
  
Well, if you all have decided that it is really OK to write https data to the
filesystem, then sr=attinasi on the patcy (id=38998) - sounds like a security
hole to me though (especially with access permissions set to 777).

  

  



    
    

    
  
a= asa@mozilla.org for checkin to the trunk.
(on behalf of drivers)

  

  


Blocks: 83989

    
    

    
  
I agree. Adding keyword relnote.

Arun, how do you ensure a relnote is added to the product?

Liz: How will these changes effect yours in Acrobat? We still want to stream
directly to Acrobat 5.x with your changes. Should we increment the version?

Patch checked in, marking FIXED.

  

  


Status: NEW → RESOLVED
Closed: 24 years ago → 24 years ago
Keywords: relnote
Resolution: --- → FIXED

    
    

    
  
Marc, double check that.  The cached file should be opened as 00600.  

  

  



    
    

    
  
verify fix works in trunk build 2001-06-18-23/Win2k

  

  



    
    

    
  
Verified on WinNT branch. On Mac, I get a crash.

  

  



    
    

    
  
john, do you have a stack trace?  lets open a new bug for this problem.

  

  



    
    

    
  
Marking verified. I am opening a new bug for Mac and possibly Linux.

  

  


Status: RESOLVED → VERIFIED

    
    

    
  
Reopening. This is reproducible again.

  

  


URL: https://junruh.mcom.com/pingform.pdf → https://pki.mcom.com/pingform.pdf
Status: VERIFIED → REOPENED
Keywords: relnote → nsbeta1, 
          
            regression
Resolution: FIXED → ---
Target Milestone: mozilla0.9.2 → mozilla1.0

    
    

    
  
WFM: w2k, Gecko/20020306 Netscape6/6.2.1+, https://pki.mcom.com/pingform.pdf
But there is a possibility to hang mozilla or 4.x  on *.pdf file if something 
bad happened in previous rpc session between acrobat plugin and Acrobat process, 
actually last one can just stall, in this case you won't be able to open any 
local pdf file. 
The solution: kill Acrobat.exe 

  

  



    
    

    
  
Yes, confirming that this is happening, but ONLY with Acrobat 5.05. The
orriginal Acrobat 5.0 works correctly. Strange....Liz, did anything change?

From the logs, everything looks correct that we are getting byte ranges and a
plugin instance is being created. However, the data never gets to the plugin!
We're not even updating progress in the status bar. A look in the debugger is
needed.

Although the symptoms may be the same, let's open a new bug as I don't think
this is going to be the same issue as this bug.

  

  


Status: REOPENED → RESOLVED
Closed: 24 years ago → 23 years ago
Resolution: --- → FIXED

    
    

    
  
v

  

  


Status: RESOLVED → VERIFIED

    
    

    
  
I have just installed 5.1 and see blank page too.

  

  



    
    

    
  
Hi Folks:

We have an the same pingform.pdf test case (or similar) on a secure
server here, but I am not seeing a blank page problem.  I am, seeing, however,
that the forms submission does not work with the 3/8 build. 

I will do a little more debugging on the forms submission problem.
In the meantime, it looks like I will need you folks to help
me get access to your test case for the blank page, since I can not
repo it here.


  

  



    
    

    
  
Confirming signing PDF's fails on NPN_Post on:
http://acroeng.adobe.com/BrowserTestSuite/forms/SubmitAsPDF.pdf

Created bug 130080 for this issue.

  

  



    
    

    
  

      
      
      
      

        Attached file
          
        tester plugin release build (deleted)
        — 
      

    


  

  

  



    
    

    
  
woops, wrong bug report:(

  

  



    
  
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: