elros34 / sailfish_linux_chroot

GNU General Public License v3.0
20 stars 4 forks source link

Make Ubu Chromium-browser the default browser from SFOS? #8

Open Kabouik opened 4 years ago

Kabouik commented 4 years ago

Same as issue #7: this is a naive question and not a feature request, there might be too much work. However, maybe it's possible using Mimer in SFOS and some text config black magic?

Right now I can select Ubu Chromium as default browser in Mimer, and clicking on a link in a SFOS application confirms Ubu Chromium is the default app, but it will not open a new tab even when Chromium is already running. I assume this is because the Ubu Chromium .desktop file is actually running a script and not only the app.

Ubu Chromium-browser really is an amazing leap forward in terms of productivity on keyboard phones. I finally have an up to date browser with keyboard shortcuts for tabs, navigation, prev/next, close tabs, prev/next tab, Tampermonkey user scripts, Stylus user styles, extensions, html5 web apps… It even can be used as a media player with file:// (though without HW decoding). It really is awesome when the hardware is powerful enough, not a toy or gadget anymore (which is a good enough use, anyway).

elros34 commented 4 years ago

You don't need mimer anymore because sfos already have openFileDialog which allows you to choose browser when you click on a link. If it doesn't work then you probably have installed one of these applications which breaks this behavior. If you remove ~/.local/share/applications/mimeinfo.cache and run update-desktop-database as root it will work correctly.

I just checked and it works. When I click on link, site opens in a new tab but window is not activated so this could be improved somehow.

Kabouik commented 4 years ago

Excellent news.

How did you select Ubuntu Chromium in the SFOS app chooser? I do see the multiple choices, but the list could not be edited in my case (Sailfish browser, Webcat, Microtube). The only way I found to add Ubuntu Chromium was to use Mimer, now I get 4 choices for URLs.

It does not open new tabs in my case. Perhaps because I added Ubuntu Chromium the wrong way? Does it work both for Chromium in its own window and for Chromium within your DE? In which SFOS application did you click on the link?

elros34 commented 4 years ago

So I was right, both webcat and microtube breaks x-scheme-handler/https for everything else.

It doesn't matter how chromium it's started, new tab is handled itself in browser. I see no reason for it to not work.

Kabouik commented 4 years ago

Weird, still no luck for me, regardless of whether Chromium is opened in its own window (Chromium browser icon in the Homescreen) or from XFCE4 itself.

I did realize Webcat and Microtube break the app chooser so I uninstalled them, deleted mimeinfo.cache and ran devel-su update-desktop-database, but still no new tab opened in Chromium when selecting it upon clicks on links in SFOS apps. If I pick Sailfish browser, it does open a new tab in it.

Kabouik commented 4 years ago

Not directly related, but you might be interested and I don't know where else to contact you. I made a simple video to showcase how well Chromium and Ubu chroot in general work in combination with the Pro¹: https://youtu.be/DLl92bISgAo

The combination makes for an amazing productivity device (splitting the screen in xfce4 is awesome for instance, since we cannot do it in SFOS).

elros34 commented 4 years ago

If you didn't figure it out yet try to start chromium then: ./ubu-start.sh chromium http://example.org should open new tab and print something similar:

chromium-browser --force-device-scale-factor=1.5 --window-size=640,360 --window-position=0,0 http://example.org nohup sh -c 'sleep 6; setxkbmap -layout '\''pl'\'' -rules evdev -model jollasbj -option '\''grp:ctrl_alt_toggle'\''' (translated) Opening in existing browser session.

It should work same when you use: xdg-open http://example.org

Kabouik commented 4 years ago

I'm getting some weird output, supposedly related to my host signature being changed:

[root@Sailfish sailfish_ubu_chroot-dev]# ./ubu-start.sh chromium http://example.org
++ export ON_DEVICE=0
++ ON_DEVICE=0
++ '[' -f /etc/sailfish-release ']'
++ ON_DEVICE=1
+++ logname
++ export HOST_USER=nemo
++ HOST_USER=nemo
++ '[' -z nemo ']'
++ export HOST_HOME_DIR=/home/nemo
++ HOST_HOME_DIR=/home/nemo
+ eval set -x
++ set -x
+ '[' 2 -eq 0 ']'
++ ubu_ssh_pid
++ pgrep -u root -x -f '/usr/sbin/sshd -p 2228'
+ '[' -z 8299 ']'
+ run_qxcompositor chromium
+ '[' chromium == qxcompositor ']'
+ '[' chromium == xfce4 ']'
+ '[' chromium == chromium ']'
+ '[' 1 == 1 ']'
++ ubu_qxcompositor_pid
++ pgrep -u nemo -f 'qxcompositor --wayland-socket-name ../../display/wayland-ubu-1'
+ '[' -n 8188 ']'
+ print_info 'qxcompositor already running'
+ echo -e '\n\e[93m=== qxcompositor already running ===\n\e[0m'

=== qxcompositor already running ===

+ ubu_host_user_exe 'invoker -s --type=silica-qt5 qxcompositor'
++ whoami
+ '[' root == root ']'
+ su nemo -l -c 'invoker -s --type=silica-qt5 qxcompositor'
invoker: Invoking execution: '/usr/bin/qxcompositor'
+ return 0
+ '[' chromium == qxcompositor ']'
+ '[' chromium == xwayland ']'
+ ubu_ssh '/usr/share/ubu_chroot/start.sh chromium' http://example.org
++ printf '%q ' /usr/share/ubu_chroot/start.sh chromium http://example.org
+ ubu_host_user_exe 'ssh -p 2228 -o StrictHostKeyChecking=no user@localhost /usr/share/ubu_chroot/start.sh chromium http://example.org '
++ whoami
+ '[' root == root ']'
+ su nemo -l -c 'ssh -p 2228 -o StrictHostKeyChecking=no user@localhost /usr/share/ubu_chroot/start.sh chromium http://example.org '
@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@
@    WARNING: REMOTE HOST IDENTIFICATION HAS CHANGED!     @
@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@
IT IS POSSIBLE THAT SOMEONE IS DOING SOMETHING NASTY!
Someone could be eavesdropping on you right now (man-in-the-middle attack)!
It is also possible that a host key has just been changed.
The fingerprint for the ECDSA key sent by the remote host is
SHA256:qAyFvzR6WqNYGaDPYFfSp5HkAtcCn7tJP6Ii7jB+hL4.
Please contact your system administrator.
Add correct host key in /home/nemo/.ssh/known_hosts to get rid of this message.
Offending ECDSA key in /home/nemo/.ssh/known_hosts:1
Password authentication is disabled to avoid man-in-the-middle attacks.
Keyboard-interactive authentication is disabled to avoid man-in-the-middle attacks.
user@localhost: Permission denied (publickey,password).
[root@Sailfish sailfish_ubu_chroot-dev]# 
elros34 commented 4 years ago

ssh -p 2228 user@localhost and follow instruction which should appears or remove known_host file.

Kabouik commented 4 years ago

Thanks, this part is fixed (perhaps it was due to me fiddling around with multiple .ext4 files).

Now opening new tabs from command line works but only if I am root. If I am not, then ubu-srtart.sh will restore the chromium window but prompt me to type my password in the other window with terminal, and the tab opens after I confirm my password.

With xdg-open, the same happens with chromium being restored, but no password prompt, so I am guessing this is why it fails when clicking on a link in SFOS apps and choosing chromium to open them.

elros34 commented 4 years ago

Then there is still something wrong with ssh because it shouldn't ask you about password.

Kabouik commented 4 years ago

Interesting, Ubu chroot has been asking for my password since I created it using ubu-create.sh. I'm prompted for password for Ubu shell, Ubu close, Ubu xfce4 and Ubu chromium. Thought it was normal because almost everything seemed to be working.

