499829 - Camino (2.0b4pre) Adblock blocks Group-Radio of last.fm

Status: RESOLVED FIXED

(Camino Graveyard :: Annoyance Blocking, defect)

Description

[Mehmet]

User-Agent:       Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.5; en; rv:1.9.0.12pre) Gecko/2009062200 Camino/2.0b4pre (like Firefox/3.0.12pre)
Build Identifier: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.5; en; rv:1.9.0.12pre) Gecko/2009062200 Camino/2.0b4pre (like Firefox/3.0.12pre)

Hello Camino-Team,

the Adblock of Camino Version 2.0b4pre (1.9.0.12pre 2009062200) blocks Group-Radios of last.fm

*see steps to reproduce*

Reproducible: Always

Steps to Reproduce:
1. activate adblock

2. go to link http://www.lastfm.de/listen/group/Hip-Hop%20%26%20R%27n%27B#pane=webRadioPlayer&station=%2Flisten%2Fgroup%2FHip-Hop%20%26%20R%27n%27B


Actual Results:  
Group-Radio doesn't play.

Expected Results:  
Group-radio should play

Deactivating the adblocker resolves the problem.

Comment 1

[Smokey Ardisson (offline for a while; not following bugs - do not email)]

Mehmet, do you still have this problem?  I tried to reproduce this, and I get audio and video when I follow your link (and I see no difference in the page appearance when I turn ad-blocking off).

Comment 2

[Mehmet]

Attachment: hardcopy

Hi Smokey.

Yes, the problem is still existing by me (see attachment).

Are you redirected to the German Domain (.de), too?

I tried to use .com, but I'm always redirected to the German Domain .de :-(

Comment 3

[Smokey Ardisson (offline for a while; not following bugs - do not email)]

Yeah, I'm on lastfm.de when I follow your link, and I don't see that.  I'll need you to get me the generated source of the page, I think.

Can you 

1) Go to https://www.squarefree.com/bookmarklets/webdevel.html#generated_source and drag the "generated source" link to your Bookmark Bar
2) Go to last.fm
3) Click on the "generated source" item in your Bookmark Bar (this should spawn a new window or tab with HTML source (except it has more than what view-source shows)
4) Copy/paste the displayed HTML source into a plain-text file and attach it to this bug

From there I *should* be able to figure out what's being blocked and what rule is causing it to be blocked; I'm guessing something is served slightly differently depending on IP address.

Comment 4

[Mehmet]

Attachment: generated source

Hey. I attached the source of the last.fm-link.

Thanks for your help. :-)

Comment 5

[Smokey Ardisson (offline for a while; not following bugs - do not email)]

I can reproduce the problem using the generated source, so confirming.

Comment 6

[Smokey Ardisson (offline for a while; not following bugs - do not email)]

