Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Share API - user action requirement #49

Open
motiz88 opened this issue May 28, 2018 · 3 comments
Open

Share API - user action requirement #49

motiz88 opened this issue May 28, 2018 · 3 comments

Comments

@motiz88
Copy link
Collaborator

motiz88 commented May 28, 2018

I'm trying to implement the RN Share API on top of the Web Share API. The latter is not available inside workers and must be triggered by user activation, so from my tests neither the "JS" nor the "native" Share module can actually successfully invoke it.

The limitation seems to be inherent to the use of a worker+bridge to route user actions to API calls of this sort, which is interesting because this situation will in all likelihood repeat itself with other Web APIs (e.g. audio, probably?). Therefore I wonder if there is anything RNDom can do about this architecturally or whether we need new browser-level hooks to solve this. (Or a different kind of escape hatch in the short term - e.g. the ability to attach synchronous event handlers to certain views as needed, bypassing the bridge)

@vincentriemer
Copy link
Owner

Yes, I hit this issue while building my React Europe slides (created a native module for triggering fullscreen mode). In that case I made it so that when you requested full screen it would first display a popup asking for confirmation and then would make the actual call in reaction to that confirmation.

The above is a workaround/hack at best and we should try and reach out to the browser vendors to discuss solutions. I think I remember seeing a discussion mentioning that Chrome is exploring a different way of propagating 'user gesture activation' where after a gesture it would register a long lived token that would wait to be consumed. I think something like that would work for us but it would be nice to test it out before the strategy is committed on.

@cobarx
Copy link

cobarx commented Oct 12, 2018

Ok, I was able to get this to work by creating a native component that extends View and attaches an onclick listener directly onto the HTML element. In my limited testing, it works quite well. I used RCTView since I couldn't find a native component for Touchable.

Sample code:

import { RCTView, type RCTBridge } from "react-native-dom";

class RCTFullscreenButton extends RCTView {
    constructor(bridge: RCTBridge) {
        super(bridge);

        this.classList = []; // remove pe-box-none class so we can set pointerEvents
        this.style.pointerEvents = "auto";
        this.addEventListener('click', this.onClick);
    }

    onClick() {
        const element = document.getElementById('video');
        if (element) {
            element.webkitRequestFullscreen();
        }
    }
}

customElements.define("rct-fullscreen-button", RCTFullscreenButton);

export default RCTFullscreenButton;

It might be good to write this up as a guide or formalize it so that this capability is built into react-native-dom. When dealing with video, you need to receive user gestures from a variety of sources: fullscreen via button, double click on the video & keypress plus being able to provide gestures to start the video when autoplay is disabled. I realize it's a bit hacky to have surfaces that are react-native-dom specific, but these are going to be fairly common scenarios. If we exposed API for direct event handler props, that would probably be sufficient.

Slightly unrelated, but a capability to set the DOM id via a prop would be good as well. For example with video, you would want to fullscreen the encapsulating view that contains the video canvas and the controls. Making people create native components will be beyond the capabilities of a lot of React Native newcomers.

edit: realized we need a range of event handlers such as click, double click, and keypress

@vincentriemer
Copy link
Owner

There has finally been progress in the browser space! Just found that Chrome's revamp of the user gesture requirement is now available behind a flag and is explained here: https://mustaqahmed.github.io/user-activation-v2/

I tested it with one of my slide decks and normally, if you press the "F" key a popup appears asking to confirm going to fullscreen (a workaround for the gesture requirement), but with that flag enabled it goes straight to fullscreen 🎉

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

3 participants