Mozilla working on in-page popup blocker for Firefox | Hacker News Reader

Mozilla working on in-page popup blocker for Firefox

androidpolice.com

253 pointsrexbee144 comments

Maybe some webmaster education to teach people that popping up a dialog begging for Facebook follows or email addresses is generally considered a hardcore dick move? Seriously, who decides to employ those dialogs? A newsletter signup is best embedded in the page itself, as is any social follow ads. To shove them in my face is always rude, and usually means not only am I not going to sign up for your newsletter, but I'm to close out of your page altogether. You lose, go home [and fix your jerky web design].

It's not like most people had education specifically for this. The truth of the matter is most of us are winging it big time. Hence the wild west improvisation.

> a dialog begging for Facebook follows

Or that monstrous dialog Facebook has on its pages asking its visitors to join Facebook. Annoying on desktop, supremely annoying on mobile. Just another reason I usually don't bother clicking on Facebook links.

I bet it gets enough leads and or sales so that even though it annoys a bunch of users that it is worth it. If it had no conversions they would have stopped doing it by now.

Arguing that etiquette should be observed when you have a lead / sales generation flow doesn't work.

> Arguing that etiquette should be observed when you have a lead / sales generation flow doesn't work.

Depends on which customers you want.

> Maybe some webmaster education to teach people that popping up a dialog begging for Facebook follows or email addresses is generally considered a hardcore dick move?

That doesn't work. Before Bayesian filtering and Gmail, 90% of my mail was spam. The people who did it knew that it was wrong, they just didn't care. $$$ > almost anything.

Imho the difference is that spam emails are a captive audience; keep sending them, eventually you get a hit. And you can send new ones to the same person repeatedly.

But irritating popups will ensure many will never come back - you've forever lost your opportunity to even attempt to sell me something. Seems so illogical

You're assuming that regular people care that much about them. When you have users with an Internet Explorer not that far from this one: https://i.stack.imgur.com/82hWm.jpg, do you really think that several popups phase the regular users? :)

Internet explorer with a million toolbars seems to have been replaced with the much cleaner tablet-as-a-Facebook-machine and a million freemium apps.

"Steve needs your help in farmville!"

True, but mostly I end up those sites because google sends me there.

When browsers and search engines fights back against crappy web content I suspect we'll see change.

Browsers need a button so the user can categorize a page/site as dickish. In the future, visits to the site will cause the browser to stop with a reminder, similar to the "this page is insecure" dialog, giving the user the option to click through or go back.

"Seriously, who decides to employ those dialogs?"

Usually some out of touch marketing, SEO, advertising, etc. person. Most web developers aren't the decision makers in situations like this.

Do you think those popups are created just to piss you off, or because they are profitable?

Or maybe because someone thinks they're profitable.

I've tried to explain this the my client but they don't care. IF they see conversion from it, they'll keep using it.

I just have a bookmarklet to kill all "fixed" position divs.

I'm clicking it more and more these days - even those damn fixed navs that take up a stupid percentage of the screen give me the shits.

If clicking the bookmarklet doesn't get rid of your stupid modal newsletter sign up or annoying sticky nav, I'm just closing the tab.

Here's the bookmarklet btw:

javascript:(function()%7B(function () %7Bvar i%2C elements %3D document.querySelectorAll('body *')%3Bfor (i %3D 0%3B i < elements.length%3B i%2B%2B) %7Bif (getComputedStyle(elements%5Bi%5D).position %3D%3D%3D 'fixed') %7Belements%5Bi%5D.parentNode.removeChild(elements%5Bi%5D)%3B%7D%7D%7D)()%7D)()

You may also be interested in my filterlist[1] project for uBlock Origin which attempts to do this via CSS style overrides for many, many sites.

[1] https://github.com/yourduskquibbles/webannoyances

holy shit dude.

if this is as awesome as it looks, i'm actually excited.

thank you.