So the problem here appears to be that the url of the player is an iframe with the url starting "http://www.lastfm.de/ads.php".  It looks like almost the same HTML+JS is in what I see when I visit the site (and don't see the player blocked), so I'm not sure what's different.

iframe[src*="/ads."] is a very legitimate rule, so I'd rather not simply remove it; I'd also rather not get in a whack-a-mole game whitelisting various last.fm domains around the world.

Adding 

div[id*="Player"] * iframe[src*="/ads."]

to the general whitelist seems to unbreak the player display (it doesn't play locally, ad-blocking off or on) and could possibly be used to prevent similar types of issues where online player apps have their content set to be ad-related iframes.

philippe, what do you think about that?

Comment 7

[philippe (part-time)]

(In reply to comment #6)
 
> div[id*="Player"] * iframe[src*="/ads."]
> 
> to the general whitelist seems to unbreak the player display (it doesn't play
> locally, ad-blocking off or on) and could possibly be used to prevent similar
> types of issues where online player apps have their content set to be
> ad-related iframes.


That would work yes. The iframe is unblocked, but I can only assume the content will load...
(I noticed that the ad scripts inside the iframe are coming from doubleclick)

One request: you could loosen the universal selector (*); that is one hell of a performance killer.

div[id*="Player"] iframe[src*="/ads."] works out OK for the sample page;
else
div[id*="Player"] div iframe[src*="/ads."]

Comment 8

[Smokey Ardisson (offline for a while; not following bugs - do not email)]

Fixed on cvs trunk by the checkin for bug 485865.  Thanks philippe for your help on these!

Comment 9

[Mehmet]

Attachment: hardcopy No2

Hey Smokey.

Should the lastfm-player work with build Version 2.0b4pre (1.9.0.12pre 2009070600) ??

If yes, it doesn't play the radio :-( But the player in the frame is to see, now. See attached pic.

Or will it be fixed complete in tomorrows build (2009070700) ?

Thanks in advance

Mehmet

Comment 10

[Smokey Ardisson (offline for a while; not following bugs - do not email)]

Hmm, I'm not sure what else is going on here.  Attachment 386237 [details] didn't play for me even with ad-blocking off and the site itself wasn't ever blocked for me, so it's going to be hard to debug :(

Comment 11

[philippe (part-time)]

I can't see the live page, as it apparently requires a login/pw - which I don't have :-).
When I tested the attached sample code, no movie/music played, but I assumed that the site is doing some same-origin checking.

Is it possible that ads inside or overlaying the player block everything. As I noted above, the content of the iframe is based on scripts coming from doubleclick (and they may be doing some location detection).

Mehmet, do you have Flashblock turned on ?
At the top of the block where the whole player should display, there is a 1px flashmovie with source: http://cdn.last.fm/webclient/pixel/49/lfmPlayer.swf

I thought that was some kind of web-tracking thing though.

Otoh, the are a few more (hidden) iframes with id starting with 'LastAd_'. It is not clear how those relate to video/music playing though.

I'll attach the source of the (offending ?) iframe as seen by Firebug

Comment 12

[philippe (part-time)]

Attachment: iframe source

based on Attachment 386237 [details]

Comment 13

[Mehmet]

@philippe: Flashblock is turned off !!! Only the Webblocker and the PopUpblocker are turned on.

Regards
Mehmet

Comment 14

[Smokey Ardisson (offline for a while; not following bugs - do not email)]

Mehmet, I think the best way to proceed here is for you to debug this locally, since you're the only one who can reproduce the problem. :(

The best way I can think of is to open Camino.app/Contents/Resources/ad_blocking.css in a text editor, comment out half of the CSS rules in the "{ display: none ! important }" section, toggle ad-blocking off and back on, and see if the player plays.  If it plays, then the problematic rule is in that half; if it doesn't, uncomment that half and comment out the other half.  Then repeat the process with whichever half seems to be causing it, and then half of that, and so forth, until you (hopefully) get down to one rule that's the problem.

Comment 15

[Mehmet]

Hi Smokey,

wow... okay... I solve the problem :-)

I removed the following rule and it works:



/* turn some false positives back off */

div[id*="Player"] iframe[src*="/ads."]

{ display: inline ! important }


Is this a important rule for the Adblock feature?


For your info: Crash-Log 7bd1b31a-e641-4326-8a39-39a262090728 from today was caused by me while playing in the css-file and loading the last.fm station :-)


REGARDS

Mehmet

Comment 16

[Smokey Ardisson (offline for a while; not following bugs - do not email)]

That rule was added to fix this; that's bizarre that taking it out completely fixes it.  The rule is "broken", though; it needs to go in its own block because it's a block element.

If you remove the current 'div[id*="Player"] iframe[src*="/ads."]', and add 

div[id*="Player"] iframe[src*="/ads."]
{ display: block ! important }

after that '{ display: inline ! important }', does the player work?

Comment 17

[Smokey Ardisson (offline for a while; not following bugs - do not email)]

(In reply to comment #15)

> For your info: Crash-Log bp-7bd1b31a-e641-4326-8a39-39a262090728 from today was
> caused by me while playing in the css-file and loading the last.fm station :-)

That's a Flash bug, bug 494448 ;)

Comment 18

[Mehmet]

Smokey, I go crazy with this Group-Radio-Player.

Removing the rule from my comment#15 has only an effect, when the lastfm site is loaded the very first time (after resetting Camino or deleting cookies)!!! 

When I go after visiting the last.fm station to caminobrowser.org for example and after that again to the lastfm station the player doesn't play... It only works again, when I delete the cookies...

Same affect, without removing the rule or changing the rule like in your comment#16

I give it up... :-(

Mehmet

Comment 19

[philippe (part-time)]

Mehmet, does the player work in a similar situation if you don't block ads?

Comment 20

[Mehmet]

Hi Philippe.

I test it just now... No. When I disable the Abblocker and do the same steps (1. last.fm, 2. caminobrowser.org, 3. lastfm.org ) the player works fine.

Comment 21

[Mehmet]

@Smokey & Philippe: Without Adblocking I see, that the Ad-Stream comes from cdn1.eyewonder.com

I deleted the following block rule from the css file now:

embed[type="application/x-shockwave-flash"][src^="http://cdn"][src*=".eyewonder.com"],


I will test it if it works now !!!

Comment 22

[Mehmet]

Attachment: Adstream+Musicplayer in one window

Hi !

Okay, it seems, that removing the rule 

embed[type="application/x-shockwave-flash"][src^="http://cdn"][src*=".eyewonder.com"], 

has the effect, that the player is loading always now :-)

Every otherthing in the css file is "original" (rule from Comment#15 is NOT removed!!)

But... there is one more thing :) When the Adstream is finished, the Music player should start in the same Player. But there is another effect. See attachment. This is caused by the rule from comment#15. But if I remove it too, or change it like in comment#16 the player doesnt play...

What for a crazy world :)

Comment 23

[philippe (part-time)]

(In reply to comment #22)

Oh my... :-(((
They probably have a script inside the flashplayer that injects a second <object> or <embed> after the publicity has played.

If you still have energy, can you try the following:
1. turn OFF adblocking
2. turn ON Flashblock.
3. load the page, the main part of the page will -I suppose- show the blocked flash movie.
4. unblock and wait for the advertisement to play (:-()
5. when the bottom part of your screen shot in comment 22 comes up, does it show a blocked flash movie ? If yes :
6. **Don't** unblock it, but mouse over it, it should show a tooltip.
7. try to take note of the url it shows in the tooltip (pen and paper...).

8. Try to get the generated source (as in comment 3) at the moment both the ad and second movie show (bottom part of your screenshot in comment 22) - I don't know if it will be any different from what you have attached before, though.

> What for a crazy world :)
yeah, it is getting ugly out there.

Comment 24

[Mehmet]

Attachment: generated code of the Adstream with flashblock

Comment 25

[Mehmet]

Attachment: generated code of the Group Radio with Flashblock

Comment 26

[Mehmet]

Hi Philippe:

The Source of the blocked Adstream is: http://cdn1.eyewonder.com/200125/758193/1100039/lastFM.swf

Comment 27

[Mehmet]

Attachment: Screenshot with Dom-Inspector

The id of the iframe where the adstream is to see is "LastAd_PreRoll" i think.

Perhaps it helps ?!?!?!?!?! 

Thanks and advance 
Mehmet

Comment 28

[Mehmet]

(In reply to comment #17)
> (In reply to comment #15)
> 
> > For your info: Crash-Log bp-7bd1b31a-e641-4326-8a39-39a262090728 from today was
> > caused by me while playing in the css-file and loading the last.fm station :-)
> 
> That's a Flash bug, bug 494448 ;)

Smokey, don't be shocked: there is a handful Crashreports caused by me on last.fm again (while playing in the adblock css file) which are send to breakpad...

Comment 29

[philippe (part-time)]

Mehmet, thanks for your patience, and for the source code. :-)

OK, I think I understand what is going on.
The iframe loads an ad (flash), when the ad has played, it calls some javascript that
a. changes the display property for the iframe to 'none'
b. changes the display property for the div that contains the actual lastFM player to 'block'.

and of course, if the adstream loaded in the iframe doesn't play, the js is never called. And we override the display property of the iframe.

::sigh::

Let's try an über-hack

don't change anything in the existing code; I tested with the latest ad_blocking.css file after bug 502536 landed.

add at the bottom of ad_blocking.css

@moz-document domain(lastfm.de) {
	html embed[type="application/x-shockwave-flash"][src^="http://cdn"][src*=".eyewonder.com"] {
	display: inline-block !important;
	}
	iframe[id="LastAd_PreRoll"] {
	position:absolute !important;
	z-index:-10 !important;
	}
	div#webRadioPlayer-visualisation {
	height:320px !important;
	}
}

(Basically, I hide the iframe behind the rest of the player and remove it out of the document flow).

Dance 3 times around the shrine to Mamon (!Important :-)), hope the stars align, toggle ad-blocking off/on, load your lastFM page, and hopefully enjoy you music stream.

Comment 30

[philippe (part-time)]

oopsie, small typo:

> @moz-document domain(lastfm.de)
should be

@-moz-document domain(lastfm.de)

Comment 31

[Mehmet]

Puhhh.... Good work Philippe !!! :-)))))

