Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Popover API

developer.mozilla.org

Post reply on HN
Print view View original

61–70 of 166 posts

Re: Popover API

#61

Post by mst »

bestest wrote: post #18
sseagull wrote: post #13

Kinda funny that browsers have built-in pop-up blockers, but then create APIs like this. Yes I know the difference, but still. I’m old enough to remember the pop-up and pop-under wars of the late 90s and early 2000s. I guess we won that particular battle, but the war for our attention is far from over.

I think you're comparing apples with grapples. A popover is floating element that appears to display a contextual piece of information when required. What you're mentioning is something completely different.

I tend to use "apples to aardvarks" but now I'm not sure whether I like mine or yours better.

Shall have to alternate them for a bit and call it A/G testing.

Re: Popover API

#62

Post by mquirion »

delichon wrote: post #53

These are popovers: https://kagi.com/proxy/passover-popovers-6.jpg?c=gBnCtLe1QYl... No you can't have that word to mean something else, it's sacred. And because you tried you can't have any of my popovers either.

Glad I'm not entirely alone in having this thought.

Re: Popover API

#63

Post by cjaybo »

algasami wrote: post #40

The pessimist inside me worries about whether this could be used to lure people into revealing their credentials; granted, there are thousands of ways to do this easily, but I'm still cautiously optimistic on this topic.

Saw an interesting case of this type of attack in the CounterStrike community earlier this week.

Someone setup a fake tournament website that asked the user to login with their Steam account. Then it launched what looked like a new browser window with the Steam login page, but was actually just a popover that had been elaborately styled, with window decorations and all.

Re: Popover API

#64

Post by delichon »

logrot wrote: post #56
delichon wrote: post #53

These are popovers: https://kagi.com/proxy/passover-popovers-6.jpg?c=gBnCtLe1QYl... No you can't have that word to mean something else, it's sacred. And because you tried you can't have any of my popovers either.

Never heard of them. Any good? Something you make yourself or by ready? Eaten hot or cold?

They are quite delicious. Home made, eaten hot, with butter in our home. It's a Jewish Passover tradition that I find to be odd, because it is supposed to be part of an ascetic ritual in which we forego "leavened" bread and so instead eat matzo and popovers. But instead of being any kind of sacrifice it is a great treat, especially in a household that doesn't otherwise serve fresh baked bread.

It's like telling a kid they've been naughty so they can't have the old cookies, they have to eat fresh baked cookies instead.

Re: Popover API

#65

Post by darby_eight »

sseagull wrote: post #13

Kinda funny that browsers have built-in pop-up blockers, but then create APIs like this. Yes I know the difference, but still. I’m old enough to remember the pop-up and pop-under wars of the late 90s and early 2000s. I guess we won that particular battle, but the war for our attention is far from over.

It also helps that we now just have spam covering content and slowing our computer down inside the window. Hell, many publications will even get you to pay for the privilege.

Re: Popover API

#66

Post by oefrha »

threatofrain wrote: post #46
oefrha wrote: post #14

Earlier quoted context omitted.

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], , 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…

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.

Re: Popover API

#67

Post by [deleted] »

jacobgorm wrote: post #9

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

[deleted]

Re: Popover API

#68

Post by seltzered_ »

The popover API feature turned out to be super useful when writing a userscript for extracting data from a website recently.

Allowed a nice way to float a list with content for users to copy.

Re: Popover API

#69

Post by sseagull »

efilife wrote: post #30
sseagull wrote: post #13

Kinda funny that browsers have built-in pop-up blockers, but then create APIs like this. Yes I know the difference, but still. I’m old enough to remember the pop-up and pop-under wars of the late 90s and early 2000s. I guess we won that particular battle, but the war for our attention is far from over.

I've seen exactly this comment somewhere on HN already. What's going on?

Deja vu?

I did start to type this as a response elsewhere, but never submitted it. And there’s nothing in my comment history.

So my theory is “great minds think alike” :)

Re: Popover API

#70

Post by staminade »

oefrha wrote: post #66
threatofrain wrote: post #46

Earlier quoted context omitted.

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...
Post reply on HN