Jitsi-meet: Desktop view available for mobile

[rscastil]

Please correct me if I should not reopen this topic.
I tried to remove this on the head of my html meta name="viewport" content="width=device-width, initial-scale=1.0" but its still detecting that I'm using mobile device so I conclude that the mobile detection is based on actual mobile device not on the width.

I'm trying to use the desktop view on specific page. Is there a way on the api to force them to use desktop view in mobile device?

[saghul]

The detection is based on the actual device / browser. You cannot override it, but you can use the "request desktop site" option that both Chrome and Firefox offer in Android.

We are not going to enable the desktop interface on mobile, because the experience would be subpar, so we are encouraging our users use the apps.

I know some disagree with this, but that's how things are today.

[bahiamartins]

I could make it work by changing the file: /usr/share/jitsi-meet/libs/app.bundle.min.js

Change the line:
if ("android" === e || "ios" === e)

To:
if (false && "android" === e || "ios" === e)

[lheckemann]

FWIW this excludes the one feature that I love the most about jitsi meet, and one that's advertised on its front page, from mobile users. The low barrier to using it and low commitment is what has allowed it to practically replace Skype for when I talk to people, but this insistence on the app has stopped several conversations I wanted to have from happening.

Simple to use
No downloads required. Jitsi Meet works directly within your browser. Simply share your conference URL with others to get started

At least this false advertising should be removed from the main page if mobile browsers won't be allowed.

I'll probably be setting up my own copy of jitsi meet to disable the forced app promotion using the config option (@bahiamartins I believe the more correct solution is to set MOBILE_APP_PROMO, introduced in 743d12e32607f2ba9f1a228e110b9877a9924df9, to false).

[ZuzooVn]

@lheckemann , I can bypass app promotion by setting MOBILE_APP_PROMO to false, but this error comes:

Any idea?

[saghul]

You can instruct your mobile browser to request the Desktop site.

[ZuzooVn]

@saghul: my problems is I am making Jitsi app for Android 4.0 based devices, which can not be used your react native app. Thus I use external_api.js and this problem comes.

[saghul]

@ZuzooVn This is the only solution I know of: https://github.com/jitsi/jitsi-meet/issues/1662#issuecomment-329813550, but that requires your own Jitsi Meet deployment.

[ZuzooVn]

@saghul: Thanks, I will deploy my own Jitsi meet server.

All I need are those commands?

sudo apt-get install npm nodejs-legacy
cd jitsi-meet
git clone https://github.com/jitsi/jitsi-meet.git
npm install
make

[saghul]

That will just build the frontend. You also need the backend, see the quick start section on the README.

[ZuzooVn]

@saghul you mean this document? https://github.com/jitsi/jitsi-meet/blob/master/doc/quick-install.md, I can not find the backend section.

[saghul]

@ZuzooVn the jitsi-meet package is a meta-package which depends on all components. You can see them all with apt-cache show jitsi-meet.

[ZuzooVn]

@saghul thanks, I can build the backend with below command line

apt-get install jitsi-meet-web-config jitsi-meet-prosody jitsi-meet-web jicofo jitsi-videobridge

My last question is, how can I rebuild the Jitsi with modification?, I used make but it still run the old version.

I think deploy-local.sh will deploy my local version, but I can not find it on GitHub because deploy-local.sh is added to .gitignore file

[ZuzooVn]

@saghul AFAIK, after run make command, how can I copy all of the necessary files to /usr/share/jitsi-meet/?
Should I run jitsi-meet/debian/jitsi-meet-web.install?

[saghul]

You need to do that manually. There is no script for it.

[ZuzooVn]

@saghul thanks, I did it.
I think you should add more detail to README, I took me 1 day to find out the solution :)

[saghul]

It's a great opportunity for contribution, how do you feel about sending us a PR? :-)

[ZuzooVn]

@saghul: I can make a pull request, but I do not sure about my solution.

AFAIK, you have below code on Makefile:

deploy-local:
    ([ ! -x deploy-local.sh ] || ./deploy-local.sh)

But the deploy-local.sh was added to .gitignore (deaff6af5b430bdbcc1ebc23ee00bf45a06c1a21), thus I create my own deploy-local.sh.

I do not know the reason why don't you commit the deploy-local.sh

[saghul]

Ah, I see. Each may have their own deployment needs, so deploy-local.sh is like a "hook" you can create your own and the makefile will use it.

[tmcgee123]

I find it a little bit troubling that you're willing to let people hack your code base to supply functionality for an extremely large use case. Having people install yet another application, in addition to ours in order to let them use video, is a much more subpar experience.

Asking for "Request Desktop Site" is too advanced for most public users, if they're having network difficulties in the browser, then they will almost certainly have the same issues in the application. The only logic I can see for disabling this support for mobile browsers is that you're pushing people to use your applications that you've spent time/money developing, which should remain optional.