I have checked Ubu's ~/.ssh/authorized_keys and the key is correct, it does match the public key of the SFOS host.

elros34 commented 4 years ago

It might be dev branch which fails to create passwordless keys. Run as nemo in sfos: ssh-keygen -t rsa -N '' -f ~/.ssh/id_rsa

Kabouik commented 4 years ago

That's to be run on host SFOS, right?

szopin commented 4 years ago

Tried both on sfos side (as nemo and root), and in ubu-shell (also as both), still getting password prompt when using .desktop links (assumed this is normal behaviour)

elros34 commented 4 years ago

Don't mix up different things. Running: ./ubu-start.sh chromium http://example.org when you already have opened chroot will use ssh with keys so it shoudn't ask about password.

Running "ubu close" icon will always ask about password because it kills all started processes and unmount /dev, sys, .. and image. Rest of the desktop files will ask about password only if chroot is not already started. So if you use "ubu shell" desktop and then close opened terminal neither xfce nor chromium will aks about password until you explicitly close chroot.

To sum up ssh -p 2228 user@localhost should works without password when you alread have chroot opened.

szopin commented 4 years ago

Weirdly enough my setup doesn't work with the chroot already running, I have to ubu-close.sh or just getting 'no Xwayland' message that goes nowhere if I try to manually restart xfce4 after closing (from the same terminal window it left). The faulty vfat install never asked me for password and just went straight onto the desktop view (with no touch input), but doubt that is relevant. Maybe the multi-instances patch would solve this, but not using patchmanager and I'm fine with a bit of extra typing, no big issue for me

Kabouik commented 4 years ago

Same behaviour for me, I have to Ubu close after I close a chroot-related window (even the shell) before I can open a new one. And password is asked if an Ubu window is running minimized and I ssh -p 2228 user@localhost, I guess this is what prevents new tab openings with xdg-open. I installed the patchmanager multi-instances successfully, but am doubting whether it might be conflicting with something.

I generated a new ssh key but still get the password prompt (xfce4 running before I try to open example.org from ssh, window not closed):

++ ubu_ssh_pid
++ pgrep -u root -x -f '/usr/sbin/sshd -p 2228'
+ '[' -z 24923 ']'
+ run_qxcompositor chromium
+ '[' chromium == qxcompositor ']'
+ '[' chromium == xfce4 ']'
+ '[' chromium == chromium ']'
+ '[' 1 == 1 ']'
++ ubu_qxcompositor_pid
++ pgrep -u nemo -f 'qxcompositor --wayland-socket-name ../../display/wayland-ubu-1'
+ '[' -n 24803 ']'
+ print_info 'qxcompositor already running'
+ echo -e '\n\e[93m=== qxcompositor already running ===\n\e[0m'

=== qxcompositor already running ===

+ ubu_host_user_exe 'invoker -s --type=silica-qt5 qxcompositor'
++ whoami
+ '[' nemo == root ']'
+ invoker -s --type=silica-qt5 qxcompositor
invoker: Invoking execution: '/usr/bin/qxcompositor'
+ return 0
+ '[' chromium == qxcompositor ']'
+ '[' chromium == xwayland ']'
+ ubu_ssh '/usr/share/ubu_chroot/start.sh chromium' http:/example.org
++ printf '%q ' /usr/share/ubu_chroot/start.sh chromium http:/example.org
+ ubu_host_user_exe 'ssh -p 2228 -o StrictHostKeyChecking=no user@localhost /usr/share/ubu_chroot/start.sh chromium http:/exam
ple.org '
++ whoami
+ '[' nemo == root ']'
+ ssh -p 2228 -o StrictHostKeyChecking=no user@localhost /usr/share/ubu_chroot/start.sh chromium http:/example.org
user@localhost's password:
Kabouik commented 4 years ago

Have you by any chance managed to troubleshoot something on our password prompt issue @szopin? I haven't had the time to look into it lately unfortunately.

elros34 commented 4 years ago

If its still not solved how about you start ssh with more verbose mode (-v)?