No problem, I hope it works out for you! Feel free to spread the word to others as well as provide sites that are causing issues for you so I can add fixes to the list.

Probably olark and other chat bot crap can be added too. They are mostly used these days for pushy sales people to hook casual browsers.

Fantastic. You must submit your list to the uBlock Origin author for inclusion in the list of available filters.

gorhill is aware of it [0]... I don't want to be too pushy and would rather let him come to his own conclusion on whether to include or not.

[0] https://github.com/uBlockOrigin/uAssets/pull/872

Just want to say; I'm checking in after a few days of using it and... if i think about it, i guess i'm clicking that "killsticky" bookmark less and less.

its funny, suddenly i don't even have to think about it, which is what this is all about - reducing cognitive load.

re inclusion on ublock and the like: it should probably be an option that people can enable/disable; ublock is more about blocking ads/trackers, but i would wager that most people are annoyed with sticky stuff too.

ready for the next challenge?.... getting rid of sites that fuck with the default scroll behaviour ;)

thanks again :)

Brilliant, and Thank You.

Ironically, though, this will probably limit severely the quantity and quality of data I can feed back to this Mozilla project via this add-on...

Me too! I cannot recommend this enough. IMO everyone should have this bookmark (or similar). As you say, it's most useful for removing static overlays that just get in the way of page content and take up screen space, but it can also get rid of pop-ups too.

It even works well on iOS/Safari !

Came across this as well [0]→[1].

(Slightly modernized version could be:)

    javascript:void([].forEach.call(document.querySelectorAll('body *'),e=>/fixed|sticky/.test(getComputedStyle(e).position)&&e.parentNode.removeChild(e)))

[0] https://news.ycombinator.com/item?id=16516126 [1] https://alisdair.mcdiarmid.org/kill-sticky-headers/

You can golf away 8 characters by replacing

    [].foreach.call(a, b) -> a.forEach(b)

... since the value returned by `querySelectorAll` has a `forEach` method. And 5 more if you replace:

    'body *' -> '*'

Ah, thanks for headsup, I somewhat missed the moment NodeList got sufficiently widespread forEach support. Good to know. In fact my intention was just to add check for `sticky` value along the `fixed` one; the 'golfing' approach was just habitual laziness…

that one looks better than the one i pasted - i've noticed that some sites are using "sticky" instead of "fixed" and my bookmarklet (which I copied off someone else) doesn't remove them.

thanks.

It is sad that one of the most powerful CSS features ha been abused to the point where it is now going to be blocked in finicky ways. Modal boxes are quite useful in apps. And they are great for notifications.

