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)
Tracking
()
RESOLVED
WORKSFORME
People
(Reporter: Natch, Unassigned)
References
()
Details
Attachments
(1 file)
(deleted),
text/html
|
Details |
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?
Comment 1•16 years ago
|
||
Testcase?
Reporter | ||
Updated•16 years ago
|
Reporter | ||
Comment 2•16 years ago
|
||
(In reply to comment #1)
> Testcase?
In the url.
Comment 3•16 years ago
|
||
Testcase WFM on a trunk nightly... Video starts loading, controls appear on mouseover, and clicking play makes it start.
Comment 4•16 years ago
|
||
Odd, I can confirm this on Vista, but it works fine on OSX.
Reporter | ||
Comment 5•16 years ago
|
||
(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.
Reporter | ||
Comment 6•16 years ago
|
||
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
Comment 7•16 years ago
|
||
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.
Reporter | ||
Comment 8•16 years ago
|
||
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+
Priority: -- → P2
Flags: blocking1.9.1+ → wanted1.9.1+
Reporter | ||
Comment 9•16 years ago
|
||
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.
Reporter | ||
Comment 10•15 years ago
|
||
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.
Reporter | ||
Comment 11•15 years ago
|
||
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.
Description
•