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)
Core Graveyard
Plug-ins
Tracking
(Not tracked)
mozilla0.9.5
People
(Reporter: gileadis, Assigned: serhunt)
References
()
Details
(Keywords: testcase)
Attachments
(6 files)
(deleted),
text/html
|
Details | |
(deleted),
text/plain
|
Details | |
(deleted),
patch
|
Details | Diff | Splinter Review | |
(deleted),
patch
|
Details | Diff | Splinter Review | |
(deleted),
patch
|
Details | Diff | Splinter Review | |
(deleted),
text/html
|
Details |
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•24 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
Updated•24 years ago
|
Status: UNCONFIRMED → NEW
Ever confirmed: true
Comment 3•24 years ago
|
||
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>?
Comment 7•24 years ago
|
||
Comment 8•24 years ago
|
||
shrir's added in a testcase (yay)!. This one's critical and so i'm nominating
it nsbeta1.
Comment 9•24 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•24 years ago
|
||
Comment 11•24 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•24 years ago
|
||
Comment 13•24 years ago
|
||
shrir, can you please run your plugin tests with the patch.
Status: NEW → ASSIGNED
QA Contact: petersen → shrir
Assignee | ||
Comment 14•24 years ago
|
||
Chris, are there some formatting guidelines you are trying to follow?
Comment 15•24 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
on.
Comment 17•24 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•24 years ago
|
||
I can do it...will comment soon.
Comment 19•24 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•24 years ago
|
||
Got the tests from Karnaze. Will run them today and comment soon..
Comment 21•24 years ago
|
||
*** Bug 81140 has been marked as a duplicate of this bug. ***
Comment 22•24 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•24 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•24 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
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•24 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",
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•24 years ago
|
||
Comment 27•24 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•24 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•24 years ago
|
||
[s]r=attinasi for patch 34342
Comment 30•24 years ago
|
||
Comment 31•24 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•24 years ago
|
||
The patch is in.
Status: ASSIGNED → RESOLVED
Closed: 24 years ago
Resolution: --- → FIXED
Comment 33•24 years ago
|
||
testcase works now, seen fully, nothing gets clipped. VERIFIEDon 0524 trunk .
Status: RESOLVED → VERIFIED
Comment 34•23 years ago
|
||
This bug is reopened because the patch caused mac regression (e.g. bug 76085).
Status: VERIFIED → REOPENED
Resolution: FIXED → ---
Comment 35•23 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).
Status: REOPENED → ASSIGNED
Target Milestone: mozilla0.9.2 → mozilla0.9.3
Comment 36•23 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 : http://bugzilla.mozilla.org/showattachment.cgi?attach_id=32689
Updated•23 years ago
|
Target Milestone: mozilla0.9.3 → mozilla0.9.4
Updated•23 years ago
|
Target Milestone: mozilla0.9.4 → mozilla0.9.5
Assignee | ||
Comment 38•23 years ago
|
||
Looks like the problem has nothing to do with tables and alignments. Reduced
testcase is coming.
Assignee | ||
Comment 39•23 years ago
|
||
Assignee | ||
Comment 40•23 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•23 years ago
|
||
Sounds like bug 36997.
Assignee | ||
Comment 42•23 years ago
|
||
That was fast! Thanks, Peter.
Assignee | ||
Comment 43•23 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 ***
Status: NEW → RESOLVED
Closed: 24 years ago → 23 years ago
Resolution: --- → DUPLICATE
Updated•3 years ago
|
Product: Core → Core Graveyard
You need to log in
before you can comment on or make changes to this bug.
Description
•