Unable to save image via "save image as..." in Google Chrome

[Lain_13]

Environment

Google Chrome Version 41.0.2272.118 m
Windows 7 x64
Adblock Plus 1.8.12

How to reproduce

1. Add filter: $third-party,object,subdocument,domain=pornolab.net
2. Open this page: ​http://pornolab.net/forum/viewtopic.php?t=1936956
3. Right-click on the image on the right side and select "Save image as..."

Observed behaviour

Save image window will not appear. Red counter on the ABP icon will increment by 1.

Expected behaviour

Save image window should appear.

[sebastian]

Well, this behavior comes from Chrome. IMO it should behave the same when the request was blocked, as when it failed loading for other reasons. In the latter case a dialog to save the web page instead the image shows up, also not that great but certainly better than no feedback at all. Feel free to file a ​Chrome bug.

[Lain_13]

Seems like for testing purposes $object is enough.

[Lain_13]

The problem here is that image is not blocked when displayed on the page.

Does Chrome perform separate download request when attempting to save an image and this time with type "other", and as result it gets blocked by $object due to workaroud in ABP for known Chrome bug (object requests have type other)?

Is there a way to avoid blocking requests made by browser in such case? Maybe by source of such request?

[sebastian]

I see. That makes sense. Unless the request has been cached, the original image data aren't available later. So Chrome has to issue another request to download the image again, if the user saves it via the context menu. That request doesn't occur in an image context but is reported as other and therefore blocked by your filter. But still, I consider it a Chrome bug that nothing happens when clicking "Save image as ..." in this case.

You could whitelist requests of the type other with the exception rule @@||*$other. however, this won't be limited to images downloaded via the context menu, but also effect other requests that don't have a dedicated type. If there would be a dedicated type for those kind of requests they wouldn't be reported as other. However, one could argue that those requests should be reported with the type image instead. But again, feel free to file a Chrome bug and try to convince the Chromium team.

[Lain_13]

I don't get it. What is the point to fire a Chrome bug if Chrome won't be able to request that image anyway since ABP will block it? Maybe Chrome's lack of reaction on failed attempt to request a file is wrong and it have to show at least something instead of save image dialog, but the main issue will remain and user still won't be able to save an image.

Is it possible to detect requests originated from the browser itself? Since this behavior triggers with $third-party,object I assume that it has some browser-specific source which ABP can detect and avoid blocking.

[sebastian]

Replying to Lain_13:

I don't get it. What is the point to fire a Chrome bug if Chrome won't be able to request that image anyway since ABP will block it?

Chrome could still do better than doing nothing if that request blocked, falling back to saving the whole page (as it does when the image failed to load before) or showing a meaningful error message. Also as I alternatively suggested, Chrome could report those requests with the type image as well. So if the image isn't blocked while loading the page it would neither be blocked when saving it.

Is it possible to detect requests originated from the browser itself? Since this behavior triggers with $third-party,object I assume that it has some browser-specific source which ABP can detect and avoid blocking.

No, extensions can't reliably detect whether a request was initiated outside of the context of rendering and running a page. The type indicates the context in which the request were initiated. If the type is image the request were issued to show an image on a page, if it is xmlhttprequest it's a request sent by JavaScript code and so on. However, if the requests doesn't classify as one of the few categories defined by Chrome, it is reported as other. However, this isn't limited to special requests issued by the browser independently of the page's behavior.

[Lain_13]

I doubt they will implement any kind of complex check for the resource type on the attempt to save it to report proper type to the extensions, but they may add type "browser" to all browser requests. However, I'm afraid that my attempt to report this issue to Chrome will lack technical details since I have no idea how APB intercepts queries in the Chrome and where it looks for requests types. Could you please report it there instead of me?

[sebastian]

Replying to Lain_13:

I doubt they will implement any kind of complex check for the resource type on the attempt to save it to report proper type to the extensions, but they may add type "browser" to all browser requests.

Even if we could identify those kind of requests, I'm not sure if we want to ignore them completely in Adblock Plus. If users or filter lists authors want to block those requests they should be able to (e.g. when Chrome or one of it forks suddenly starts to embed ads into the browser's UI, or send tracking requests).

However, I'm afraid that my attempt to report this issue to Chrome will lack technical details since I have no idea how APB intercepts queries in the Chrome and where it looks for requests types. Could you please report it there instead of me?

There you go: ​https://crbug.com/474019

[Lain_13]

Thanks!

I think it could be a type disabled by default, similar to "popup" type. So, it has to be explicitly defined to apply.

[sebastian]

Would you mind to attach a screen recording reproducing this issue to the Chrome bug I created?

[Lain_13]

Screen recording of a problem. User this page: ​http://imgur.com/gallery/09vlZ

[Lain_13]

Oops, attached to the wrong bug. :)

Now atteched it to that Chrome bug too.

[sebastian]

Thanks!

[sebastian]

Closing as rejected as this is a Chrome bug we can't really work around.