Closed Bug 479253 Opened 16 years ago Closed 15 years ago

Script added (document.write) videos destroy video controls

Categories

(Core :: Audio/Video, defect, P2)

x86
Windows Vista
defect

Tracking

()

RESOLVED WORKSFORME

People

(Reporter: Natch, Unassigned)

References

()

Details

Attachments

(1 file)

If a script writes in a video the video controls are hidden on start and cannot be pulled up with the same error in bug 470852. In fact it throws as soon as it gets a mouseover and doesn't stop.
Flags: blocking1.9.1?
Testcase?
(In reply to comment #1) > Testcase? In the url.
Testcase WFM on a trunk nightly... Video starts loading, controls appear on mouseover, and clicking play makes it start.
Odd, I can confirm this on Vista, but it works fine on OSX.
(In reply to comment #4) > Odd, I can confirm this on Vista, but it works fine on OSX. That makes sense since I'm on Vista. Branch and trunk are somewhat different though, trunk gives me all the errors while branch just doesn't automatically (or ever for that matter) show them (note that this is not an autoplay video).(In reply to comment #3) > Testcase WFM on a trunk nightly... Video starts loading, controls appear on > mouseover, and clicking play makes it start. Even that seems wrong given that this is not an autoplay video, it should show them from the start.
fwiw this is the error I get on trunk: Error: Permission denied for <file://> to get property XULElement.style from <file://>. Source File: chrome://global/content/bindings/videocontrols.xml Line: 305 Mozilla/5.0 (Windows; U; Windows NT 6.0; en-US; rv:1.9.2a1pre) Gecko/20090219 Minefield/3.2a1pre
Really line 304, off by one? 303 if (this.fadingIn) 304 this.controlBar.style.visibility = "visible"; 305 },(In reply to comment #5) > (In reply to comment #4) > Even that seems wrong given that this is not an autoplay video, it should show > them from the start. It does, I was just saying they fade in and out as expected.
Well it's line 305 with my patch for bug 478982 because I add an extra line, sorry about that. I also get an error on line 323 with the same message.
Flags: blocking1.9.1? → blocking1.9.1+
Flags: blocking1.9.1+ → wanted1.9.1+
Mozilla/5.0 (Windows; U; Windows NT 6.0; en-US; rv:1.9.2a1pre) Gecko/20090501 Minefield/3.6a1pre Mozilla/5.0 (Windows; U; Windows NT 6.0; en-US; rv:1.9.1b5pre) Gecko/20090501 Shiretoko/3.5b5pre This has gotten *a lot* better on trunk and branch, occasionally they do break and I'll get some errors, but it's not totally broken anymore, yay! The thumb and time do not update though, at least the video plays.
Attached file testcase (deleted) —
This is working nearly perfectly! Everything in this file works just fine, occasionally, though, when I use a javascript: url to replace a page with document.write it will fail. The url on this bug is a good testcase for that, but you have to _replace_ a page with it, not open a new tab with it (like bugzilla does). I'll open a new bug for that, this one is WFM.
Mozilla/5.0 (Windows; U; Windows NT 6.0; en-US; rv:1.9.1.1) Gecko/20090715 Firefox/3.5.2 Mozilla/5.0 (Windows; U; Windows NT 6.0; en-US; rv:1.9.2a1pre) Gecko/20090807 Minefield/3.6a1pre ->WORKSFORME
Status: NEW → RESOLVED
Closed: 15 years ago
Resolution: --- → WORKSFORME
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Created:
Updated:
Size: