Closed Bug 652300 Opened 13 years ago Closed 11 years ago

Flash bypasses Flashblock on Tumucumaque but not on Namaroka

Categories

(Core Graveyard :: Plug-ins, defect)

2.0 Branch
x86
Windows 7
defect
Not set
normal

Tracking

(Not tracked)

RESOLVED WORKSFORME

People

(Reporter: philip.chee, Assigned: johns)

References

()

Details

(Keywords: regression)

This might turn out to be a Flashblock bug in the end, but it was working fine on Firefox 3.6.x

Main page: http://sports.sina.com.cn/g/2011-04-12/12465530498.shtml
Narrow down the test case to one iframe:
http://pfp.sina.com.cn/iframe/sports/2008-03-31/161730.html

1. The latter is a rotating ad so you might need to hit refresh several times. *Some* flash slips through especially the one for M18.com.
2. All rotating ads are consistently blocked on Firefox 3.6
3. The Ad is *sometimes* blocked on Firefox 4.0.1. It seems to depend on how long it takes to load the page.
4. It appears to be due to some combination of document.write and element.innerHTML and sometimes seems to involve using document.write() to generate <script> tags which then generate the Flash elements.

So it might be the DOM parser buggering up Flashblock, or the order in which <script>s load (especially if inserted into the DOM via document.write) or something completely different.

As far as I can tell turning off the HTML5 parser and/or turning off JIT doesn't have any effect on this bug so I'm totally lost.

Help me Obiwan Zbarsky, you're my only hope!
Note Flashblock still works fine with static html markup.
Can you bisect?  That's more likely to get us somewhere than anything else...
> Can you bisect?
Right. I should have thought of that first.
Last good:
Mozilla/5.0 (Windows NT 6.1; WOW64; rv:2.0b8pre) Gecko/20101013 Firefox/4.0b8pre
http://hg.mozilla.org/mozilla-central/rev/f6e81dd5a125

First bad:
Mozilla/5.0 (Windows NT 6.1; WOW64; rv:2.0b8pre) Gecko/20101014 Firefox/4.0b8pre
http://hg.mozilla.org/mozilla-central/rev/ad0a0be8be74

Regression range:
http://hg.mozilla.org/mozilla-central/pushloghtml?fromchange=f6e81dd5a125&tochange=ad0a0be8be74
There's a tracemonkey merge in the middle of the regression range so I don't know how to bisect futher.

Turning off hardware acceleration has no effect. Still broken in the current nightly:
Mozilla/5.0 (Windows NT 6.1; WOW64; rv:7.0a1) Gecko/20110626 Firefox/7.0a1
Bisect on tracemonkey nightlies?
But chances are, you'll just find the huge wrapper rewrite.....  Still worth checking.
> Bisect on tracemonkey nightlies?
Sorry for the stupid question, but what sort of date range should I look at? I have no idea how tracemonkey developement works.
The initial end of the range can be the date of that merge.  The beginning of the range.... I think Oct 1 (the date of the first changeset in the TM merge) should still work.
i was about to report this happening on daily motion pages,

