Closed Bug 1205052 Opened 9 years ago Closed 9 years ago

Videos don't play (conflict with FlashStopper add-on)

Categories

(Core :: DOM: Security, defect)

Product:
Core
Component:
DOM: Security
Version:
43 Branch
Type:
defect
Priority:
Not set
Severity:
major

Tracking

()

Status:
RESOLVED WORKSFORME

People

(Reporter: streetwolf52, Unassigned)

References

Details

(Keywords: regression)

User Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:43.0) Gecko/20100101 Firefox/43.0 Build ID: 20150914163022 Steps to reproduce: Install the bad cset below: Good : https://hg.mozilla.org/integration/mozi ... 8cff31d3c0 Bad : https://hg.mozilla.org/integration/mozi ... 719c0a762b Actual results: Play some videos. Either there is just an empty frame or clicking on the Play arrow does nothing. Scrolling through pictures such as on http://www.msn.com/en-us/movies/gallery/25-years-since-goodfellas-where-are-they-now/ss-AAeh4C5 causes high CPU utilization. Expected results: Videos should play and CPU should not reach high utilization levels.
Group: firefox-core-security → core-security
Severity: normal → major
Component: Untriaged → Graphics
Priority: -- → P1
Product: Firefox → Core
Group: core-security
pushlog: https://hg.mozilla.org/integration/mozilla-inbound/pushloghtml?fromchange=0577b78a0aae398d93d6cfeb1c096f8cff31d3c0&tochange=2c9f4d2e77fabd283b530a0c34bd21719c0a762b From this, it seems much more likely that this is caused by a media checkin of sorts, rather than gfx, but let's not jump to conclusions -> back to core::untriaged. Gary, can you provide a link to an example video? cpearce, any chance you can look into this?
Component: Graphics → Untriaged
Flags: needinfo?(garyshap)
Flags: needinfo?(cpearce)
Keywords: regression
Priority: P1 → --
Any video over at weather.com will do.
Flags: needinfo?(garyshap)
Forget the video at msn.com. That doesn't work even with a new profile with the good cset. Must be something wrong with the site.
Did more testing. Video problem looks like it is add-ons related. Haven't yet narrowed it down but I will. Still something changed that conflicts with an add-on. As far as the high CPU goes I'll see if I still get that without my add-ons.
The video problem appears to be a conflict with the add-on FlashStopper. I should have tested this obvious potential culprit. However, the high CPU still happens when I go through the Good Fellows pictures I gave a link for in my OP. It's the Plug-in container for Nightly that has the high CPU.
Video problem is definitely a conflict with FlashStopper. Wonder if the other Flash Blocking add-ons have the same issue? The high CPU looks like another issue. When I disable e10s the high cpu appears under Nightly in Task Manager. With e10s it's in the plugin container, no doubt the tab.
High CPU happens in Safe-Mode. I mentioned the problem I'm having with the developer of FlashStopper. I'll see what he says. After some more testing I might open up a bug report regarding the high cpu utilization.
I don't see any HTML5 videos on the Goodfellas page. I have Flash disabled. I don't see how this could be HTML5 video related. Clearing need-info.
Flags: needinfo?(cpearce)
As I said, the video problem is a conflict with an add-on I use, FlashStopper. The High CPU is a different issue. The good fellows picture montage produces the high cpu, nothing to do with videos. I get high cpu on other pages too.
This report probably could be closed unless you want to leave the video portion open because of the conflict with an add-on. The High CPU, with further testing, might necessitate a new bug report.
(In reply to Gary [:streetwolf] from comment #12) > This report probably could be closed unless you want to leave the video > portion open because of the conflict with an add-on. Do we know what causes the issue here? Have you tried narrowing the regression range further?
Flags: needinfo?(garyshap)
Summary: Videos don't play and high CPU utilization. → Videos don't play (conflict with FlashStopper add-on)
I see you already have the patches in my regression range.
How exactly can I narrow it down to a particular patch? Btw... Problem is on Nightly.
I ran a build off of the try server and the problem still happens with FS. Here's the patch in the build which falls in my regression range. Could be the culprit. https://hg.mozilla.org/try/pushloghtml?changeset=edcc44141138
I worked with the developer of FlashStopper and he came up with a fix. First off he saw this in the browser console: Security Error: Content at http://www.cnn.com/videos/us/2015/09/16 ... h-pkg.wjla may not load or link to chrome://flashstopper/content/bindings.xml. From this he deduced that adding this line to his chrome.manifest would fix the problem and it did: Add after the first line: content flashstopper chrome/content/ contentaccessible=yes Just wondering if any other add-ons will also have the same problem.
Component: Untriaged → DOM: Security
This also breaks Image Toolbar. Adding 'contentaccessible=yes' to the chrome.manifest also fixed it. https://addons.mozilla.org/en-us/firefox/addon/image-toolbar/
Bobby/Christoph, any idea what's going on here?
Flags: needinfo?(mozilla)
Flags: needinfo?(bobbyholley)
This is almost certainly the result of https://hg.mozilla.org/try/rev/e7433b2cc02b Christoph, can you fill us in on what's going on with that patch?
Flags: needinfo?(bobbyholley)
(In reply to Bobby Holley (:bholley) from comment #21) > This is almost certainly the result of > https://hg.mozilla.org/try/rev/e7433b2cc02b > > Christoph, can you fill us in on what's going on with that patch? Benjamin and Jonas have a deeper understanding of the xblservice code which we updated within Bug 1195162. Can any of you provide some guidance?
Flags: needinfo?(jonas)
Flags: needinfo?(benjamin)
That patch is part of an effort to harmonize and simplify our security checks. It used to be that *all* chrome:// URLs were accessible to content as long as it was loaded as XBL, and as long as the link to it came from a chrome:// stylesheet. This meant that we used different policies for chrome:// URLs depending on if a resource was loaded as a script, as an XBL or as a stylesheet. The goal is that any content that can be loaded into a webpage needs to have a contentaccessible=yes, no matter how it is loaded. And so any content which does not have contentaccessible=yes is sure to not be loaded into a webpage.
(In reply to Jonas Sicking (:sicking) from comment #23) > That patch is part of an effort to harmonize and simplify our security > checks. > > It used to be that *all* chrome:// URLs were accessible to content as long > as it was loaded as XBL, and as long as the link to it came from a chrome:// > stylesheet. > > This meant that we used different policies for chrome:// URLs depending on > if a resource was loaded as a script, as an XBL or as a stylesheet. > > The goal is that any content that can be loaded into a webpage needs to have > a contentaccessible=yes, no matter how it is loaded. And so any content > which does not have contentaccessible=yes is sure to not be loaded into a > webpage. Ok. How much addon bustage are we willing to swallow as a result? If this is already hitting us on Nightly it might be a lot, but possibly not all that much (the set of addons that load XBL bindings in content is relatively small, I think).
I started a conversation in bug 1195162 about this.
(In reply to Jonas Sicking (:sicking) from comment #25) > I started a conversation in bug 1195162 about this. Thanks Jonas - clearing needinfo.
Flags: needinfo?(mozilla)
(In reply to Bobby Holley (:bholley) from comment #24) > > Ok. How much addon bustage are we willing to swallow as a result? If this is > already hitting us on Nightly it might be a lot, but possibly not all that > much (the set of addons that load XBL bindings in content is relatively > small, I think). this also causes firefox bustage since after rejecting the xbl bindings the elements (video & flash objects in this case) did not work...
(In reply to yochai meltzer from comment #27) > (In reply to Bobby Holley (:bholley) from comment #24) > > > > Ok. How much addon bustage are we willing to swallow as a result? If this is > > already hitting us on Nightly it might be a lot, but possibly not all that > > much (the set of addons that load XBL bindings in content is relatively > > small, I think). > > this also causes firefox bustage since after rejecting the xbl bindings the > elements (video & flash objects in this case) did not work... In what cases (on a clean profile with no add-ons)? Can you provide a testcase? All the videos here ( http://www.quirksmode.org/html5/tests/video.html ), for instance, wfm on current nightly.
Flags: needinfo?(yochay)
(In reply to Gijs Kruitbosch (gone until Tue 22 Sep) from comment #28) > > In what cases (on a clean profile with no add-ons)? Can you provide a > testcase? All the videos here ( > http://www.quirksmode.org/html5/tests/video.html ), for instance, wfm on > current nightly. when the add-on binding fails the html elements (at least for video and flash objects) don't work (this is why this bug is reported as "Videos don't play") to reproduce install https://addons.mozilla.org/firefox/downloads/file/345312/flashstopper-e10s-1.2.6b2-fx.xpi?src=version-history and try youtube or your link.
Flags: needinfo?(yochay)
I believe that this is because we now don't let web content trigger chrome XBL unless the chrome package has contentaccessible set on it.
Flags: needinfo?(benjamin)
(In reply to yochai meltzer from comment #29) > (In reply to Gijs Kruitbosch (gone until Tue 22 Sep) from comment #28) > > > > In what cases (on a clean profile with no add-ons)? Can you provide a > > testcase? All the videos here ( > > http://www.quirksmode.org/html5/tests/video.html ), for instance, wfm on > > current nightly. > > when the add-on binding fails the html elements (at least for video and > flash objects) don't work (this is why this bug is reported as "Videos don't > play") > > to reproduce install > https://addons.mozilla.org/firefox/downloads/file/345312/flashstopper-e10s-1. > 2.6b2-fx.xpi?src=version-history and try youtube or your link. Right, so only with those add-ons installed...
This item is on our Regression list. Please see below Build ID 20160315030230 User Agent Mozilla/5.0 (Windows NT 5.1; rv:48.0) Gecko/20100101 Firefox/48.0 Extensions [Firefox Hello Beta 1.1.12; FlashStopper 1.4.2; Multi-process staged rollout 1.0; Pocket 1.0] Start Windows Task Manager Play Videos: http://www.quirksmode.org/html5/tests/video.html All options play, CPU and MemUsage, for firefox.exe and plugin-container.exe never maxed, -no errors to report @ this time
Flags: needinfo?(gijskruitbosch+bugs)
(In reply to Michelle Funches - QA from comment #32) > This item is on our Regression list. Please see below > Build ID 20160315030230 > User Agent Mozilla/5.0 (Windows NT 5.1; rv:48.0) Gecko/20100101 Firefox/48.0 > Extensions [Firefox Hello Beta 1.1.12; FlashStopper 1.4.2; Multi-process > staged rollout 1.0; Pocket 1.0] > Start Windows Task Manager > Play Videos: http://www.quirksmode.org/html5/tests/video.html > All options play, CPU and MemUsage, for firefox.exe and plugin-container.exe > never maxed, -no errors to report @ this time Sounds like the add-on got fixed? Gary?
Flags: needinfo?(gijskruitbosch+bugs) → needinfo?(garyshap)
Yeah, all fixed.
Flags: needinfo?(garyshap)
Status: UNCONFIRMED → RESOLVED
Closed: 9 years ago
Resolution: --- → WORKSFORME
You need to log in before you can comment on or make changes to this bug.