Closed Bug 64645 Opened 24 years ago Closed 23 years ago

RealPlayer plugin displays only bottom of video

Categories

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

defect

Tracking

(Not tracked)

VERIFIED DUPLICATE of bug 36997
mozilla0.9.5

People

(Reporter: gileadis, Assigned: serhunt)

References

()

Details

(Keywords: testcase)

Attachments

(6 files)

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.
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
Status: UNCONFIRMED → NEW
Ever confirmed: true
*** Bug 64974 has been marked as a duplicate of this bug. ***
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.
Keywords: realplayer
the page has an <embed> tag in an <object> tag, I assume Mozilla uses the <object>?
Not always. There is a bug that classid is ignored.
Target Milestone: --- → mozilla1.0
Keywords: 4xp
*** Bug 74681 has been marked as a duplicate of this bug. ***
Attached file testcase (deleted) —
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
Blocks: 74980
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
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.
Attached patch patch to fix the bug (deleted) — Splinter Review
shrir, can you please run your plugin tests with the patch.
Status: NEW → ASSIGNED
QA Contact: petersen → shrir
Chris, are there some formatting guidelines you are trying to follow?
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.
Moving to m0.9.2
Target Milestone: mozilla0.9.1 → mozilla0.9.2
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?
I can do it...will comment soon.
Blocks: 44711
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.
Got the tests from Karnaze. Will run them today and comment soon..
*** Bug 81140 has been marked as a duplicate of this bug. ***
Keywords: patch
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.
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.
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()
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); } }
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.
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.
[s]r=attinasi for patch 34342
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...
The patch is in.
Status: ASSIGNED → RESOLVED
Closed: 24 years ago
Resolution: --- → FIXED
testcase works now, seen fully, nothing gets clipped. VERIFIEDon 0524 trunk .
Status: RESOLVED → VERIFIED
Depends on: 82552
This bug is reopened because the patch caused mac regression (e.g. bug 76085).
Status: VERIFIED → REOPENED
Resolution: FIXED → ---
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).
Status: REOPENED → ASSIGNED
Target Milestone: mozilla0.9.2 → mozilla0.9.3
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
Target Milestone: mozilla0.9.3 → mozilla0.9.4
Target Milestone: mozilla0.9.4 → mozilla0.9.5
Reassigning to av.
Assignee: karnaze → av
Status: ASSIGNED → NEW
Looks like the problem has nothing to do with tables and alignments. Reduced testcase is coming.
Attached file Reduces test case (deleted) —
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?
Sounds like bug 36997.
That was fast! Thanks, Peter.
Marking dup. Chris, if you feel this is not the case please eh... redup. *** This bug has been marked as a duplicate of 36997 ***
Status: NEW → RESOLVED
Closed: 24 years ago23 years ago
Resolution: --- → DUPLICATE
v-d
Status: RESOLVED → VERIFIED
Product: Core → Core Graveyard
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Created:
Updated:
Size: