Placeholders of blocked images not being shown

[WalterWW]

Platform: Debian/Iceweasel
Option "Hide placeholders of blocked elements" is unchecked in ublock.
Dynamic filtering set to block all 3rd-party content by default.

When I go to a website that has embedded third-party images, I do not see a placeholder. Example screenshot of what it looks like on http://dilbert.com/strip/2015-02-23:

http://i.imgur.com/KgNJilf.png

For comparison, this is what it looks like with Requestpolicy:

http://i.imgur.com/AZiEXn5.png

This is definitely a little bit annoying, because on some pages it is not so obvious that there should be an image, and there is no easy way to tell if something other than ads has been blocked.

And as a follow up to this issue I would like to suggest the following related feature:

The option to show placeholders of blocked elements should only apply to blocked dynamic filtering requests, but not to blocked elements from the filter list.
My reasoning here is that most people are probably never interested in seeing placeholders of blocked ads, but they would most likey prefer to see blocked images such as the one in my example above.

[gorhill]

Ok, I see. I set visibility to hidden when an element is blocked through a network request. I should just not apply any style when no collapse is demanded.

[chrisaljoudi]

@gorhill is it as simple as removing this line?

[gorhill]

Almost. I have the fix locally, but I want to be sure it's the right thing to do (feature-wise).

[WalterWW]

Testing this in 0.8.8.5-dev.3 I get the following results:

'Hide placeholders' enabled:

'Hide placeholders' disabled:

It's definitely unhiding something, as can be seen by the difference in the screenshots, but it's still not showing a placeholder for the missing image.

[gorhill]

Looks to me we are dealing with a browser-specific behavior. With Chromium, the browser respects the declared image size, 900 x 280. Firefox disregards the declared size and collapses, this is not uBlock doing this.

Edit: Actually, the size with Chromium is 850 x 850. I don't know where that comes from. In any case, uBlock doesn't touch the target element at all when "Hide placeholder of blocked.." is not selected, so whatever the outcome is browser-specific.

[WalterWW]

Damn, that sucks :(

So I was curious to see how Requespolicy handles this, as it "correctly" displays the 850x850 container, just as ublock apparently does with Chromium.

What I noticed is that ublock leaves the original 3rd-party source of the image intact, but prevents the image from loading: http://i.imgur.com/imcXSNi.png

Requestpolicy on the other hand replaces the source of the image with an inline data image instead: http://i.imgur.com/LmtgRFo.png

Could that be what's causing the different results?

[WalterWW]

I found some more information on the issue here:

https://stackoverflow.com/questions/14396356/force-firefox-to-render-empty-image-within-dimensions-specified-by-css

It indeed seems to be a Firefox specific behaviour, where it doesn't keep the specified dimensions for the image if it fails to load.

[WalterWW]

Is this issue still on your radar, gorhill? Or do you think this isn't something that should be addressed in ublock?

For what it's worth, it was reason enough for me to go back to my trusty RP/ABP combo, because working placeholders are essential to my browsing habits.

[gorhill]

Wait I thought I was commenting for #942.

The issue here is browser-specific, and I don't feel like creating code patch because of that one Firefox-specific issue.

[gorhill]

Note that you could as well ask Firefox devs to have Firefox behave like how Chromium behaves.

[WalterWW]

Okay, just checking.

Unfortunately different browsers also have slightly different behaviours and other quirks, and this will always be the case. You essentially said that you don't care to make this particular functionality of ublock work in all the supported browsers, which is your decision. At least I now know that as a firefox user who relies on placeholders, I don't need to check back anytime soon.

Don't get me wrong, I still think you're doing a great job with ublock regardless, and I hope you keep up the good work :)

[gorhill]

you don't care to make this particular functionality of ublock work in all the supported browsers

The functionality is there, it's just Firefox rendering the placeholder differently. You could as well say Firefox doesn't care rendering the placeholder like other browsers.

[WalterWW]

Yes, you are semantically correct. Still, the functionality is not there when using ublock in firefox.

Anyway, I don't feel like arguing. I just wanted to know whether this is something that's still on your radar or not, to which I now have an answer.

[gorhill]

By the way, RequestPolicy embed a 1-pixel gif if I remember correctly, so it is kind of hacky as the result is Firefox ending up displaying a 850px x 850px placeholder... is this part of documented standards? There is no guarantee other browsers would give the same result. So I stick to not introduce voodoo code and rather fallback on whatever a browser decides.

[WalterWW]

I have no idea if there are any standards documenting this behaviour. All I know is ublock placeholders don't work in firefox, which is unfortunate, but such is life.

[WalterWW]

For the sake of completeness: Firefox Mobile handles unloaded images the same way as the desktop version, which means there are no placeholders with ublock.

[gorhill]

there are no placeholders with ublock

There are placeholders, they just happen to be differently shaped than what you would want, that is just how the browser renders them.

[WalterWW]

No, there are no visible placeholders. I have no idea what exactly your obsession with semantics is about regarding this issue, and I don't care. From the point of view of the user this is broken in firefox. And from the point of view of the user it doesn't matter if it's the browser's fault or not, it's just broken. Other addons display placeholders correctly in firefox, while ublock does not.

But seeing that nobody else seems to care about placeholders in the first place, leaving this broken probably doesn't matter much.

[gorhill]

obsession with semantics

The difference is that you should file an issue with Firefox: if a network request for an image is blocked for whatever reasons (hosts file for example), you will get the same result, i.e. regardless it was blocked by uBlock or not.

[WalterWW]

No. I only have this problem with ublock, so I'm reporting it here. If you for some reason want to be stubborn about it, then that's none of my business. There are other addons for firefox which work exactly the way one would expect and actually show placeholders for blocked images.

[gorhill]

want to be stubborn about it

It's common sense. Try hosts file = placeholders rendered same way. Are you going to file an issue with the hosts file maintainer for how Firefox renders its placeholders? uBlock has to deal with many browsers on many platforms, with different behaviors, and has to go along with other add-ons on these other browsers and platforms. For instance, look at NoScript preventing uBlock from collapsing the blocked frames: not everybody is happy about this. So the bottom line is: do not interfere with the DOM if it can be avoided. Letting the placeholders render as intended by the browser is the safest approach.

[WalterWW]

This will be my last reply regarding this isse, because you're obviously smart enough to understand the problem at hand without me explaining it to you. Anyway...

Try hosts file = placeholders rendered same way.

A hosts file has a completely different purpose than a dynamic blocker inside the browser: Blocking an url in the hosts files means I don't want my computer to connect to that url, ever. Nobody is going to add an url to the hosts file just so they can remove it and add it again on a per-site basis. That's ridiculous because it's a complete pain in the ass and that's why we have content blocker addons for the browser, which are supposed to make this easier for the user!

uBlock has to deal with many browsers on many platforms

So? There is tons of browser specific code in ublock already. What makes this issue different other than the fact that you think that every browser should behave exactly the same way chrome does for some reason.

Fix it or leave it, it's your thing not mine.

[gorhill]

There is tons of browser specific code in ublock already

Silly hyperbole. Not in the platform-independent code, which is what we are talking about here.

[WalterWW]

That's what you're talking about. All I'm talking about is that ublock doesn't show placeholders in firefox and firefox mobile, and thus that functionality is broken from the point of view of the user.

I'm not here to argue with you, so I'll definitely stop here now, as I have said all I have to say regarding this.

[gorhill]

ublock doesn't show placeholders in firefox and firefox mobile, and thus that functionality is broken from the point of view of the user

I will answer just for the benefit of other readers who may end up being misled by such a false statement:

The placeholders are shown.

uBlock just doesn't override the browser's default rendering of the placeholders. Not having custom placeholders is not equal to not having placeholders.