RealPlayer plugin displays only bottom of video




17 years ago
16 years ago


(Reporter: Dave Gileadi, Assigned: av (gone))



Dependency tree / graph

Firefox Tracking Flags

(Not tracked)




(6 attachments)



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

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
(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

17 years ago
I am seeing this with build 2001010508 on Mac OS 9.0.4.  Changing platform and
os to reflect this.
OS: Windows NT → All
Hardware: PC → All


17 years ago
Ever confirmed: true

Comment 2

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

Comment 3

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


17 years ago
Keywords: realplayer

Comment 4

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

Comment 5

17 years ago
Not always. There is a bug that classid is ignored.


17 years ago
Target Milestone: --- → mozilla1.0


17 years ago
Keywords: 4xp

Comment 6

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

Comment 7

17 years ago
Created attachment 32689 [details]

Comment 8

17 years ago
shrir's added in a testcase (yay)!.  This one's critical and so i'm nominating
it nsbeta1.
Severity: major → critical
Keywords: nsbeta1, testcase
Priority: -- → P1


17 years ago
Blocks: 74980

Comment 9

17 years ago
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.
Assignee: av → karnaze
QA Contact: shrir → petersen
Target Milestone: mozilla1.0 → mozilla0.9.1

Comment 10

17 years ago
Created attachment 32854 [details]
content and frame dump of attached testcase

Comment 11

17 years ago
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

17 years ago
Created attachment 34342 [details] [diff] [review]
patch to fix the bug

Comment 13

17 years ago
shrir, can you please run your plugin tests with the patch. 
QA Contact: petersen → shrir

Comment 14

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

Comment 15

17 years ago
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 

Comment 16

17 years ago
Moving to m0.9.2
Target Milestone: mozilla0.9.1 → mozilla0.9.2

Comment 17

17 years ago
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

17 years ago
I can do it...will comment soon.


17 years ago
Blocks: 44711

Comment 19

17 years ago
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

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

Comment 21

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


17 years ago
Keywords: patch

Comment 22

17 years ago
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

17 years ago
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

17 years ago
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 
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()

Comment 25

17 years ago
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", 
     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

17 years ago
Created attachment 34912 [details] [diff] [review]
patch to fix crash in SetUpStreamListener (forgot about this one)

Comment 27

17 years ago
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

17 years ago
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

17 years ago
[s]r=attinasi for patch 34342

Comment 30

17 years ago
Created attachment 35148 [details] [diff] [review]
revised patch (supersedes attachment #3 [details] [diff] [review])

Comment 31

17 years ago
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

17 years ago
The patch is in.
Last Resolved: 17 years ago
Resolution: --- → FIXED

Comment 33

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


17 years ago
Depends on: 82552

Comment 34

17 years ago
This bug is reopened because the patch caused mac regression (e.g. bug 76085).
Resolution: FIXED → ---

Comment 35

17 years ago
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).
Target Milestone: mozilla0.9.2 → mozilla0.9.3

Comment 36

17 years ago
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 :


17 years ago
Target Milestone: mozilla0.9.3 → mozilla0.9.4


17 years ago
Target Milestone: mozilla0.9.4 → mozilla0.9.5

Comment 37

17 years ago
Reassigning to av.
Assignee: karnaze → av

Comment 38

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

Comment 39

16 years ago
Created attachment 50773 [details]
Reduces test case

Comment 40

16 years ago
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

16 years ago
Sounds like bug 36997.

Comment 42

16 years ago
That was fast! Thanks, Peter.

Comment 43

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

*** This bug has been marked as a duplicate of 36997 ***
Last Resolved: 17 years ago16 years ago
Resolution: --- → DUPLICATE

Comment 44

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