I'm sure that my opinion won't change the actual implementation, but I think that your team needs to review these types of decisions better. No one wants their users to be re-directed to another site or application, which goes against multiple principles of retaining users.

If you're going to limit support across browsers, a compatibility chart would be a good idea to limit posts such as these.

[saghul]

@tmcgee123

Our UI / UX is not designed to be mobile friendly. That's a fact. When we went to mobile, we chose to go the native app route. You can like or dislike that, but ultimately that's the choice we made.

Why go this route? Simply, we have more control over the execution environment and can deliver a much better experience thanks to integrations which are not possible on web:

• control over the WebRTC version we ship
• control over the codecs we have
• control over audio device routes
• integration with the proximity sensor

These are just a few examples of why using an app is better. Yes, one has to install it.

If you're going to limit support across browsers, a compatibility chart would be a good idea to limit posts such as these.

We are not limiting support across browsers. We are limiting a platform. It has been suggested before, that a PR which adds a setting for this would be welcome, as long as the current behavior is kept as the default.

At the end of the day, this is an open source project, and we cannot make everyone happy, but you can modify it to suit your needs.

[ghost]

I could make it work by changing the file: /usr/share/jitsi-meet/libs/app.bundle.min.js

Change the line:
if ("android" === e || "ios" === e)

To:
if (false && "android" === e || "ios" === e)

it seems we're now testing for t not e, and the orders of precedence mean that the revised if statement actually was equivalent to if ( (false && "android" === e) || "ios" === e) which meant it would work (with a t) on Android but not on ios. This seems to work for me (although ios didn't seem to work as well as Android - as always):

if(false && ("android"===t||"ios"===t))

[rishabhchd19]

I could make it work by changing the file: /usr/share/jitsi-meet/libs/app.bundle.min.js
Change the line:
if ("android" === e || "ios" === e)
To:
if (false && "android" === e || "ios" === e)

it seems we're now testing for t not e, and the orders of precedence mean that the revised if statement actually was equivalent to if ( (false && "android" === e) || "ios" === e) which meant it would work (with a t) on Android but not on ios. This seems to work for me (although ios didn't seem to work as well as Android - as always):

if(false && ("android"===t||"ios"===t))

This worked for me on Android but not on iOS on iPad chrome and safari browser. Is there any way to keep enable mobile browsing and DISABLE Desktop browsing?

[ddevault]

I'm also here to speak out against forcing users into the app. It's a dark pattern and should really be fixed.

[ghost]

I'm also hear to speak out against forcing users into the app. It's a dark pattern and should really be fixed.

And the primary reason I no longer use jitsi-meet.

[saghul]

Look, I'm not going to try to explain our reasoning again because we have done that _ad nauseam_. This is our choice. If you don't like our choice you are free to change the code yourself or use a project that better suits your needs.

[ddevault]

Do you suppose once you've had to explain yourself ad nauseam, you maybe ought to reconsider your decision? Or do you think yourselves infalliable, and are tiring of explaining the word of god to the plebs?

It's not hard - you just have to let users try proceeding without the app anyway. Give them the choice.

[saghul]

Do you suppose once you've had to explain yourself ad nauseam, you maybe ought to reconsider your decision?

Not really, the numbers speak for themselves: people wanting mobile web support vs active mobile installs.

Or do you think yourselves infalliable, and are tiring of explaining the word of god to the plebs?

I never intended to make such claim, sorry if it seemed that way.

It's not hard - you just have to let users try proceeding without the app anyway. Give them the choice.

Either in this thread or in another I proposed to have a setting for this, but nobody acted on it. We are comitted to the mobile apps for various reasons and have no resources to devote to this, but I'd take a PR which enables it for a given installation, defaulting to false as it's the current behavior.

[ddevault]

people wanting mobile web support vs active mobile installs

How many of the former camp do you think you actually hear from? I came here because my sister was frustrated with the mobile experience. I'm an open source advocate and a free software developer, so my inclination to voice my complaints is far higher than my sister's ever would have been. How many of them just forget about it and use Skype?

Either in this thread or in another I proposed to have a setting for this, but nobody acted on it. We are comitted to the mobile apps for various reasons and have no resources to devote to this, but I'd take a PR which enables it for a given installation, defaulting to false as it's the current behavior.

Can you see why sending patches which won't bubble up to meet.jit.si wouldn't appeal to me? "Fuck off and self-host", if you'll excuse my paraphrasing, isn't a particularly friendly way to fix this problem.

[saghul]

How many of the former camp do you think you actually hear from? I came here because my sister was frustrated with the mobile experience. I'm an open source advocate and a free software developer, so my inclination to voice my complaints is far higher than my sister's ever would have been. How many of them just forget about it and use Skype?

That I don't know, of course.

Can you see why sending patches which won't bubble up to meet.jit.si wouldn't appeal to me? "Fuck off and self-host", if you'll excuse my paraphrasing, isn't a particularly friendly way to fix this problem.