any progress?
> any progress?
Sorry as Boris says I (or someone needs to go through the tracemonkey nightlies from 1st Oct to 13 October in the hopes of finding the patch/change which caused this problem. Unfortunately I haven't had the time to do this yet.

Boris/Anybody, where can I find the tracemonkey nightlies anyway?
Same place as any other nightly, basically.  Load http://ftp.mozilla.org/pub/mozilla.org/firefox/nightly/2010/10/ and search for the directories with "tracemonkey" in the name.
is the problem found?
in which version will this be fixed?

click_to_play might help?
Please forgive me whilst I start with a small complaint. I was so relieved to finally find a bug that not only matched the issue that I have experienced since 4.0, but that had members of the mozilla community actively engaging in getting to the bottom of it. This issue has been the main reason I have steadfastly refused to upgrade from 3.6.

And as you can imagine with the recent, IMO heavyhanded, mechanisms introduced in the auto-update facilities to force users off of 3.6, it has been a difficult and frustrating exercise averting the upgrade (eg. the UAC of Windows 7(/Vista) saves me, because I refuse the privilege elevation. I don't think I could have fought that fight on XP).

In any case, I have performed the bisection discussed above. I've come to these conclusions on last good/bad:

Last good:
http://ftp.mozilla.org/pub/mozilla.org/firefox/nightly/2010/10/2010-10-10-05-tracemonkey/firefox-4.0b8pre.en-US.win32.zip

First bad:
http://ftp.mozilla.org/pub/mozilla.org/firefox/nightly/2010/10/2010-10-11-05-tracemonkey/firefox-4.0b8pre.en-US.win32.zip

My test case is with this URL:
http://smh.drive.com.au/motor-news/deals-on-wheels-a-to-v-of-newcar-bargains-20120615-20dmh.html

With the Last good, you can refresh as many times as you want, and the first advertisement on the right hand side (under a heading stating "Advertisement") will be blocked by Flashblock each time.

With Fist bad, if not on the initial load, a few refrehes should reproduce where the (flash) advertisement is not blocked.

If this issue could be resolved, I would be greatly appreciative. I am not sure if I would be game enough to stay on the rapid release line of versions, but at least I can find a post 3.6 version that I am comfortable with and supress auto update on that (until whatever concerns me on the rapid release line is sorted out).

Thanks in advance.
theres a chance the work being done in bug 745030 might fix things here
Depends on: 745030
I'm not too sure if bug 745030 is related. I have discovered that nightlies have a fix for this. And I applied bisection, to the best of my knowledge (I'm not familiar with which streams of build I should be looking at).

I have found this:

Last bad:

http://ftp.mozilla.org/pub/mozilla.org/firefox/nightly/2012/05/2012-05-04-03-05-09-mozilla-central/firefox-15.0a1.en-US.win32.zip

First good (again):

http://ftp.mozilla.org/pub/mozilla.org/firefox/nightly/2012/05/2012-05-04-12-29-39-mozilla-central/firefox-15.0a1.en-US.win32.zip

That would seem to place the fix too early for bug 745030. I do wonder which bug fix was involved. It may be even be a type of duplicate of this. I'll have a go at trying to work it out from hg.
Shaddy Baddah, thanks for doing those bisections!  For future reference, the changeset URL from about:buildconfig is usually more useful than the link to the build for finding the regression range.

In any case the range in comment 13 is http://hg.mozilla.org/tracemonkey/pushloghtml?fromchange=edb0506b0c23&tochange=0a667876b6fd which is mostly the compartment landing. 

The range from comment 15 is http://hg.mozilla.org/mozilla-central/pushloghtml?fromchange=2db9df42823d&tochange=9ebf3dc839c5 which includes two inbound merges...  Bug 751641 in there _might_ be relevant.  Not sure.

In any case, over to plug-ins.
Component: DOM: Core & HTML → Plug-ins
QA Contact: general → plugins
Just to add further clarification... a consistent test that I have found for this is using the link http://smh.drive.com.au/. On first load of this page, the topmost Flash advert on the right hand side is blocked, even in the Bad builds. A reload of the page will result in the advert not being blocked in the Bad builds only.

I've tested this on two separate Windows 7 machines, and I have also just verified that Debian Iceweasel 8.0 presents the problem. It seems likely to me that the ranges apply to the Linux builds as well, placing the bug in non-architecture code.

As the nightlies now seem to have the problem resolved, I guess the primary aim now is to have the reporter verify that?

I'll keep my fingers crossed that an understanding of how the bug crept in, and then crept back out, is achieved. By myself or someone from the community.
(In reply to Shaddy Baddah from comment #17)
> As the nightlies now seem to have the problem resolved, I guess the primary
> aim now is to have the reporter verify that?
> 
> I'll keep my fingers crossed that an understanding of how the bug crept in,
> and then crept back out, is achieved. By myself or someone from the
> community.

Bug 745030 and its numerous followups should have resolved a few issues that could cause flash to bypass content policy. If someone can verify that this doesn't reproduce in FF17, then that was almost certainly the fix.
Assignee: nobody → jschoenick
Since I haven't heard of any recent reports I'm taking the liberty of closing this as WFM.
Status: NEW → RESOLVED
Closed: 11 years ago
Resolution: --- → WORKSFORME
Product: Core → Core Graveyard
You need to log in before you can comment on or make changes to this bug.