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].

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? :)

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.

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.

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 ;)

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…

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 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?

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.

> 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.

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.)

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.

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.

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?

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.

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.

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.

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.

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.)

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)

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.

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.

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.

> 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.

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.

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.

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.

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.

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.

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.

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.

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?

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.

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).

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.

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.

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.