Flash-based circular on OfficeDepot.com not displayed after clicking Flashblock placeholder

RESOLVED FIXED

Status

Camino Graveyard
Annoyance Blocking
RESOLVED FIXED
10 years ago
9 years ago

People

(Reporter: allen middleton, Assigned: Philip Chee)

Tracking

({fixed1.8.1.13})

Details

(URL)

Attachments

(2 attachments, 1 obsolete attachment)

(Reporter)

Description

10 years ago
User-Agent:       Mozilla/5.0 (Macintosh; U; PPC Mac OS X Mach-O; en; rv:1.8.1.12pre) Gecko/20080118 Camino/1.6b2 (like Firefox/2.0.0.12pre)
Build Identifier: Mozilla/5.0 (Macintosh; U; PPC Mac OS X Mach-O; en; rv:1.8.1.12pre) Gecko/20080118 Camino/1.6b2 (like Firefox/2.0.0.12pre)

My installed version of Firefox 2.0.0.11 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.
(Reporter)

Comment 1

10 years ago
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?
Component: Page Layout → Annoyance Blocking
QA Contact: page.layout → annoyance.blocking
Summary: Flash ad on Officemax.com not rendered. → Flash-based circular on OfficeDepot.com not displayed after clicking Flashblock placeholder
(Assignee)

Comment 3

10 years ago
I notice that this only started to happen between Firefox 2.0.0.10 and 2.0.0.12, 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>.
Status: UNCONFIRMED → NEW
Ever confirmed: true
(Assignee)

Comment 4

10 years ago
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 2.0.0.0 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 2.0.0.13pre, 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 2.0.0.12+ 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.
(Assignee)

Comment 5

10 years ago
Boris, any insights on Comment #4 ?
Nope.  Can you hunt down a branch regression range, perhaps?
(Assignee)

Comment 7

10 years ago
Created attachment 304918 [details] [diff] [review]
flashblock.xml Fix for Gecko 1.8.1.12

This patch fixes the problem with the test case URL in Firefox 2.0.0.13pre. 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).
Flags: camino1.6b3?
Flags: camino1.5.6?
Comment on attachment 304918 [details] [diff] [review]
flashblock.xml Fix for Gecko 1.8.1.12

Putting this in my queue so I don't forget to test....
Attachment #304918 - Flags: review?(alqahira)
Comment on attachment 304918 [details] [diff] [review]
flashblock.xml Fix for Gecko 1.8.1.12

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.
Attachment #304918 - Flags: review?(alqahira) → review+
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).
Attachment #304918 - Attachment is obsolete: true
Attachment #305243 - Flags: superreview?(stuart.morgan)
As I was afraid, this "broke" on branch in Camino the day when we upgraded from Flashblock 1.5.4.1 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 1.5.4.1 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 17

10 years ago
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)?
(Assignee)

Comment 18

10 years ago
> 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.
(Assignee)

Comment 19

10 years ago
> 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.
(Assignee)

Comment 20

10 years ago
Boris is this comment relevant? https://bugzilla.mozilla.org/show_bug.cgi?id=267833#c54
Hmm... That's possible, I suppose...

Comment 22

10 years ago
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.
Attachment #305243 - Flags: superreview?(stuart.morgan) → superreview+
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?
Assignee: nobody → philip.chee
Flags: camino1.6b3? → camino1.6b3+
Keywords: fixed1.8.1.13
Version: unspecified → 1.8 Branch
Status: NEW → RESOLVED
Last Resolved: 10 years ago
Resolution: --- → FIXED
Camino 1.5.6 is not happening.
Flags: camino1.5.6? → camino1.5.6-

Comment 25

9 years ago
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.

Comment 27

9 years ago
Sorry.. Um, I'm not sure how to file a new bug as I'm rather new to this. But I'll try.
You need to log in before you can comment on or make changes to this bug.