But they are annoying when they block everything and prevent you from doing anything further. (I'm looking at you WaPo). I used the clearly extension to bypass things like this. And if that did not work I would go into Dev tools and delete things.

I guess a machine learning approach might be a good approach. But would it learn from all of the benign use cases when people are only reporting negative stuff?

I hope that Firefox will fix the "permissions" problem for web-apps.

I.e., allow web-apps to request permissions, and allow users to grant those permissions. In a way that is not intrusive.

Then, I can see this work, and actually be useful.

This is totally the dream.

Tangentially related, I wish I had fine grained control over whether or not websites can access (or block) pasting, keybindings, etc. I think currently you’d have to write an extension or userscript to monkey patch the functionality in javascript land before the site executes.

We could push for a signing regime. Every page has a certificate applied for every individual developer who worked on the page, and for every publisher whose content is on the page. Then the browser provides a simple button that will blacklist the developers and publishers from ever getting content onto the user's screen again.

Users can opt in to a sharing service which consolidates the blocked certificates across multiple users. When a threshold is crossed for a particular certificate, that certificate can be propagated broadly to all the participants in the sharing service and said developers and publishers can lose the ability to put anything onto a user's across wide ranges of users.

I think when people start having things to lose, they might start acting more responsibly and respectfully.

I like the idea, but it has still some problems. Such as: what if competitors start gaming the system? Will this not result in enormous bureaucracy? How do you control that developers do not swap/sell their certificates?

Perhaps it's best to keep things straightforward at first (?)

Firefox does have permissions already, for things like push notifications and accessing camera/microphone. You can grant/deny them overall, or on a page-by-page basis.

ublocks everything for me on WaPo page, so I don't see need to remove anything using dev tools.

> where it is now going to be blocked

I think the point is not to block all of them, but the annoying "subscribe to our newsletter" ones that pop up even before you've read anything on that site.

That aside: the main reason modals are useful are because they prevent you from doing anything else - sometimes that's needed. If not, a modal is probably not the solution.

I think it would make sense to block modal boxes that show up without any user action, but allow them if there's user action in the chain of events that leads to their appearance. That's how most pop-up blockers work, and it's simple but very effective.

That worked well at first, and then pop-up ads switched from generating the pop-ups as soon as you visited the page to generating them in response to clicking links on the page.

I'm guessing we'll see similar goofiness with modals. And that we'll reach a similar terminal state where nobody uses them anymore, except for your bank, who will doggedly refuse to let you see your monthly statement unless you display your modal blocker first.

Your idea of a terminal state sounds much better than the status quo where everybody and you bank throws modals at you. It's okay if it isn't perfect, as long as it gets rid of like 95% of annoying pop-ups.

Absolutely. But it's depressing that the Web is such that we can never have nice things.

I've taken to browsing with JavaScript disabled, and many sites' "no script" version of the page is just an impassioned plea for me to re-enable JavaScript so that they can do all the popups and tracking and whatnot that prompted me to turn it off in the first place.

I'm trying to find the "clearly" browser extension you mentioned, but have had no success. Where is it?

Sorry. Should have mentioned this:

https://blog.evernote.com/blog/2015/12/17/evernote-to-end-su...

Modal boxes are generally a bad user experience in every case. I'm not going to advocate for blocking them entirely, but certainly I think web developers are over-using them in general (beyond just the intentionally annoying ones Mozilla is hoping to block), and its funny because desktop developers have mostly finally stopped using modals on Windows and Linux. (macOS feels quirky and outdated here now by somewhat recently doubling down on modals for things that don't need to be and probably aren't modal.)

Even for things like confirmations: a user might likely still want to see (and maybe interact with) the thing they are confirming. For instance, if confirming to delete an object, it's still helpful to be able to scroll to see the entirety of the object to double/triple check that it is indeed the object you plan to delete. A overlaying modal always interrupts the user's focus and often gets in the way of otherwise useful information or actions before confirming.

The truth is that modals are easier.

You don't need to worry about elegantly maintaining context. They introduce a side context.

Unfortunately the spell breaks when you want to switch contexts again. The side context makes it awkward. There is also an issue for URLs as modals are difficult to share.

They may solve one specific problem, but are less adaptable than doing the hard work of making separate views.

> A overlaying modal always interrupts the user's focus and often gets in the way of otherwise useful information or actions before confirming.

But an overlaying action-bar with a "confirm" button that otherwise allows you to scroll before you delete would be a great middleground.

But how can a browser tell the difference?

In this specific case of what Mozilla is trying to achieve, they are researching the topic and looking for help. Mozilla doesn't sound like they want to ban all overlays, just the obnoxious ones.

When I think "action bars", I tend to think of banners that expand into a flexbox row or rows of my choosing and I don't overlay anything. If it is meant to hide a part of the UI, it's better to hide or replace that UI explicitly rather than cover it up graphically in an overlay.

Another reason to explicitly hide/replace UI instead of covering it graphically is because that doesn't stop someone from interacting with that covered UI, it just makes it more irritating to do so. I'm not just talking about Dev Tools and similar "cheat" options, but not every user is necessarily interacting with your site or application with sight/graphically. An overlay doesn't stop a screen reader, for instance. (A lot of the modal popups that Mozilla is hoping to block are entirely ignored by a browser's "Reader Mode", which is sometimes my first attempt when I see one.)

