64645 - RealPlayer plugin displays only bottom of video

Status: VERIFIED DUPLICATE of bug 36997

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

Description

[Dave Gileadi]

From Bugzilla Helper:
User-Agent: Mozilla/4.0 (compatible; MSIE 5.5; Windows NT 4.0)
BuildID:    

The RealPlayer plugin doesn't display the full picture in Mozilla due to the 
browser re-laying-out the page before the video has a chance to load.

Reproducible: Always
Steps to Reproduce:
1. Visit http://video.cnet.com/cgi-bin/visearch?
user=cnet_news&template=playhiram.html&query=%2A&squery=%2BClipID%3A0+%
2BVideoAsset%
3At010601_1200&inputField=&ccstart=5166&ccend=695300&videoID=t010601_1200
(and don't get after me for this being a Microsoft comercial; it's where I saw 
the problem, okay? :)

2. Watch the video load.

Actual Results:  The top half of the video is cut off.

Expected Results:  The video should display entirely within the browser frame.

This seems to happen because the page resizes itself when the stream is first 
loading, since we don't have any video to display yet, and then when the video 
does appear the page doesn't resize itself again to fit.

Comment 1

[Jonathan S Abrams]

I am seeing this with build 2001010508 on Mac OS 9.0.4.  Changing platform and
os to reflect this.

Comment 2

[Jonathan S Abrams]

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

Comment 3

[shrirang khanzode]

I see this on both the branch and trunk and specific to this website. Other 
videos on cnn.com etc work fine. The layout is messed up and the video appears 
cut.

Comment 4

[basic]

the page has an <embed> tag in an <object> tag, I assume Mozilla uses the <object>?

Comment 5

[av (gone)]

Not always. There is a bug that classid is ignored.

Comment 6

[shrirang khanzode]

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

Comment 7

[shrirang khanzode]

Attachment: testcase

Comment 8

[Arun Ranganathan]

shrir's added in a testcase (yay)!.  This one's critical and so i'm nominating
it nsbeta1.

Comment 9

[Peter Lubczynski]

This is still a problem with today's pull on Windows. Attaching content and 
frame dump of simplifed testcase. Should be easy to pinpoint problem as Y offset 
is incorrect.

Re-assign to karnaze.

Comment 10

[Peter Lubczynski]

Attachment: content and frame dump of attached testcase

Comment 11

[Todd Pringle]

Bug 68189 is to include an updated Real Player build in the next release - you
may want to see if this behavior still exists with the new version.

Comment 12

[karnaze (gone)]

Attachment: patch to fix the bug

Comment 13

[karnaze (gone)]

shrir, can you please run your plugin tests with the patch. 

Comment 14

[av (gone)]

Chris, are there some formatting guidelines you are trying to follow?

Comment 15

[Peter Lubczynski]

Wow...what a patch. Perhaps an HTML diff would be easier to read. Looks like a 
big change. 

I don't think Shrirang has a build set up on his Windows machine to test this 
on.

Comment 16

[karnaze (gone)]

Moving to m0.9.2

Comment 17

[Arun Ranganathan]

shrir, is there any way you can test with karnaze's patch? let me know if you
need any help.  i'm REALLY keen on this being in 0.9.1.  did anyone code review
the patch?

Comment 18

[shrirang khanzode]

I can do it...will comment soon.

Comment 19

[Peter Lubczynski]

You may want to coordinate with Karnaze as I've given him my test suite to run. 
This is a pretty big patch to nsObjectFrame::Reflow so i'd be good to get some 
coverage on it.

Comment 20

[shrirang khanzode]

Got the tests from Karnaze. Will run them today and comment soon..

Comment 21

[shrirang khanzode]

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

Comment 22

[Peter Lubczynski]

I highly suggest NOT checking this in until proper testing can be done.

Proper testing can not be done until we fix the bugs which cause Real to crash.

Comment 23

[shrirang khanzode]