Your paraphrasing doesn't entice me to spend a single second on this.

I'm not the only one working on this project, but maybe having a "Continue to the mobile site" would be acceptable under certain circumstances (must be Android running Firefox or Chrome, any other scenario won't work). But that effort won't come from our side. I will review such PR and discuss it as needed but so far all I have seen are complaints but nobody volunteered to do much about it.

I'm an open source advocate and a free software developer

I am familiar with your work ❤️

[ddevault]

Your paraphrasing doesn't entice me to spend a single second on this.

I don't have any expectations that you'll spend your time on this. I'm not interested in bullying people into changing their software to do what I want. I believe instead in making the changes I want to see and sending a patch. However, you are a gatekeeper - and I need to convince you that the patch would have merit. You said that such a patch would end up disabled on meet.jit.si, and if that's so, then I'm not interested in spending my own time on it. "Fix this problem" requires O(n) of my time, but "fix this problem and self-host this software forever" requires O(n²). Taking the stance that improvements - and this would definitely be one - wouldn't be fed into jitsi's hosted upstream, despite the time investment and goodwill required from contributors, is where the "fuck off" feeling comes from.

I don't mean to disrespect your work - I think Jitsi is great and I will continue to use it on desktop. But I think that this decision is wrong and I won't be able to reach for Jitsi in the future when I know some participants will be on mobile. No one wants to install a bloody app the first time they use Jitsi. I'm sure it's great for users who already use and love Jitsi, but it's a massive turn-off for new users. I think this stance hurts FOSS as a whole, because the only real alternatives at that point are proprietary.

[tmcgee123]

@saghul

I apologize for my initial comment. Every team makes decisions for what they think is best for their software. It's good to see that people like your product so much they are commenting here to try to make it better.

Given your replies regarding a patch, I can pledge here that I will write this patch or help whomever decides to start it first. This is something that will help our UX greatly and it sounds like a lot of others would benefit as well (who are obviously very passionate 😀).

Thank you for your patience and maintaining this software, I'm looking forward to working on the patch!

[Skagoo]

@tmcgee123 I have a use case in which I would like mobile browser support as well. Did you already start working on such a patch? If so I'd be happy to contribute, if not I will make an attempt myself.

[pingpilot-forks]

This is actually achieved by setting "disableDeepLinking" to true and setting the mobile flags appropriately

[GetoXs]

I could make it work by changing the file: /usr/share/jitsi-meet/libs/app.bundle.min.js

Change the line:
if ("android" === e || "ios" === e)

To:
if (false && "android" === e || "ios" === e)

FYI. In my docker version it it
if("android"===n||"ios"===n)
to:
if(false && ("android"===n||"ios"===n))

[mangmang2006]

Just reinstalled Jitsi with the latest stable version (quick install for Ubuntu 18.x), and found the above relevant code doesn't exist any more for patching. Has anyone found a workaround? ps: from the deb repository, some packages were built on April 3rd. Thanks a lot.

[mangmang2006]

OK, not a big deal: on line 29
from:
function i(){return"android"===r.a.OS||"ios"===r.a.OS}
to:
function i(){return false&&("android"===r.a.OS||"ios"===r.a.OS)}

[rayhaanq]

Just to confirm, setting disableDeepLinking to true worked for me. I can access via mobile browser

[saghul]

For posterity's sake, please see: https://github.com/jitsi/jitsi-meet/pull/3518#issuecomment-611396665

[jeetendra-choudhary]

I could make it work by changing the file: /usr/share/jitsi-meet/libs/app.bundle.min.js

Change the line:
if ("android" === e || "ios" === e)

To:
if (false && "android" === e || "ios" === e)

By the way I couldn't find this in app.bundle.min.js seems like it has been changed. Can someone point me to correct location please?

[huntson]

I could make it work by changing the file: /usr/share/jitsi-meet/libs/app.bundle.min.js

Change the line:
if ("android" === e || "ios" === e)

To:
if (false && "android" === e || "ios" === e)

This no longer works as it appears the file has changed. Can someone enlighten us to the proper way to do this now?

[rishabhchd19]

I could make it work by changing the file: /usr/share/jitsi-meet/libs/app.bundle.min.js
Change the line:
if ("android" === e || "ios" === e)
To:
if (false && "android" === e || "ios" === e)

This no longer works as it appears the file has changed. Can someone enlighten us to the proper way to do this now?

There's something similar in the file that you can still change. Previously it was 't' instead 'e'. check what's there now.

[luixxiul]

I think this is too obvious but let me clarify that editing the minified js is never a permanent solution; that e can be changed anything after upgrading jitsi-meet.

[ashishsharawat]

This is actually achieved by setting "disableDeepLinking" to true and setting the mobile flags appropriately

Could you please specify the location where to make changes?

[wiseminds]

disableDeepLinking

on your own installation check this file /etc/jitsi/meet/<your domain>-config.js