Closed Bug 1205052 Opened 9 years ago Closed 8 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: 8 years ago
Resolution: --- → WORKSFORME
You need to log in before you can comment on or make changes to this bug.