> desktop developers have mostly finally stopped using modals on Windows and Linux.

I can't say I've noticed this. Almost every application I have uses modals.

> a user might likely still want to see (and maybe interact with) the thing they are confirming. For instance, if confirming to delete an object, it's still helpful to be able to scroll to see the entirety of the object to double/triple check that it is indeed the object you plan to delete.

KDE uses modals for confirmations but gets at least this instance right: "delete" confirmation boxes list the files in question. I wish other applications would do this.

WaPo 'you've read enough' block is usually defeated by using Private mode, so they can't easily track article views.

That said, paywalls on news sites have made me realize two things: good journalism needs monitary support, and that news is so expensive I can only afford to support one, maybe two news outlets. Vicious.

I wrote a Firefox extension called "Open Page in Private Window" that adds a toolbar button and context menu item to open the current page in a new Private Window. This is useful for reading articles on websites that limit the number of articles you can read per month.

https://addons.mozilla.org/en-US/firefox/addon/open-page-in-...

What's a good example of a page-blocking modal box? I never found one that wouldn't be better as a pop-up, like the new email dialog on Gmail, or as extra content to the main page, like most confirmation dialogs.

Maybe an adult content blocker from a page not normally expected to have it?

Re: ML - I think it might be possible to do some sort of generic popup-detection: a container that's initially invisible, containing a clickable that the mouse accelerates towards shortly after becoming visible. With opt-in, they could use those detections that aren't reported to identify good use-cases (though sending passive data like that might not be very Mozilla).

The tricky bit will be getting rid of the darkened full-screen overlay as well as the modal, but I guess you could track element visibility changes/removals around the same instant as the mouse click.

I'm torn on this. On one hand, yes, these modals are some of the most annoying parts of the web and are really ruining the experience on lots of pages. But on the other hand, why should Mozilla (or any browser) get to start fiddling with the content of web pages? If Comcast announced they were doing this, HN would be up in arms about how they were modifying traffic. I'm aware of the browser vs service provider difference, but the end result is the same. Suppose Google decided that it doesn't like websites with bad color schemes so it's going to have Chrome automatically update some websites to use their material design style? Suppose Microsoft decides that websites with small font aren't friendly enough to people with vision problems so they start upsizing all font below size ten in IE? The point is - the browser should render what it's given. If the user wants to modify that, use a plugin.

Web browsers should always try to act in the best interest of the user, not just render what is given.

I slightly disagree. I think browsers should try to act in the best interest of the user, but should always have the option to just render what is given.

> If Comcast announced they were doing this, HN would be up in arms about how they were modifying traffic. I'm aware of the browser vs service provider difference, but the end result is the same.

I wouldn't as easily dismiss the difference between the browser vs a service provider, but regardless, I assume Mozilla will make it an option you can turn on or off at will. I doubt Comcast would do the same.

If Mozilla comes out with something that changes content without user's choice, I'm willing to bet HN will justifiably be up in arms.

> If Mozilla comes out with something that changes content without user's choice, I'm willing to bet HN will justifiably be up in arms.

They did, and HN was up in arms. Did everyone forget the blowback from their cross-promotion deal with USA for Mr. Robot? https://beta.techcrunch.com/2017/12/15/mozillas-mr-robot-pro...

That wasn't even an integrated part of the browser, it was more a case of bad defaults with an auto-installed plugin and HN was (rightly) quite pissed off with them for it.

This is different IMO, this is changing how a website is rendered, not really very different at all than an adblocker which are already generally accepted.

> The point is - the browser should render what it's given. If the user wants to modify that, use a plugin.

Maybe we can do better?

The browser should render what it's given by default. If the user wants to modify that, change a setting

I think that's a bit naive. Some changes from the default are so accepted and given today, we'd end up with a bizarre situation where browsers ship with a "broken" default that nobody wants.

We are just so used to it that we don't even think about it. Do you think websites should be able to spawn unlimited popups, even as you try to close them? I remember that horror.

The browser launches the first N popups and then offers to block the rest. No problem.

Blocking popups when the JS of the page is clearly trying to spawn more is not "default behavior" at all, it's a trick browser vendors do to enhance the user experience.

I much prefer the existing solution, where all popups are blocked, and I get an indicator showing that a popup was blocked, with the option of enabling it.

You're solution works as long as I can set N to 0, I guess.

Plugins offload a lot of culpa and work from the browser. Though obviously since browsers have taken on tasks like readability mode and popup blocking, they have made decisions here.

But as far as defaults go, I think of people like my parents. My dad was routinely fooled by those fake "Click to Download" ads and it breaks my heart that there are people out there who take advantage of others like this.

Defaults should help the average user. Power users can always turn a setting off.

It's just a mozilla devoloper making a dataset of modal popups to experiment, nothing more atm.

There's a reason that the more generic name for a browser is user agent. That is, they are agents serving at the behest of the user, not the server.

> Suppose Microsoft decides that websites with small font aren't friendly enough to people with vision problems so they start upsizing all font below size ten in IE?

This is somewhat humorous for me, because one of the first things I do to my Firefox installs is lock the font and set a minimum font size that I can read. The most broken sites by far are internal ones at my company, where no one has given a damn about usability or ADA. Most public sites handle it just fine.

I do the same with font size and actually go so far as to disable all custom fonts and sizes. Everything is robo sans sizes 9-13

I do allow sites the choice between serif (Georgia), sans-serif (Segoe UI) and monospace (Courier New). But those are the only fonts permitted. Minimum font size is 13, and default font size is 16.

Is that a plugin you use to lock the font sizes? That's not a default option in Firefox that I can see. I only have default size and minimum size.

And if you have vision problem best thing is to force APHont on every site.That font is recomended for people with low vision.https://www.google.hr/url?sa=t&source=web&rct=j&url=http://w...

I wonder if asking HR how to report ADA violations on internal websites would get attention quickly... I've never been quite brave enough to do that (but then it isn't something that affects me though as my eyes get older it might soon)

Ironically, the MDN (Mozilla Developer Network) description of minimum contrast¹ fails the test it describes: in §1.4.3, the link is #3F87A6 on #F4F7F8 (3.7:1) at 16px. (And the unicorn vomit in MDN's code samples is even worse, sometimes below 3:1.)

¹ https://developer.mozilla.org/en-US/docs/Web/Accessibility/U...

MDN no longer stands for "Mozilla Developer Network", it's now "MDN: Web Docs" https://blog.mozilla.org/opendesign/future-mdn-focus-web-doc...

I guess that puts you against Reader Mode, too, then? The difference between the cases you cite and a browser is the locus of control. As long as I, the user, am in control of how my browser renders the content it's given, it's nobody's business but my own.

Ah but this is merely an experiment. It most likely will land as a Test Pilot addon, and later upgraded into a setting, just like Container Tabs were.

> If Comcast announced they were doing this

But they wouldn't do this.

They would do something like detect the popups and then inject ads for additional Comcast services into them. And they would do it secretively rather than making a public announcement beforehand. And they would hassle customers to no end about switching services in protest of that behavior, whereas most browsers would just provide a checkbox for turning it off.

Comcast is in no way a victim here.

