User-Agent: Mozilla/5.0 (Macintosh; U; PPC Mac OS X Mach-O; en; rv:18.104.22.168pre) Gecko/20080118 Camino/1.6b2 (like Firefox/22.214.171.124pre) Build Identifier: Mozilla/5.0 (Macintosh; U; PPC Mac OS X Mach-O; en; rv:126.96.36.199pre) Gecko/20080118 Camino/1.6b2 (like Firefox/188.8.131.52pre) My installed version of Firefox 184.108.40.206 has same problem. Safari works. It appears I have the latest Shockwave Flash 9.0 r115. Related system log warnings?: /Applications/Camino.app/Contents/MacOS/Camino: can't map file: /Library/Internet Plug-Ins/AdobePDFViewer.plugin ((os/kern) invalid argument) /Applications/Camino.app/Contents/MacOS/Camino: can't map file: /Library/Internet Plug-Ins/PDF Browser Plugin.plugin ((os/kern) invalid argument) /Applications/Camino.app/Contents/MacOS/Camino: can't map file: /Library/Internet Plug-Ins/Flash Player.plugin ((os/kern) invalid argument) Reproducible: Always Steps to Reproduce: 1. Load URL 2. Depress flash block icon twice. 3. Actual Results: Nothing renders. Expected Results: Animated ad page. I'm reloading the flash component now, will report any changes after reboot.
Reloading Flash didn't change problem. Flash is working ok on other web pages. This Mac is running 10.3.9 PPC OSX...
I see this, too; the circular loads fine when Flashblock is disabled. Philip, do you have any insight into this?
I notice that this only started to happen between Firefox 220.127.116.11 and 18.104.22.168, and does not occur on trunk (minefield & suiterunner). I am investigating but it might be some change in the way that Gecko handles <object> vs <embed>.
Created attachment 304435 [details] Test flashblock.xml This is interesting. The test case comprises an embed wrapped in an object (The outer object has an activeX classid so Firefox ignores this). In Firefox 1.5 and Firefox 22.214.171.124 and Minefield when Flashblock activates, it blocks the outer object removing the whole nested construct from the DOM, and that's all to it. In Firefox 126.96.36.199pre, Flashblock fires twice, once for the outer <object> and once for the inner <embed>. However our object blocking code also processes the inner <embed> so on 188.8.131.52+ the inner <embed> is messed up by being run over by our code twice. I've done some testing and decided that processing the inner embed from the object processing code isn't necessary so I've commented out that part. The flashblock.xml I am attaching will allow you to unblock the test case successfully (on BonEcho) however you will need to click on the Flashblock placeholder twice, once to unblock the outer <object> and then again to unblock the inner <embed>. For DeerPark and Minefield, only one click is necessary.
Boris, any insights on Comment #4 ?
Nope. Can you hunt down a branch regression range, perhaps?
Created attachment 304918 [details] [diff] [review] flashblock.xml Fix for Gecko 184.108.40.206 This patch fixes the problem with the test case URL in Firefox 220.127.116.11pre. Needs to be verified on Camino. Smokey, I don't know who the Camino reviewers are. Please suggest a suitable reviewer. Thanks.
I still think we need to figure out the regression range so we can tell what changed, and whether it was supposed to.
I think we'll probably want to take this fix/work-around for Camino 1.6b3 and then spin off a separate bug on the actual Gecko regression once we have the range, given our timeframe for 1.6b3. I'll try to do some checking on the range this weekend (as well as testing the work-around/patch).
Comment on attachment 304918 [details] [diff] [review] flashblock.xml Fix for Gecko 18.104.22.168 Putting this in my queue so I don't forget to test....
Comment on attachment 304918 [details] [diff] [review] flashblock.xml Fix for Gecko 22.214.171.124 This works on the site in question (with the two-click caveat from comment 4) and doesn't appear to do anything bad on other blocked Flash I tested.
Created attachment 305243 [details] [diff] [review] Philip's work-around patch plus README additions This is just a combined patch for recordkeeping and sr-ing; it's Philip's patch above plus a change to the README, and destined for the branch only (and hopefully only temporarily).
As I was afraid, this "broke" on branch in Camino the day when we upgraded from Flashblock 126.96.36.199 to Flashblock 1.5.5+regression fixes (2008-01-04 00:00 build; bug 410290). I don't have any branch Firefoxen around locally, so checking there with a constant current Flashblock will take me much longer (yay slow ftp.mo).
Er, that is, the "second click doesn't show at all" issue. The "requires two clicks" issue is older than that. Which regression is the one we're interested in (or are we interested in both)?
(In reply to comment #14) > The "requires two clicks" issue is older than that. Works: CaminoBranch-2007-09-30-01 Fails: CaminoBranch-2007-10-01-01 http://bonsai.mozilla.org/cvsquery.cgi?treeid=default&module=Camino&branch=MOZILLA_1_8_BRANCH&branchtype=match&dir=&file=&filetype=match&who=&whotype=match&sortby=Date&hours=2&date=explicit&mindate=2007-09-30+01%3A00&maxdate=2007-10-01+01%3A00&cvsroot=%2Fcvsroot Boris, that's you and XBL bug 267833, bug 373756, bug 394676, and bug 394014, according the bonsai. Camino was using Flashblock 1.5.3 at that point (just missed having the 188.8.131.52 upgrade in the window by 2 days!), if it matters.
> Boris, that's you and XBL bug 267833, bug 373756, bug 394676, and bug 394014, > according the bonsai. But it wasn't a problem on trunk? How come not?
Comment on attachment 305243 [details] [diff] [review] Philip's work-around patch plus README additions (In reply to comment #4) > the inner <embed> is messed up by being run over by our code twice. Wouldn't it be safer (from a standpoint of not inadvertently regressing other Flash constructions) to leave this code in place, but have it check for the presence of embedsrc (or for src==fakeURI)?
> Wouldn't it be safer (from a standpoint of not inadvertently regressing other > Flash constructions) to leave this code in place, but have it check for the > presence of embedsrc (or for src==fakeURI)? Not really. The block of code commented out implements part of our InstaBlock[TM] strategy to prevent even an initial brief flash of flash as our XBL kicks in (we have a 10ms timeout to prevent gecko crashing). I did a regression test with http://bugzilla.mozdev.org/attachment.cgi?id=4560 (which is an embed wrapped in an object) and InstaBlock appears to be still effective. The flashblock XML has grown organically over the course of time and there is a lot of interdependent code there. I had a look at your suggestion but I couldn't get it to work without having to invest too much time. And if bz can fix the regression, the point is moot anyway.
> But it wasn't a problem on trunk? How come not? As far as I can tell (reading through the bugs) some/much of the combined patch is branch only.
Boris is this comment relevant? https://bugzilla.mozilla.org/show_bug.cgi?id=267833#c54
Hmm... That's possible, I suppose...
Comment on attachment 305243 [details] [diff] [review] Philip's work-around patch plus README additions Okay, we can take this for b3 and see if another solution is available before 1.6 final.
I checked in the patch on the MOZILLA_1_8_BRANCH for b3. Since the problem reported here is fixed (well, worked-around) on the Camino side, I'm going to go ahead and close this bug. Now that we've identified the Core regression/regression range, I think we should move that data into a new Core bug to track that problem specifically. Philip, can you file that?
Camino 1.5.6 is not happening.
I've been having this problem too. It seems more random on the sites I visit, however. When I click on the placeholder, sometimes it will display flash file perfectly and other times it will show nothing but an empty space. Reloading the page often fixes the problem. Disabling flashblock and reloading the page always fixes the problem.
Kenny, please file a new bug; what you're describing is different from this bug.
Sorry.. Um, I'm not sure how to file a new bug as I'm rather new to this. But I'll try.