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

Auto Enter WebXR #1085

Open
wants to merge 18 commits into
base: main
Choose a base branch
from

Conversation

MikeEvansSkillsVR
Copy link

Features:

  • Automatically enter WebXR
  • Hide browser window while entering WebXR
  • Show "Entering WebXR..." popup

Works by simulating touch events on the screen to find the Enter VR button

@svillar
Copy link
Member

svillar commented Oct 24, 2023

First of all thanks for the contributions, they're very much appreciated. I know it's still a draft so I understand you still plan to make more changes. I've just quickly skimmed through it and have a few general comments:

  1. Try to split different features in different commits. For example here you're doing many different things, hiding the interstitial, simulating clicks to enter xr, avoiding exiting XR... Each of them should be discussed carefully and might need a separate PR because might become really complex by itself
  2. Do not use vendor specific directories (like svr) because the feature is general-purpouse. You'll get the credit anyway don't worry
  3. Avoid removing current features. There are several pieces of current code commented here and there
  4. Adding timers for some actions is not generally the best idea because it adds complexity and potential races. It's more convenient to listen for specific events instead
  5. Try to respect the coding style. I know it isn't documented (and it isn't consistent as well), but in general follow the current style of each file

Then I'd also like to talk about the suggested changes:

  1. Why do you think it's interesting to remove the interstitial? Because you don't want users to exit the experience?
  2. I am not sure I agree with a solution that tries to find the "enter xr" button by brute force. It might easily end up clicking in something that is not what we want to. I think a preferable way to go is to specify some coordinates in the intent, after all the caller knows which experience they want to show

@MikeEvansSkillsVR
Copy link
Author

Hi Svillar, we appreciate you taking the time to take a peak at the PR. Also, as a developer, I really appreciate the feedback and tips you provided above. I'll take them on board and work on improving in the areas you have mentioned.

To answer your questions:

  1. The reason for removing the interstitial was purely for the purpose of getting the user straight into the experience. This can be added back if needed. However, the idea is that when starting the webxr experience in this way, the user will already have selected to start it from some third-party application (e.g. a kiosk), so we wanted to eliminate unnecessary inputs being required before the user can access the experience.

  2. Adding a location to the start intent of the browser to be used by the touch simulation is something that was, in fact, discussed! It'll certainly be added. The idea of pressing everywhere on the screen is more of a fallback.

Once again, thanks for taking a look at that and providing your feedback. It is invaluable to me as a developer and to us as a team. Looking forward to further discussion!

@MikeEvansSkillsVR MikeEvansSkillsVR marked this pull request as ready for review November 28, 2023 22:35
Copy link
Collaborator

@HollowMan6 HollowMan6 left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

@HollowMan6
Copy link
Collaborator

Looks like we need to resolve the conflicts between this branch and main before we can run CI again.

@felipeerias
Copy link
Contributor

@MikeEvansSkillsVR Did you consider other alternatives, instead of simulating touch events in this way?

Perhaps we could find the button by ID and trigger the click event on it directly. This seems more flexible and robust in case the layout of the page changes.

Something like this:

var iframe = document.getElementById( 'game-frame' );

if (iframe && iframe.contentWindow && iframe.contentDocument) {
    var button = iframe.contentDocument.getElementById( 'start-btn' );

    if (button) {
        var clickEvent = new MouseEvent('click', {
            'view': iframe.contentWindow,
            'bubbles': true,
            'cancelable': true
        });
        button.dispatchEvent(clickEvent);
    }
}

This strategy currently returns an error (DOMException: A user gesture is required) if I try to run it from the dev tools, but I think that there are ways to make it work from the browser or from an extension that is bundled with it.

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

Successfully merging this pull request may close these issues.

None yet

5 participants