Hacker News Reader

Comment by jacobgorm | Hacker News Reader

I absolutely see the need for this if implemented in concert with the host OS windowing system, because current popovers must be emulated in a way that does not always work well.

For example, a browser-native <select> today will be able to expand beyond the borders of the hosting browser window, so you can don't have to worry about it getting clipped to the window borders, but a fancy emulated select from toolkit like Quasar will not, ,which limits its placement options. So to do this right on win32 you would need each popover to have its own native HWND and on Cocoa/macOS you would need it in its own NSView.

Does anybody in here know if this is how it is actually implemented in the current browsers, or is it just a paint-over job inside the browser window?

View on HN

These popovers are just regular DOM nodes styled with regular CSS.

Giving websites a vector to paint outside the designated viewport (except in extremely limited circumstances like alert(), confirm(), [title], <select>, etc.) makes it a lot easier for them to convincingly emulate browser and OS dialogs. It's a massive security risk, I don't think it's worth the limited upside. Concrete example: a page emulating your password manager extension's unlock widget.

Edit: Note that this is not a theoretical concern. Scammers over the years have created extremely convincing fake UI elements, including fake popup windows complete with the browser chrome. They're even draggable. Not being to paint past the viewport boundary is one of very few, if not the only limitation they couldn't get around.

Let's say there's a native app that can also do pop ups. What's to stop the native app from basically stealing the likeness of your password manager? In other words, as web apps seek to become like native apps, they may also accrue the risks which are characteristic of that space.

Native apps have to be installed. You don't want to give every power they have to random websites (say, that phishing domain at the top of a Google SERP), not for a very good reason. "My custom dropdown can't draw past the boundary of the viewport" isn't a very good reason.

Giving this capability to arbitrary web apps is definitely a bad idea, but conceivably it could be made available to installed PWAs in the same way things like the Window Controls API are: https://developer.mozilla.org/en-US/docs/Web/API/Window_Cont...

PWAs can contain dynamic ads elements, which will try to abuse that. If it was normal for desktop apps to run some remote view+script sandboxes, this problem would extend there too. On one hand, PWAs are apps, on the other, they enable the spirit of downloadable web content much more easily.

There's not much to stop what you describe, other than the trust you place in a native app when you install it. Super common experience to have to give superuser access once during an installation process, and most bets are off regarding security once you do that. That's part of the added friction involved in running a native app; you have to trust it more.

Only other alternative I can think of would be an Apple App Store-style review process where the task of proving trustworthiness gets shifted onto the developer rather than the user. But it's still based around human trust rather than a platform constraint.

I see two parts to this. One is the role of user choice in deterring system damage from bad apps, and the other is the role of app stores in shielding the user from having to make this choice to begin with.

On the matter of websites, if the decision rests on individual choice, then individuals certainly have a choice to visit (and thus trust) a particular domain name and cert. That users need merely type in a name, and that there's a giant company helping you search for these apps, simply means that web apps are easy to find and install (and native apps are only slightly harder to install).

Then there's the role of the app stores, which I imagine practically deals with the supermajority of garbage, spams and scams out there. We could also have orgs whose sole job is to maintain lists of credibility, if that's what people want. Then a web user could download a browser extension or use a browser that subscribed to these lists by default. In some ways that's what ad blockers are, except ad blockers are even more precise and there's nothing quite like it in the native world.

The assumption is that webpages are safe to browse.

Installable programs grant a degree of trust over your system.

If webpages are unsafe, or have native capabilities, the World Wide Web becomes less useful, as the act of clicking a link is heavy thing.

Nothing at all.

Related note: this is also why iPad and Android tablet apps don't have real popovers or floating toolbars either. Mobile treats the window boundary as sacred.

How useful is such a feature in reality? On smaller devices, the web brower almost always covers the whole screen, and even on big monitors, it usually touches at least one corner.

It will also make it semantically easier to detect. I'm thinking about accessibility and crawlability but also in case anyone wants to write some "no popup" plugin.

Firefox, for one, technically supports "popping out" part of a page's content into a separate OS-level window. It exposes that functionality through the XUL <panel> and <menupopup> elements, which are only available to privileged [X]HTML being rendered in the browser's main process. I doubt that any browser developer would want to give ordinary web pages the ability to create borderless OS windows.

I don’t see web apps getting the native windowing system integration you envision anytime soon. The fact that some standard controls behave that way is an OS-specific implementation side effect of them being implemented as OS-native, which they aren’t required to be.

Reply on news.ycombinator.com