Closed Bug 1764264 Opened 2 years ago Closed 2 years ago

Dynamic "Close" Icon is present at suche.mobile.de with ETP set to STRICT

Categories

(Core :: Privacy: Anti-Tracking, defect, P3)

Firefox 100
Desktop
Windows 10
defect

Tracking

()

RESOLVED WORKSFORME

People

(Reporter: rbucata, Unassigned)

References

(Blocks 1 open bug, )

Details

Attachments

(1 file)

Environment:
Operating System: Windows 10 PRO x64
Firefox version:Firefox Nightly 101.0a1 (2022-04-11) (64-bit)

Preconditions:
ETP set to STRICT
Clean profile

Steps to reproduce:

  1. Navigate to: https://suchen.mobile.de/fahrzeuge/search.html?vc=Motorbike.
  2. Accept the cookie policy.
  3. Observe the result.

Expected Behavior:
A dynamic "Close" icon is present.

Actual Behavior:
Page loads as expected.

Notes:

  • Not reproducible with ETP set to OFF.
  • Works as expected using Chrome.
  • Screenshot is attached.
Attached image Screenshot_5.png

That "X" button seems to actually be there so the user can close an ad (which is somehow not appearing on Raul's screenshot). The ad is usually on the bottom of the page, partly off-screen, and the user can hover over it to slide it up into full view. But the "X" is not part of the ad, and is rather added by the website above the top/right corner of the ad, so the user can close the ad-slot. If the ad is missing, the "X" will still appear, mispositioned as in Raul's screenshot.

However, I cannot reproduce the condition, so it's likely that it only happens for certain broken or somehow blocked ads. We might be able to shim away the "X" button, but it seems like this is site error more than a problem with ETP or Firefox.

Severity: -- → S3
Summary: Dynamic "Close" Icon is present at suche.mobile.de with ETP set to STANDARD → Dynamic "Close" Icon is present at suche.mobile.de with ETP set to STRICT

The issue is not reproducible on my side anymore.

Tested with:

Browser / Version: Firefox Nightly 101.0a1 (2022-04-21) (64-bit)
Operating System: Windows 10 PRO x64

I also still can't reproduce this. It does seem likely to just be a case where their code cannot handle any ads being blocked more gracefully, and without knowledge of which ads were blocked as trackers, it will be impossible to do anything here. If anyone runs into this again and can determine which URLs were blocked that were meant to go in that ad-slot, we might be able to do something here. In the meantime, there's not much point in keep this bug open.

Status: NEW → RESOLVED
Closed: 2 years ago
Resolution: --- → WORKSFORME
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Creator:
Created:
Updated:
Size: