Closed
Bug 708431
Opened 13 years ago
Closed 13 years ago
Video controls fail to initialize if an extension implementing nsIContentPolicy is present (e.g. Adblock Plus, NoScript, GreaseMonkey)
Categories
(Core :: Audio/Video, defect)
Core
Audio/Video
Tracking
()
VERIFIED
FIXED
mozilla12
Tracking | Status | |
---|---|---|
firefox8 | --- | unaffected |
firefox9 | --- | unaffected |
firefox10 | --- | unaffected |
firefox11 | + | verified |
People
(Reporter: epinal99-bugzilla2, Assigned: jaws)
References
()
Details
(Keywords: regression, verified-beta, Whiteboard: [qa!] [testday-20120203])
Attachments
(4 files, 2 obsolete files)
109.81 KB,
image/png
|
Details | |
146.20 KB,
image/png
|
Details | |
1.40 KB,
application/x-xpinstall
|
Details | |
4.54 KB,
patch
|
bzbarsky
:
review+
roc
:
review+
akeybl
:
approval-mozilla-aurora+
|
Details | Diff | Splinter Review |
User Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:11.0a1) Gecko/20111207 Firefox/11.0a1
Build ID: 20111207031110
Steps to reproduce:
1/ Update Nightly to the latest version and create a new profile
2/ Install add-on Adblock Plus (adding a blocklist subscription is not necessary)
3/ Go to http://video.webmfiles.org/elephants-dream.webm (WebM video)
Actual results:
The video starts but the control bar (start/pause, timeline, sound level, fullscreen buttons) is hidden and it's impossible to display the statistics by right clicking on the video.
Restart the Nightly in safe mode and video overlays are visible again.
Expected results:
Add-on Adblock Plus should'nt have to block WebM video overlays.
Component: General → Video/Audio
Product: Firefox → Core
Comment 3•13 years ago
|
||
This isn't limited to Adblock Plus - the same thing happens with any extension using content policies. I've attached a minimal nsIContentPolicy implementation (does nothing but log nsIContentPolicy calls), the problem is reproducible with this extension as well. I see two exceptions in the Error Console that are apparently related:
Error: Permission denied for <http://video.webmfiles.org> to get property Object.dynamicControls
Source File: chrome://global/content/bindings/videocontrols.xml
Line: 452
Error: this.Utils is undefined
Source File: chrome://global/content/bindings/videocontrols.xml
Line: 307
Video controls fails to initialize because of these, everything else is just follow-up errors.
Comment 4•13 years ago
|
||
Confirming (reproduced in the current Firefox 11.0a1 nightly on Windows 7 x64) and tweaking summary. This is a regression, Firefox 8 works fine.
Blocks: abp
Status: UNCONFIRMED → NEW
Ever confirmed: true
Keywords: regression
Summary: Add-on Adblock Plus blocks WebM video overlays (control bar, statistics) → Video controls fail to initialize if an extension implementing nsIContentPolicy is present
Updated•13 years ago
|
Keywords: regressionwindow-wanted
Wladimir, thanks for clarifying the bug issue.
In addition I observed a weird side-effect of this bug when the video is embedded into a webpage like http://www.mozilla.org/projects/firefox/prerelease.html (OGV video, no autoplay).
STR:
1/ Start the latest Nightly in safe mode with new profile and add-on Adblock Plus.
2/ Open 2 tabs:
++ 1st tab: open http://www.mozilla.org/projects/firefox/prerelease.html (embedded video, no autoplay)
++ 2nd tab: open http://videos-cdn.mozilla.net/serv/qa/qa-360p-mp4.theora.ogv (direct video link, autoplay)
In both tabs, video controls are visible.
3/ Close Nightly and restart it normally (NO safe mode).
4/ Even if Adblock Plus is enabled, the 1st tab DISPLAYS video controls on embedded video and the 2nd tab doesn't display video controls on direct video (according to this bug).
5/ Restart Nightly normally a 2nd time, in both tabs, video controls are not displayed (according to this bug).
![]() |
||
Comment 6•13 years ago
|
||
Regression range with STR of comment #0 and Minimal content policy of comment #3 .
Regression window(m-c)
Works:
http://hg.mozilla.org/mozilla-central/rev/fd478c02c29c
Mozilla/5.0 (Windows NT 6.1; WOW64; rv:11.0a1) Gecko/20111115 Firefox/11.0a1 ID:20111115110849
Fails:
http://hg.mozilla.org/mozilla-central/rev/3ea216303184
Mozilla/5.0 (Windows NT 6.1; WOW64; rv:11.0a1) Gecko/20111115 Firefox/11.0a1 ID:20111115135750
Pushlog:
http://hg.mozilla.org/mozilla-central/pushloghtml?fromchange=fd478c02c29c&tochange=3ea216303184
Regression window(fx-team)
Works:
http://hg.mozilla.org/integration/fx-team/rev/7e1f046b173b
Mozilla/5.0 (Windows NT 6.1; WOW64; rv:11.0a1) Gecko/20111110 Firefox/11.0a1 ID:20111110040711
Fails:
http://hg.mozilla.org/integration/fx-team/rev/15c2cf2f47f4
Mozilla/5.0 (Windows NT 6.1; WOW64; rv:11.0a1) Gecko/20111111 Firefox/11.0a1 ID:20111111040857
Pushlog:
http://hg.mozilla.org/integration/fx-team/pushloghtml?fromchange=7e1f046b173b&tochange=15c2cf2f47f4
Triggered by;
Bug 700856 and Bug 700854
![]() |
||
Comment 7•13 years ago
|
||
P.S.; I think the problem step 5 of comment #5 is different bug, and maybe Bug 701662.
![]() |
||
Updated•13 years ago
|
Keywords: regressionwindow-wanted
(In reply to Alice0775 White from comment #7)
> P.S.; I think the problem step 5 of comment #5 is different bug, and maybe
> Bug 701662.
Thanks for pointing it, that's exactly I'm meeting in your comment https://bugzilla.mozilla.org/show_bug.cgi?id=701662#c19
Comment 9•13 years ago
|
||
Also if you right click and use the controls of the menu the controls don't work.
Updated•13 years ago
|
OS: Windows 7 → All
Hardware: x86_64 → All
Comment 11•13 years ago
|
||
Requesting "tracking-firefox11", as this is a regression in Firefox 11 (which is migrating from Nightly to Aurora in a few days).
status-firefox10:
--- → unaffected
status-firefox8:
--- → unaffected
status-firefox9:
--- → unaffected
tracking-firefox11:
--- → ?
Version: 11 Branch → Trunk
Updated•13 years ago
|
Summary: Video controls fail to initialize if an extension implementing nsIContentPolicy is present → Video controls fail to initialize if an extension implementing nsIContentPolicy is present (e.g. Adblock Plus, NoScript, GreaseMonkey)
Comment 12•13 years ago
|
||
Bug 711675 is probably related.
![]() |
||
Comment 14•13 years ago
|
||
Hmm. Are we now ending up with content policy checks (for the external stylesheet) before we've set up the script global for the document? That's what's caused this problem in the past....
Jared, are you owning this?
Assignee | ||
Comment 16•13 years ago
|
||
(In reply to Boris Zbarsky (:bz) from comment #14)
> Hmm. Are we now ending up with content policy checks (for the external
> stylesheet) before we've set up the script global for the document? That's
> what's caused this problem in the past....
> Jared, are you owning this?
I think this is over my head. Would the changes necessary be in videocontrols.xml or lower level?
![]() |
||
Comment 17•13 years ago
|
||
It would need to be fixed in the code that starts the loads, so in this case in VideoDocument::CreateSyntheticVideoDocument
Basically, that code runs _very_ early, before the window for the document has been created. Doing anything in there that might execute script (including starting loads of any sort) is unsafe. So in particular, the patch for bug 700854 is wrong.
Maybe we could change the timing of that call to also happen during SetScriptGlobalObject just like the document-element-inserted notification. Someone who understands this code would need to check that. The other option is to just postpone the stylesheet load until after we have a script global.
Updated•13 years ago
|
QA Contact: general → video.audio
Assignee | ||
Comment 18•13 years ago
|
||
s/videocontrols.xml/VideoDocument.cpp in comment #16
Thanks for the pointers Boris. I can try to take this bug.
Assignee: nobody → jwein
Status: NEW → ASSIGNED
Comment 19•13 years ago
|
||
Might bug 693206 help to avoid this? Easy enough to try, I suppose.
Assignee | ||
Comment 20•13 years ago
|
||
(In reply to Justin Dolske [:Dolske] from comment #19)
> Might bug 693206 help to avoid this? Easy enough to try, I suppose.
I've tried simply replacing the <field> with a <property>, but I didn't notice any change.
Assignee | ||
Comment 21•13 years ago
|
||
I have installed the minimal content policy add-on that was attached to this bug.
Before this patch, the browser would hang when visiting a webm file directly (in debug mode).
After this patch, the video now loads but the controls still fail to appear. When I hover over the video, this warning message prints to the console. It seems to print to the console for every mouse movement.
> WARNING: NS_ENSURE_TRUE(piTarget) failed: file c:/mozilla-central/obj-dir/content/events/src/../../../../content/events/src/nsEventDispatcher.cpp, line 531
I have also made the same change for ImageDocuments, under the assumption that if it was bad to do this for VideoDocuments, then we should probably fix it in ImageDocuments also.
Attachment #583947 -
Flags: feedback?(bzbarsky)
Assignee | ||
Comment 22•13 years ago
|
||
Comment on attachment 583947 [details] [diff] [review]
WIP of patch for bug 708431
Clearing review, I forgot to call SetScriptGlobalObject on the MediaDocument.
Attachment #583947 -
Flags: feedback?(bzbarsky)
Assignee | ||
Comment 23•13 years ago
|
||
Attachment #583953 -
Flags: review?(bzbarsky)
Assignee | ||
Comment 24•13 years ago
|
||
Comment on attachment 583953 [details] [diff] [review]
Patch for bug 708431
I added the call to MediaDocument::SetScriptGlobalObject and the warning is now gone. I've tested this with the "Minimal content policy for testing" attachment and the controls with and without the addon enabled.
Attachment #583953 -
Flags: review?(roc)
Assignee | ||
Updated•13 years ago
|
Attachment #583947 -
Attachment is obsolete: true
![]() |
||
Comment 25•13 years ago
|
||
Comment on attachment 583953 [details] [diff] [review]
Patch for bug 708431
You should probably only do the LinkStylesheet thing when setting the script global, not when unsetting it.
Attachment #583953 -
Flags: review?(bzbarsky) → review-
Assignee | ||
Comment 26•13 years ago
|
||
Only linking the stylesheet when the script global is being set.
Attachment #583953 -
Attachment is obsolete: true
Attachment #583953 -
Flags: review?(roc)
Attachment #584000 -
Flags: review?(roc)
Attachment #584000 -
Flags: review?(bzbarsky)
Attachment #584000 -
Flags: review?(roc) → review+
Updated•13 years ago
|
status-firefox11:
--- → affected
Assignee | ||
Comment 27•13 years ago
|
||
(In reply to Jared Wein [:jwein and :jaws] from comment #26)
> Created attachment 584000 [details] [diff] [review]
> Patch for bug 708431 v1.1
bz: review ping?
![]() |
||
Comment 28•13 years ago
|
||
Comment on attachment 584000 [details] [diff] [review]
Patch for bug 708431 v1.1
r=me. Silly holidays!
Attachment #584000 -
Flags: review?(bzbarsky) → review+
Assignee | ||
Comment 29•13 years ago
|
||
Whiteboard: [fixed-in-fx-team]
Comment 30•13 years ago
|
||
Status: ASSIGNED → RESOLVED
Closed: 13 years ago
Resolution: --- → FIXED
Whiteboard: [fixed-in-fx-team]
Target Milestone: --- → mozilla12
Assignee | ||
Comment 31•13 years ago
|
||
Comment on attachment 584000 [details] [diff] [review]
Patch for bug 708431 v1.1
[Approval Request Comment]
Regression caused by (bug #): bug 700854
User impact if declined: Video controls won't work, and a small memory leak is introduced (bug 711675).
Testing completed (on m-c, etc.): This has been on m-c since 1/8.
Risk to taking this patch (and alternatives if risky): No risks that I know of.
Attachment #584000 -
Flags: approval-mozilla-aurora?
Comment 32•13 years ago
|
||
Comment on attachment 584000 [details] [diff] [review]
Patch for bug 708431 v1.1
[Triage Comment]
Low risk - approving for aurora.
Attachment #584000 -
Flags: approval-mozilla-aurora? → approval-mozilla-aurora+
Assignee | ||
Comment 33•13 years ago
|
||
Comment 34•13 years ago
|
||
Mozilla/5.0 (Windows NT 5.1; rv:11.0) Gecko/20100101 Firefox/11.0
Verified the fix on the above builds: Adblock Plus, NoScript(select "Allow all on the page") and Greasemonkey don't block the display of video controls.
Marking as VERIFIED
Comment 35•13 years ago
|
||
(In reply to Mihaela Velimiroviciu [QA] from comment #34)
> Mozilla/5.0 (Windows NT 5.1; rv:11.0) Gecko/20100101 Firefox/11.0
>
> Verified the fix on the above builds: Adblock Plus, NoScript(select "Allow
> all on the page") and Greasemonkey don't block the display of video
> controls.
> Marking as VERIFIED
Forgot the Mac and Ubuntu builds:
Mozilla/5.0 (Macintosh; Intel Mac OS X 10.6; rv:11.0) Gecko/20100101 Firefox/11.0
Mozilla/5.0 (X11; Linux x86_64; rv:11.0) Gecko/20100101 Firefox/11.0
You need to log in
before you can comment on or make changes to this bug.
Description
•