I agree with Peter. I ran thru Peter's test suite(eith patch in win debug trunk 
build) . This bug seems fixed, however, the browser crashes as soon as the 
testcase attached in this bug laods up (on debug windows). So I cannot confirm 
whether this crasher is due to an old existing problem that we have or a newly 
introduced one due to this patch. To add to my sorrows, talkback servers are not 
providing any information when the browser is crashing. 
thus confusing me more :( . I talked with the guy who handles talkback and he is 
working on getting it working back soon.

Comment 24

[Suresh]

I tried to test this bug with and also without the patch using debug build on 
Win NT. After I load the testcase (shrir's testcase provided on 2001-04-30 
15:46) it throws few assertions and eventually crashes with the foll. stack 
trace. Anyone else seeing this? Should I file a new one for this crash? Thanks!

_free_dbg_lk(void * 0x102503d8, int 1) line 1095 + 11 bytes
_free_dbg(void * 0x102503d8, int 1) line 1001 + 13 bytes
free(void * 0x102503d8) line 956 + 11 bytes
PL_strfree(char * 0x102503d8) line 44 + 10 bytes
nsCRT::free(char * 0x102503d8) line 175 + 9 bytes
nsPluginStreamListenerPeer::SetUpStreamListener(nsIRequest * 0x04f39930, nsIURI 
* 0x04f3a8f0) line 1622 + 10 bytes
nsPluginStreamListenerPeer::OnStartRequest(nsPluginStreamListenerPeer * const 
0x04f39aa0, nsIRequest * 0x04f39930, nsISupports * 0x00000000) line 1413 + 21 
bytes
nsStreamListenerTee::OnStartRequest(nsStreamListenerTee * const 0x04f0e0f0, 
nsIRequest * 0x04f39930, nsISupports * 0x00000000) line 14
nsHttpChannel::ProcessNormal() line 432
nsHttpChannel::ProcessResponse() line 363 + 8 bytes
nsHttpChannel::OnStartRequest(nsHttpChannel * const 0x04f39934, nsIRequest * 
0x04f26b50, nsISupports * 0x00000000) line 1974 + 11 bytes
nsOnStartRequestEvent::HandleEvent() line 108 + 53 bytes
nsARequestObserverEvent::HandlePLEvent(PLEvent * 0x04f473e4) line 64
PL_HandleEvent(PLEvent * 0x04f473e4) line 588 + 10 bytes
PL_ProcessPendingEvents(PLEventQueue * 0x00e799e0) line 518 + 9 bytes
_md_EventReceiverProc(HWND__ * 0x002d03cc, unsigned int 49417, unsigned int 0, 
long 15178208) line 1069 + 9 bytes
USER32! 77e71820()
00e799e0()

Comment 25

[Suresh]

Allright! My $0.02 here. I think we are trying to free an invalid memory 
location that results in a crash. The following patch fixes the crash!!

Index: nsPluginHostImpl.cpp
===================================================================
RCS file: /cvsroot/mozilla/modules/plugin/nglsrc/nsPluginHostImpl.cpp,v
retrieving revision 1.247
diff -u -r1.247 nsPluginHostImpl.cpp
--- nsPluginHostImpl.cpp        2001/05/11 21:04:53     1.247
+++ nsPluginHostImpl.cpp        2001/05/17 05:33:09
@@ -1608,8 +1608,8 @@
   // get Last-Modified header for plugin info
   if (httpChannel)
   {
-    char * lastModified;
-    httpChannel->GetResponseHeader("last-modified", &lastModified);
+    nsXPIDLCString lastModified;
+    httpChannel->GetResponseHeader("last-modified", 
getter_Copies(lastModified));
     if (lastModified)
     {
       PRTime time64;
@@ -1619,7 +1619,7 @@
       double fpTime;
       LL_L2D(fpTime, time64);
       mPluginStreamInfo->SetLastModified((PRUint32)(fpTime * 1e-6 + 0.5));
-      nsCRT::free(lastModified);
+//      nsCRT::free(lastModified);
     }
   }

Comment 26

[Peter Lubczynski]

Attachment: patch to fix crash in SetUpStreamListener (forgot about this one)

Comment 27

[karnaze (gone)]

suresh, peterl in general it is better to open a new bug for a different problem 
(since it was crashing with or without attachment #3 [details] [diff] [review]), but since peterl has 
already added the 2nd patch, let's leave it.

Comment 28

[Peter Lubczynski]

Yes, the patch in attachment #3 [details] [diff] [review] has been checked in as a result of bug 81374. 
r=pinkerton and sr=hyatt very eary this morning. Testing should now be able to 
continue (update nsObejectFrame.* and everything in /nglsrc). If you are still 
crashing, please attach a stack. I can probably tell if it's a "known crash" or 
a new one.

Comment 29

[Marc Attinasi]

[s]r=attinasi for patch 34342

Comment 30

[karnaze (gone)]

Attachment: revised patch (supersedes attachment #3)

Comment 31

[shrirang khanzode]

tested with the latest patch on windows debug. All problems that I had reported 
to karnaze are now gone. Pages look good, plugins load. However, I stumbled upon 
one new layout problem (not seen on 0417 trunk commercial) for which I will file 
a new bug. So, I guess, this is good to go...

Comment 32

[karnaze (gone)]

The patch is in.

Comment 33

[shrirang khanzode]

testcase works now, seen fully, nothing gets clipped. VERIFIEDon 0524 trunk .

Comment 34

[karnaze (gone)]

This bug is reopened because the patch caused mac regression (e.g. bug 76085).

Comment 35

[karnaze (gone)]

This bug needs the following patches applied - the 5th attachment in this 
bug, the attachment in bug 82552, and the 2nd attachment in bug 76085. After 
that, we need to figure out why mac problems arise (e.g. bug 76085).

Comment 36

[shrirang khanzode]

wow..the cnet video started loading again...thnx to Chris Petersen to bring this 
to my notice. Arun, I guess those guys removed layers form their page and we are 
back to square one here. I mean..on today's builds, the real video clip plays 
but appears clipped as mentioned initially here. are we fixing this one?

testcase : http://bugzilla.mozilla.org/showattachment.cgi?attach_id=32689

Comment 37

[karnaze (gone)]

Reassigning to av.

Comment 38

[av (gone)]

Looks like the problem has nothing to do with tables and alignments. Reduced 
testcase is coming.

Comment 39

[av (gone)]

Attachment: Reduces test case

Comment 40

[av (gone)]

Latest finding. The test case is an <object> tag with <embed> as its 
alterntative content which Mozilla currently tries to render ignoring the 
<object> tag. The <object> tag has an attribute align="top" which happens to be 
the ultimate cause of the problem. If it is removed or changed to "bottom" or 
"center", everything is fine.

Anybody, ideas?

Comment 41

[Peter Lubczynski]

Sounds like bug 36997.

Comment 42

[av (gone)]

That was fast! Thanks, Peter.

Comment 43

[av (gone)]

Marking dup. Chris, if you feel this is not the case please eh... redup.

*** This bug has been marked as a duplicate of 36997 ***

Comment 44

[shrirang khanzode]

v-d