It works perfect now !!! Thank you very much !!! Many thanks to Smokey, too !!!

Info: Now, the Adstream before beginning of the Group-Radio-Stream is NO more to see, only to hear in an empty player. But I think I (we) can live with it :-) 

Regards
Mehmet

Comment 32

[philippe (part-time)]

Attachment: tentative patch

Smokey, is this a way to go for ad_blocking.css ?

Short explanation:
line 1 makes the adstream visible again (overrides an earlier rule)
line 2 takes the iframe out of the document flow and then sends it packing behind the whole construction (we can't set it to display:none, as it prevents the whole system to work).
line 3 forces the height on the player, avoids a visual redraw when the ad-stream finishes playing.


(In reply to comment #31)
 
> Info: Now, the Adstream before beginning of the Group-Radio-Stream is NO more
> to see, only to hear in an empty player. But I think I (we) can live with it
> :-) 

Yeah, that is something I can't control. From the moment the Adstream is required to play in order for the music stream to load, you'll have to listen to it.

Comment 33

[Smokey Ardisson (offline for a while; not following bugs - do not email)]

(In reply to comment #32)

> Smokey, is this a way to go for ad_blocking.css ?

> > Info: Now, the Adstream before beginning of the Group-Radio-Stream is NO more
> > to see, only to hear in an empty player. But I think I (we) can live with it
> > :-) 

I think this part is likely to be confusing ("where's the ad that's making this noise!?") to users other than Mehmet (who was here for the whole process).

I think for ad_blocking.css, we should just unbreak the player entirely (line 1?), and anyone who wants to hide the adstream (such as Mehmet) can put lines 2 and 3 in a userContent.css or the like.

Also, isn't line 1 fragile in the face of changing ad providers/sources?  Wouldn't something like 

iframe[id="LastAd_PreRoll"] > embed[type="application/x-shockwave-flash"] { display: block !important}

be more robust (that may not be the right CSS--I got lost in the page long ago--but you get the idea)?

And, thank you for figuring this out!

Comment 34

[philippe (part-time)]

(In reply to comment #33)
> (In reply to comment #32)

> I think this part is likely to be confusing ("where's the ad that's making this
> noise!?") to users other than Mehmet (who was here for the whole process).
> 
> I think for ad_blocking.css, we should just unbreak the player entirely (line
> 1?), and anyone who wants to hide the adstream (such as Mehmet) can put lines 2
> and 3 in a userContent.css or the like.

1. we make the iframe visible in such a way that it can't be hidden anymore by scripts - so you end up with the situation attachment (id=391279), comment 22 above.
 
> Also, isn't line 1 fragile in the face of changing ad providers/sources? 
> Wouldn't something like 
> 
> iframe[id="LastAd_PreRoll"] > embed[type="application/x-shockwave-flash"] {
> display: block !important}
> 
> be more robust (that may not be the right CSS--I got lost in the page long
> ago--but you get the idea)?

2. you cannot target the content of an iframe that way, because it is in a separate document (iframe loads xxx.html that loads the embed).
(an html5 parser may help, on condition that the right attributes are set on the iframe (seamless integration), but that is future stuff.)

A workaround is to allow/unblock all and any embed[type="application/x-shockwave-flash"] on lastFM.de. Looking at the sample pages provided width ad_blocking off FlashBlock ON, that would show a few more ads around the page.

3. But I agree it is confusing. Maybe, but I need to test the idea still, instead of sending the iframe behind everything, it will work by overlaying the div that contains the actual music stream on top.

Comment 35

[Smokey Ardisson (offline for a while; not following bugs - do not email)]

(In reply to comment #34)

> A workaround is to allow/unblock all and any
> embed[type="application/x-shockwave-flash"] on lastFM.de. Looking at the sample
> pages provided width ad_blocking off FlashBlock ON, that would show a few more
> ads around the page.

Any chance those are in sane <div>s that we could then re-block? :P

Boy, they sure are making it more difficult for us to block ads these days.

Comment 36

[philippe (part-time)]

(In reply to comment #35)

> Any chance those are in sane <div>s that we could then re-block? :P

Checked. Afaik, all ads are served inside iframes with id starting with 'LastAd_' & src starting with "http://www.lastfm.de/ads.". All those are blocked.

But simply unblocking on embed[type="application/x-shockwave-flash"] won't work, due the specificity of the previous embed[attr] selectors

embed[type="application/x-shockwave-flash"] specificity: 11
embed[type="application/x-shockwave-flash"][src^="http://cdn"][src*=".eyewonder.com"] specificity: 31

hmm, I think this should work (specificity: 32)
   html embed[type="application/x-shockwave-flash"][width][height] { display: inline !important }

 
> Boy, they sure are making it more difficult for us to block ads these days.

Yeah, it is getting real ugly; and I suspect we'll get more of those constructs.

Comment 37

[philippe (part-time)]

Attachment: patch v2

This unbreak the player by allowing the flash ads to play (unblocks all and any embed[] on LastFM.de). Most ads will be invisible (they play in blocked iframes), except the one in the player.

If a user (Mehmet) wants to hide to add while it plays, and avoid that double movie when the ad has played, they can add the following to usercontent.css:

@-moz-document domain(lastfm.de) {
iframe[id="LastAd_PreRoll"] {
position: absolute !important;
z-index: -10 !important;
}
div#webRadioPlayer-visualisation {
height: 320px !important;
}
}

Comment 38

[Smokey Ardisson (offline for a while; not following bugs - do not email)]

Comment on attachment 393095 [details] [diff] [review]
patch v2

This looks good.  What's the status on the double-ad or double-player or double-whatever situation with this change, though?

Comment 39

[philippe (part-time)]

(In reply to comment #38)
> (From update of attachment 393095 [details] [diff] [review])
> This looks good.  What's the status on the double-ad or double-player or
> double-whatever situation with this change, though?
The ad stream  will be visible while playing, and when finished, you'll have that double construct in attachment (id=391279).

Comment 40

[Smokey Ardisson (offline for a while; not following bugs - do not email)]

Comment on attachment 393095 [details] [diff] [review]
patch v2

OK.  It's a shame we can't do anything (other than not block ads at all like this), but that's life.

Stuart, see comment 32 et seq for the dilemma we have here. It's a lesser-of-two-evils or less-confusing-of-two-bad-deals problem, but if you think "hiding ad but playing its audio" is better than "showing the ad with its audio, but duplicate players  afterward" (e.g. attachment 391279 [details]), let us know. ;)

Comment 41

[Stuart Morgan]

Comment on attachment 393095 [details] [diff] [review]
patch v2

sr=smorgan; I'm still confused, but I'll trust that you guys understand it ;)

Why the bizarre line break after display: though?

Comment 42

[philippe (part-time)]

Attachment: patch v3

patch for checkin with line-break removed.

Comment 43

[Smokey Ardisson (offline for a while; not following bugs - do not email)]

Landed on CAMINO_2_0_BRANCH and cvs trunk with the line-break removed.

Comment 44

[Smokey Ardisson (offline for a while; not following bugs - do not email)]

Fixed for 1.6.9 by the rollup patch on bug 502536.