One of the reasons for the "HTTPS everywhere" thing that people have been on about is exactly because ISPs were injecting ads or javascript into web responses (https://www.infoworld.com/article/2925839/net-neutrality/cod...).

So, yeah, they've already been caught doing exactly this.

But on the other hand, why should Mozilla (or any browser) get to start fiddling with the content of web pages?

They started blocking new-window popups 15 years ago. It's a little late to put the cat back in the bag.

Because Mozilla defends its users, while everybody else defends their revenues. That's why Firefox is the best browser.

You say that but it was Mozilla / Firefox that force-remote-installed an addon without user's permissions for a commercial party.

Mozilla is the best that I've seen at defending their users, but unfortunately that bar isn't very high. You are correct that this was an extremely shitty move on their part, but I don't see many alternatives.

Because I have lot more choice with my browser than I do with my ISP, and my browser isn't going to charge me a monthly service fee to disable it.

I'd imagine Mozilla would put in a flag to enable/disable this item, leaving it up to the user as to which they would prefer.

Comcast probably wouldn't offer this option...or if they did, they'd charge you more for it.

What about the _user_? I'd like a easily-enabled option that gets rid of _all_ pop-up, pop-under, modal, whatever junk. Why isn't Mozilla providing that? It shouldn't be a matter of Chrome, or Mozilla, or whoever deciding. It should be a matter of the user deciding.

(And is there really a plugin for that? One that gets rid of all the junk, all the time? If so, it needs to be publicized.)

The most annoying ones for me are the ones that trigger when your cursor leaves the tab. TheHackerNews.com (unrelated to HN) does this constantly. Would it be too drastic to just disallow mousemove events? I see no good use for them outside of needless analytics and bugging users when they try to leave your site.

Not too drastic. If websites continue to display their malicious incompetence this will happen.

Especially if a button isn't pressed. Allow mousemove between mousedown and mouseup.

I like this solution, smart.

But what about web games that want to track your mouse cursor? Maybe the browser could restrict mousemove events to handlers on page elements that the user has clicked on? But then web developers would probably add an event handler on the page itself and receive all mousemove events again.

For me it's the ones that go SUBSCRIBE TO OUR NEWSLETTER when I open the tab for the first time - dude, I haven't even read your content, why are you giving me this.

Firefox extension: https://addons.mozilla.org/en-US/firefox/addon/in-page-pop-u...

Chrome extension: https://chrome.google.com/webstore/detail/in-page-pop-up-rep...

(both for reporting such pop-ups - the blocking hasn't been implemented yet.)

>Mozilla wants to make Firefox automatically detect and dismiss the popups.

That would be quite amazing, some newspaper outlets have that annoying inpage popup that nags me on disabling adblocker.

And if you dismiss it, it shows up every 5 seconds. And that's not even exaggerated. It was legit 5 seconds.

I hope they're careful with that. Modals could contain legally required waivers such as for upcoming GDPR etc.

Edit: what endymi0n said in another subthread

If they kill legal waivers then I would say that is up to the website operator to fix, especially when it's being widely deployed by a major browser vendor.

I think those legally required waivers shouldn't be displayed as a modal but as a landing page of sorts - a modal implies that underneath, the page itself, including ads and trackers etc are already loaded. A proper cookie warning thing should not be able to set any cookies or whatsoever before the user has agreed to it. Of course, a properly designed website will grant access to its content regardless of the user accepting or rejecting the cookie thing.

Second, if a user installs a plugin that automatically hides or rejects cookie warnings / gdpr stuff, that's their own fault then.

I have had this extension installed for about a day and already reported numerous in page pop ups. Not only does it feel good to help a blocking effort, it's also a good vent for the anger caused by these things.

There will be a few fairly simple ways to block these - probably some libraries or pieces of code reused by almost all websites employing these UX-crimes. As mentioned before, maybe the solution is to just block mousemove events.

How about just make a time machine and stop the Netscape from creating JS. I think it was a mistake adding a client side language to the web standards.

Then we'd have the web relying on VBScript. If you stop Microsoft from doing that, well… the market was still changing quickly enough some other browser might've done it and got traction.

Microsoft would have eventually yanked VBScript, and we'd be coding in C# for the browser now...

You know, I think that wouldn't even be such a bad idea. It's got types and it's reasonably static, meaning it can be optimized a lot more than JS can - in fact, Dart was created in part because its more Java / C#-like structure could be run in a much more optimized fashion than Javascript could. And it was invented (iirc) by the guy who made V8, so if anyone knows anything about the limitations of JS's run speed, it was him.

Silverlight didn't really thrive though...

Maybe if we keep going back and fixing it we'll find a solution that works. Worth a try.

Careful. That way lies PHP as client side language. Or Befunge. Don't mess with Time.

https://phpjs.hertzen.com/ ¯\_(ツ)_/¯

Username checks out.

Or everyone would just use Flash.

or Java applets.

I think we need blacklists. When I access a URL, the browser should check if it is present in the blacklist. If present, compare the reason of the blacklist (for example adblock avoidance system) and check the associated action specified by the user (for example, block the site or ask for a confirmation). Users would be able to choose the blacklist he prefers and to report missing sites.

I think there needs to be white lists. Most websites are actively hostile to their users.

A white list would exclude most random personal sites that are the best part of the internet.

Right but we're not talking about defaulting to blocking the entire site, just the ability to do questionable things. If they need to do something questionable, then they should explain to the user what and why, and the user can decide if they trust this site.

Ah, right. I lost track of the context. A whitelist of "probably won't try to pwn you" would be nice.

I want them filtered out of Google search results. Sick of going to them by accident.

I would do that for Google Groups, the UI is so shitty I would like to ban it automatically from all search results.

Have you tried the Personal Blocklist extension? https://chrome.google.com/webstore/detail/personal-blocklist...

I‘m really curious how this will play along with GDPR, which will pretty much absolutely need forced modals in order to to legally capture tracking consent. It could also create interesting legal constellations: How do you prove you asked for user consent when your client side code was blocked or modified?

You don't get consent if it was blocked.

You can’t do anything without affirmative consent, so if your modal was blocked the user can’t give it. You don’t need modals though: you could have an in-process step for the action you want to collect data for, or just anonymise your tracking rather than collecting personally identifiable data.

GDPR doesn't force modals. They are just the easiest and most lazy way to implement GDPR compliance. So perhaps modals becoming unreliable will inspire web developers to explore other options... like not tracking absolutely everything about the user from first millisecond after the page was rendered.

Nah. We'll get the same thing we got on mobile phones (and still have); force redirect the user to a new page, then redirect back to the home page (not where you came from) or just reloading the entire page when consenting (or not).

I don't think GDPR is going to be easily dismissed with modals asking for permissions like cookie notifications were. Someone correct me if I'm wrong, but if the user doesn't give consent (whether explicitly, or via a browser blocking a modal) then unless that information was critical to the application function then you have to provide the service anyway without downgrading the functionality.

Its all explicit opt-in/implicit opt-out instead of implicit opt-in/explicit opt-out. There are no consequences for the user if they opt-out, and it is extra-territorial in its enforcement meaning it impacts any businesses in any region handling European citizen data. GDPR seems to mean business from a regulatory standpoint.

This is correct except for the cases where a company can show "legitimate interest" in which case it is in fact an opt-out rather than an opt-in [1].

And yeah, I agree - they mean business

[1] https://www.gdpreu.org/the-regulation/key-concepts/legitimat...

This is an interesting interpretation of GDPR I have not heard before. Are you confusing it with the older cookie notification law? If not, can you explain what part of GDPR you see a popup as satisfying?

I am legitimately curious, because GDPR can be quite nuanced and I may be missing something myself.

Edit: I'm still trying to figure this one out. I just read a dozen articles about affirmative consent and almost every one recommends a clearly defined and unambiguous checkbox embedded in your form. I couldn't find any example that did a modal except for some mobile app examples but mobile apps would presumably not be effected by this change to how in-page popups work. The fact is, the browser does not passively collect enough PII without asking for it explicitly in a form so putting the consent also in the form is an easy choice.

Again, I could be missing something. I'm hoping someone more familiar with it can clarify.

Simple; don't trust your user's browser will use your website like you intend it to. Don't use an annoying modal dialog, use a landing page instead. Block access to the page until your server has received a positive "I agree" confirmation.

The lazy approach is to have a fully client-side modal dialog that is clicked away with an "I agree", fully client-side.

You ask "How do you prove you asked for user consent", but you don't need to - you need to prove the user gave consent. And if the user has a script that automates that process, then that's good enough for you and your company IMO.

Shitty sites like Reddit hide the scrollbar until you manually click the button that makes the popup disappear, so automatically hiding the popups is going to break them.

I like it.

Is this about actual popups, new windows with their own browser chrome, or about modals? The graphics in the article reflect modals.

If Mozilla really wanted to block actual popups could do so directly by directly removing the userland functionality spawns a new browser window.

Actual popups not spawned from user interaction have been blocked for like the past 10 years though

When I worked at Travelocity we would find ways to prove this wrong as necessary to create those hated popunders. Expedia still uses these.

Modals (i.e. "in-page"). All browsers have been blocking regular pop-ups for ages now (or at least have tried to).

I wish the browser could present a huge screen (2000px high or bigger) to the webpage and render it. After that I would love to scroll this viewport without the page even knowing about it.

This would resolve all problems with position fixed and also block the page from showing real modals once scrolling starts.

Float-overs and ridiculous full-width bars are some of the most annoying "innovations" that have appeared in recent years. But I don't see why browsers have to do anything - the publishers clearly like the way their pages work and consider it worthwhile.

Blocking things like this is different from blocking third-party advertising in my mind. I should be able to stop my browser from contacting a third-party site.

If the author of a page wants to see a float-over then so be it. I can choose to close the tab and not come back.

Detecting popups like this automatically seems like it will be more of a cat & mouse game with developers trying to find ways around it and then a bunch of legitimate use cases being blocked out.

And Firefox still hasn't fixed their issues with native popups: http://fan-pages.herokuapp.com (WARNING: if you use FF it may crash your browser)

It would have been helpful to give a warning that simply going to that site would crash my browser.

Sorry, I didn't think it was that effective anymore. Updated.

btw Chrome seems to have some kind of protection against that dialog DoS. From what I've been told Firefox actually downloads the content in the background before you ever approve the dialogs (which is probably great if someone isn't popping an infinite number of them).

How is this possible? Real popups windows were mostly blocked by only allowing them in user event handlers (sketchy sites like bittorrent trackers can still create popup windows because you have to click on the site at some point).

But an in-page popup window can be created in loads of different ways. I can't see a general heuristic you could apply to detect them.

That's why (if you read the article) there's a browser add-on now which allows you to report pop-ups, so that the creator can use that input as a blacklist. Popular sites' popups should be easily blocked that way. Crowdsourcing the patterns, so to speak.

Worst offenders are iZooto guys peddling their crappy web notifications fixed position dialog all over the Indian news sites. Solves no purpose other than steal good amount of space on the screen. Waiting for either their junk product to die or Mozilla to release this blocker soon.

Makes me think of what you often hear that browsers are the new operating systems. They definitely are, even in the worst vices: here we go, we also need the antivirus now.

I think it is about time we rethink the whole web to the foundations. In the meantime we can install Lynx.

This will be great coupled with Firefox's ability to turn off "get spam right in your browser" (aka site notification) prompts.

Hopefully it will allow user triggered overlays.

It's sad that this is needed.

On a side note my ublock origin went into overdrive on androidpolice. How many trackers does a man need FFS?!

I count 38 uBlocks and 13 Badgers. Yay.

I count 2 from uBlock. But then again, I have JavaScript disabled on all domains by default; I just whitelist the ones I care about.

Life is infinitely better now.

Reply on news.ycombinator.com