[avaer]

I'd like to be able to tell my browser what it should tell the pages it's loading, especially if pages are leveraging it to do things against my will.

That applies to blocking Google ads, as well as fixing Youtube malfeatures.

Of course, it's understandable you won't see this from a browser paid for by Google. But you can't paint in broad brush strokes like "I don't think hiding side-effects or user actions helps anyone."

[kinlan]

I'm disputing the fact there was a casual offhand design, and I don't think hiding the state of the render or the browser helps anyone not least developers who need the information about the state of their page.

I'm not saying that there can't be meaningful response from the browser to user hostile actions, I don't think anyone disagrees.

There's a broader question about a user's will and the sites intent especially when it comes to business plans of the site that I'm not sure if access to features native in the browser is aligned with say ad blocking or tracking etc... I don't know.

[Aaargh20318]

> There's a broader question about a user's will and the sites intent especially when it comes to business plans of the site

The site's business plans are not my problem. Basically, my phone and my computer should do what I want. Why is there even an API to make a video player enter/exit full-screen mode ? That's 100% a user decision and there is no valid reason why that should ever be exposed to JS.

[acoard]

>Why is there even an API to make a video player enter/exit full-screen mode ? That's 100% a user decision and there is no valid reason why that should ever be exposed to JS.

There absolutely are valid reasons and responsible uses for the browser to expose that API. Instead the argument should be around the irresponsible uses justifying hiding that part of the API.

Valid reasons to expose full-screen to the API:

* An "Always full-screen videos when I play them" button. * Remote control of demo displays, kiosks, etc. Force them to all fullscreen and play a video synced up. * Disable unnecessary features when website is full screen (e.g. stop polling website for changes) * Exit full-screen on certain conditions. For example on a shared streaming site like Rabb.it, maybe if someone joins your chat room (assume this is configurable by the user)

In short, you can use JS to respectfully enact user decisions.

I'll also mention a related case. On Safari iOS, you can't autoplay a <video> element unless the user has interacted with it via tapping it. The goal, obviously, is to stop autoplaying videos. The goal, of stopping annoying autoplaying videos, is noble, but at the cost of removing the possibility of responsible usage. Maybe it's worth it, maybe it's not, but there is an undeniable tradeoff.

[gpderetta]

There is a long history of browsers disabling or crippling features because they get abused by web pages. In fact is is almost a rule that if a feature can be abused, it will be abused.

A possible solution is having a "responsible app mode" in browsers. Whitelisted webpages have full access to these privileged APIs which would otherwise be stubbed out and non-functional (hopefully in a way that a webpage can't detect).

[Touche]

What if I want to present an X button that the user can click to exit fullscreen? How would I do that without a programmable API?

[pas]

That should be a browser option. (Show exit full-screen button or not.)

Also, especially for video, the browser should be able to play it full screen without any distractions.

Of course, there are optional enhancements (subtitles, or different audio tracks) driven via JS. And for those the controls have to go somewhere.

Ideally, if there were a standard for those, the browser could handle it. (But then we're at the problem of an ever bloating browser.)

[Touche]

Sounds like you are advocating for something very different than the current APIs. You're asking that the browser define its own UI for an exit button. How does it know where to put that? What if it is a game in a `<canvas>` element and the button overlays some important UI in the game?

I think you're overreacting to one bad-actor. Inevitably your suggestion here leads to good-actor pages having much less power to present good UI to its users. The browser has to think of all use-cases and have options for that, rather than defining lower-level hooks that pages can do what they want with.

Would it make you feel better that there already many other ways that pages can do user-hostile things? Have you ever visited a page that blocks right-click? Would you want to forbid Mouse Events because of this?

[pas]

I like the trust model that current browsers do. If I trust a page they can use the full viewport or screen, and a lot of keys, etc.

> You're asking that the browser define its own UI for an exit button.

Yes. Currently firefox puts a "to exit full screen press esc" OSD already on videos, that also interferes with visual presentation of sites/directors. So ... directors already don't put shit there.

The same thing goes for walled gardens (like Apple's - they don't allow some things), the problem is not that it's curated, the problem is that there are insufficient tools available for users to put their walls where they want.

Yes, by default I don't want to allow blocking right click. (You might be familiar with the saga of this bug https://bugzilla.mozilla.org/show_bug.cgi?id=78414 . )

[Aaargh20318]

> ave you ever visited a page that blocks right-click? Would you want to forbid Mouse Events because of this?

No, the left mouse button is for interaction with the webpage, the right mouse button is mine. Just don't send any events for the right mouse button.

[codefined]

Why not just restrict it to user-initiated events that can exit or enter full screen? Similar to how you have to press a button to enter full screen mode. It seems to make sense to do the same thing to exit, or other various actions.

[Aaargh20318]

There already is one as part of the video player component, at least on iOS, right next to the button that toggles full-screen.

[Touche]

The fullscreen API is not just for video elements.

[Touche]

Thank you for staying level-headed here. This is indeed a gray area question, and it's worth having a debate over. No one is clearly in the right.

[kuschku]

Well, the legal answer clearly places one side in the right (the user has the right to modify websites that are shown on their system however they wish to, and the right to circumvent all measures on that site, as in the countless ABP vs. ... cases has been ruled).

The historical answer does the same, as browsers were explicitly designated User Agents, as their whole purpose is to act in the name of the user, and fulfill whatever the user wishes to, which also clearly places the will of the user over everything a website may wish to.

How you interpret this is obviously left to you...

[Touche]

This is not a legal discussion, no one is saying that the user doesn't have a right to block this behavior.

> The historical answer does the same, as browsers were explicitly designated User Agents, as their whole purpose is to act in the name of the user, and fulfill whatever the user wishes to, which also clearly places the will of the user over everything a website may wish to.

The browser is a User Agent, I agree. This doesn't mean they can predict all user hostile behavior and fix it before it ever happens. Browsers often fix bad behaving websites over time. Recently there's been a lot of effort to fix pages that cause scrolling jank when they load ads in the background.

[ariwilson]

Do you have some legal references to this? Curious. The site also has the legal right to refuse to serve you content, of course.

[kuschku]

ArsTechnica had a list of 6 of the recent court cases between AdBlock Plus and media corporations: https://arstechnica.com/tech-policy/2016/11/adblock-plus-win...

There’s been countless cases brought against ad blockers, and all that were about ad blocking, were decided favourable for the blockers.

[Touche]

What does any of this have to do with YouTube blocking PIP?

[zeveb]

> I don't think hiding the state of the render or the browser helps anyone not least developers who need the information about the state of their page.

I don't care about helping developers who want to hinder my usage of my browser on my hardware. It's my CPU they are executing on, and thus it should be I & I alone who determines what is executed.

[awesomepeter]

Well you do determine what is executed. Don't use chrome, don't open the website.