Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

samsonite.pl [Breakage] [FCL] #711

Closed
kulfoon opened this issue Nov 27, 2018 · 12 comments
Closed

samsonite.pl [Breakage] [FCL] #711

kulfoon opened this issue Nov 27, 2018 · 12 comments

Comments

@kulfoon
Copy link

kulfoon commented Nov 27, 2018

List the website(s) you're having issues:

https://www.samsonite.pl

What happens?

Breakage - the page won't load - shadow overlay

List Subscriptions you're using:

uBO default +
uBO annoyance +
Fanboy’s Cookiemonster List +
I don't care about cookies addon

Your settings

  • OS/version: Windows 7 SP1 64bit
  • Browser/version: Firefox 63.0.1 64bit / Opera 56 64bit
  • Adblock Extension/version: uBlock Origin version: 1.17.2

Other details:

Screenshoots:

screenshoot 1 - after enabling Fanboy’s Cookiemonster List and / or I don't care about cookies addon

ss066

.
screenshoot 2 - after disabling Fanboy’s Cookiemonster List and I don't care about cookies addon

ss067

.
screenshoot 3 - after accepting the message

ss068

.

Notes: just BTW FYI, I don't care about cookies addon is also affected - I've already sent the mail just right now.

@krystian3w
Copy link

samsonite.pl##div[aria-labelledby="ui-dialog-title-cookies-dialog"], .ui-widget-overlay

but widget block reload page - strange and silly...

@ryanbr
Copy link
Owner

ryanbr commented Dec 1, 2018

I just needed;

samsonite.pl##.ui-widget-overlay

If someone can test that doesn't affect other parts of the site?

@krystian3w
Copy link

It probably will not be problem, this is the typical background for this web plugin.

@ryanbr ryanbr closed this as completed Dec 1, 2018
ryanbr added a commit to easylist/easylist that referenced this issue Dec 1, 2018
@kiboke
Copy link

kiboke commented Dec 3, 2018

"I don't care about cookies" will implement this instead, for greater precision and to allow other modals to have an overlay:
.ui-dialog.cookies-dialog ~ .ui-widget-overlay:not(body):not(html)

@krystian3w
Copy link

krystian3w commented Dec 3, 2018

I would be more worried if the store works without cookie permission accept than if I need to check if the message and the background are in the same parent (html element).

@krystian3w
Copy link

krystian3w commented Dec 3, 2018

I have not checked yet almost whether elements are immediately after to use the plus.

Pseudo code CSS - what I mean (children next to each other):

.ui-dialog.cookies-dialog + .ui-widget-overlay

https://www.w3schools.com/cssref/sel_element_pluss.asp


Does not work on this case, the elements are not directly behind each other.

@ryanbr
Copy link
Owner

ryanbr commented Dec 3, 2018

Simplified filters, generally will be faster. (like my initial commit) though if there is a better filter available I'm happy to modified it.

@krystian3w
Copy link

krystian3w commented Dec 3, 2018

@kiboke wrote:

.ui-dialog.cookies-dialog ~ .ui-widget-overlay:not(body):not(html)

I think ui-widget-overlay does not have to be checked if it's a <body> or <html> element.

Certainly from a logical point of view, it would be difficult to become <html>, and the <body> would require the <head> to be .ui-dialog.cookies-dialog:

<html>
   <head class="ui-dialog cookies-dialog">
          ...
   <head>
   <body class="ui-widget-overlay">
         ...
  <body>
</html>

@kiboke
Copy link

kiboke commented Dec 3, 2018

My filter will not be applied just on this website, hence the greater complexity.

For global filters I always add :not(body):not(html) automatically because I've seen many websites where the developer, for god knows which reason, apply a cookie related classname to both body and html.

@kiboke
Copy link

kiboke commented Dec 3, 2018

But you're right, :not(body):not(html) is probably not needed in this case.

@krystian3w
Copy link

krystian3w commented Dec 3, 2018

As for me, in such a mix it is more sensible to check the first parameter and the second decisive is no longer like blocking as a <body> or <html> (cutting the page - blank page).

@ryanbr
Copy link
Owner

ryanbr commented Dec 3, 2018

personally not overusing :not(...) , and +/~ improves extension/browser performance, only really limited to problematic filters

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

4 participants