Closed Bug 520436 Opened 15 years ago Closed 15 years ago

Padding for embedded YouTube videos causes clipped/distorted controls and video content

Categories

(Core :: Layout, defect, P2)

x86
macOS
defect

Tracking

()

VERIFIED FIXED
mozilla1.9.3a1
Tracking Status
status1.9.2 --- beta2-fixed

People

(Reporter: whimboo, Assigned: roc)

References

()

Details

(Keywords: regression, testcase, verified1.9.2)

Attachments

(4 files)

Attached image screenshot
Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.5; en-US; rv:1.9.3a1pre) Gecko/20091003 Minefield/3.7a1pre ID:20091003031247 With the fix on bug 508495 the video content is nearly shown perfect on all platforms. Only on OS X I get some static pixels on the right side now which are not getting updated. It's really only visible on OS X and works fine on Windows and Linux. Also Shiretoko doesn't show it. See the screenshot. Steps: 1. Load the page from the URL field 2. Start the video
Flags: blocking1.9.2?
A small testcase would be useful especially if you can come up with one that doesn't require dynamic changes in plugin content...
Attached file Dynamic testcase
That's a short reduction for the given web page. It shows that the padding is causing this problem. It's applied to the object and embedded element. It's even more than only a couple of pixels now. The controller bar gets distorted too.
Keywords: testcase
Summary: Static video content shown at the right side whey playing embedded YouTube videos → Padding for embedded YouTube videos causes clipped/distorted controls and video content
Similar artifacts are shown in video content with Namoroka. So it has to be a regression from bug 339548 directly.
Blocks: 339548
No longer blocks: 508495
Keywords: regression
Assignee: nobody → roc
Attached patch fixSplinter Review
NPN_InvalidateRect's rectangle parameter is relative to the top-left of the plugin content, so we need to adjust it to make it relative to the element's border-box. To make this testable I've added a setColor method to the test plugin that invalidates the plugin's area. Then it's possible to write invalidation reftests using the test plugin.
Attachment #404582 - Flags: review?(joshmoz)
Whiteboard: [needs review]
Flags: in-testsuite?
Attachment #404582 - Flags: review?(joshmoz) → review+
Whiteboard: [needs review] → [needs landing]
Flags: blocking1.9.2? → blocking1.9.2+
Priority: -- → P2
Roc, can we call it fixed?
I'm holding it open to investigate the test failure.
Hmm, reftest seems to pass locally and on try servers. I will try to reland.
As well as reenabling the test, this patch makes reftest.js output slightly more specific messages when there is a post-onload timeout.
Attachment #408535 - Flags: review?(dbaron)
I'll mark this fixed to avoid confusion.
Status: NEW → RESOLVED
Closed: 15 years ago
Resolution: --- → FIXED
Verified fixed with Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.5; en-US; rv:1.9.3a1pre) Gecko/20091027 Minefield/3.7a1pre ID:20091027031433
Status: RESOLVED → VERIFIED
Target Milestone: --- → mozilla1.9.3a1
Verified fixed with Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.5; en-US; rv:1.9.2b2pre) Gecko/20091105 Namoroka/3.6b2pre ID:20091105033812
Comment on attachment 408535 [details] [diff] [review] make reftest timeout messages a bit more useful r=dbaron, although I probably should have suggested months ago that Jesse review this instead...
Attachment #408535 - Flags: review?(dbaron) → review+
Whiteboard: [needs landing]
I'm pretty sure you rolled the reftest harness changes of attachment 408535 [details] [diff] [review] into your rewrite, since the messages sound a bit familiar. I landed the re-enable the commented-out reftest part in http://hg.mozilla.org/mozilla-central/rev/c14987c4d6a0.
Whiteboard: [needs landing]
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Created:
Updated:
Size: