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
A flag to stop showing the use native app page on mobile #7612
Comments
Here is my description of the same need: I use a jitsi room embedded in an iframe and already pass a few configuration keys in the URL : https://jitsi.example.com/room#config.startWithAudioMuted=true&startWithVideoMuted=false&config.requireDisplayName=true Thanks a lot for having enabled using jitsi directly in the browser on mobile! That makes a big difference. Is possible to set "Launch in browser" by default on mobile? My mobile users are annoyed of having to click on the page and we happen to leave the room & join back a few times a day (saving bandwidth when not actively discussing). What would fit my needs the easiest way would be a configuration key to be passed in the URL A banner to invite to install the app could present this option, with less words, and in a more punchy way. Thanks a lot for the amazing work you provide! It's time for me to consider support financially the development of Jitsi :) |
This issue has been automatically marked as stale because it has not had recent activity. It will be closed if no further activity occurs. Thank you for your contributions. |
I also would appreciate such a feature. Meanwhile I found a workaround by setting |
I confirm, it works fine to add #config.disableDeepLinking=True at the end of the URL. Thanks a lot @coolmast! |
This issue has been automatically marked as stale because it has not had recent activity. It will be closed if no further activity occurs. Thank you for your contributions. |
This issue has been automatically marked as stale because it has not had recent activity. It will be closed if no further activity occurs. Thank you for your contributions. |
disableDeepLinking is DEPRECATED! use deeplinking.disabled : true insted of that. |
Hello, I tried to change from disableDeepLinking: true -> deeplinking.disabled: true seems no working, any suggestion, please. |
Is your feature request related to a problem you are facing?
I use jitsi meet to provide live help to persosn using our school website. I use the external api to generate a password protected room each day. The passwords are supplied by the javascript on the webpage and are not known to the users. Once on our website you can get into our support room.
Users on mobile are prompted to use the native Jitsi meet but once they get to the native app they are asked for the apssword which they do not know.
After some testing I realise there is a continue with web option but it is not very obvious and most users "who need help" dont understand the difference...and we cant really tell them because they havent gotten to the support room yet. BTW many of the users with problems are parent who dont necessarily read well so displaying the instruction is not a good option.
Describe the solution you'd like
A flag in the external api that i can set which makes jitsi open the meet in the browser without the extra step and does not offer the native app as an option. It hould simply behave the same as it does on desktop.
Describe alternatives you've considered
Cant disply instructions on the web page - truth is the only reason many of the users need help is low literacy or low comprehension.
Unable to deploy our jitsi server right now and we need a simple and powerful solution (like Jitsi). We tried but have not been able to get it fully functional on our shared server.
Rolling our own WebRTC - we dont have the resources to dedicate to this right now. We also use a webapp and so moving users from our apt to jitsi causes information about who and if they are logged in and to what accout to be lost.
The set up we have works very nicely on web right now, we didnt even realize there was a problem until people started calling and emailing asking for the "help" password.
MOBILE_APP_PROMO:false still prompt for them to use the app.
The text was updated successfully, but these errors were encountered: